selecting 'Hide Contents' may crash MinimServer

[simoncn]

(10-08-2012 12:52)bubbleguuum Wrote:  Any specific feature(s) you have in mind that are difficult to achieve with th current standard ?

The most obvious problem from the user perspective is the need for MinimServer to add 'Hide Contents' containers all over the place to support alternative views of the contents of a container while preventing recursive browsing from returning duplicates. If ContentDirectory provided a recursive browsing operation as a mandatory feature (for example, as a BrowseAllChildren flag), and all the control points used it, this ugliness could be eliminated. A better solution would be to support alternative views of the same container as part of the protocol.

It should be possible to do recursive browsing using the Search operation. Because this is optional, I suspect that no control points use Search for recursive browsing. So even if MinimServer were to add support for recursive browsing via Search, it would still need to pollute the Browse tree with all these 'Hide Contents' containers.

If ContentDirectory allowed a container to be marked as "hidden" by the server, so the control point would use it for recursive browsing but not display it, this would solve the 'Hide Contents' problem.

It's unfortunate that 'Hide Contents' needs to be a container. MinimServer does this because the server only gets told about container selections, not item selections. If the server could return a selectable item to the control point, and be told when the user selects that item, this would enable some interesting new features in MinimServer.

I think the most serious deficiency is the lack of any lifecycle management for server containers. When the control point requests a container from the server, the server must be prepared to return the same contents for BrowseDirectChildren operations on that container for an unbounded length of time. If the contents of the container change because new music has been added, the server still needs to remember the historical contents of the container (for ever!) because the protocol doesn't allow the server to know whether the control point is still using those historical contents.

Another big problem is the lack of any standard for when the control point should refresh container contents. It seems that every control point has a different strategy for when it does this. Even Kinsky Windows and Kinsky iOS aren't consistent! If the server has a fixed hierarchy of containers whose contents never change, this might not matter much, but if the server is building container contents dynamically, it matters a great deal.

Quote:Some Control Points have gone the route of building their own database from an UPnP Media Server to overcome some limitations, with the rmedia server being only there for initially crawling content, get updates and serve content.
Notably, WMP, J River Media Center and Songbook (iOS) do this.
I'm ambivalent on this solution. I can see the advantages (custom navigation, global search) but it duplicates Media Server functionality and creates new problems on the CP side (syncing).

I'm not keen on this approach. It only works if the server has a fixed hierarchy of containers with no duplication of contents. WMP is completely unusable with MinimServer because of this, and many useful features of MinimServer don't work with PlugPlayer because of its aggressive preloading.

In similar vein, it seems that all control points preload the complete contents of an opened container even if they don't preload the whole browse tree. It would be much more efficient if they took advantage of the UPnP facility to load only those items from the container that the user is displaying on the screen.