About Lumin app, after some analysis, I came to the following "conclusions", am I right or wrong?

 

 

1/

All the http tracks addresses and albums images are stored by the app.

 

 

2/

No UPNP requests are addressed by the Lumin, but only http requests. The UPNP server is fully bypassed.

 

 

 

 

Pros

Faster navigation than network communications for navigation on the iPad.

 

 

Cons

Long time to first load the llibrary. Memory limitation on the iPad. An infinite cache does not exist.

 

 

No simple and fast server change, mismatched cache between several servers.

 

 

One tag change on the server side requires a full parse of the entire library by the app, this is not automatic and requires user action "update Library"

 

 

As UPNP server is bypassed (no UPNP calls, only http calls), server transcoding (or other UPNP server setup) cannot be used and is also bypassed. As wave transcoding provides better (little) output, than Flac (decoding software jitter), you cannot use the Lumin app to get server transcoding.

 

 

 

 

Of course all this was tested. With Kinsky and Luminn app as Control Points, and Synology, Foobar and Jriver as UPNP servers.

 

 

With Kinsky, the Lumin is naturally able to deliver UPNP requests, and, for example, transcoding works on the server side.

 

 

I can inderstand that "fast" was a design requirement for navigation, but, maybe, all the consequences of the technical design choices to achieve "fast" were not enough evaluated.

 

 

"Fast" can be achieved by a smarter cache design. No one looks at the entire library simultaneously. Cache updates can be made "real time" when entering a folder or a navigation branch.

 

 

To bypass the UPNP server seems to me a very "strange" design choice for a UPNP network player control app

 

 

Best and kind regards.