selecting 'Hide Contents' may crash MinimServer

[bubbleguuum]

(13-08-2012 12:57)simoncn Wrote:  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.

Yes, I understand what you mean.

A CP doing a recursive browse should filter duplicates (note that neither BubbleUPnP / BubbleDS do it). It is easy to filter as the item id uniquely identify each item (provided that the server use the same id for identical items!). It could also further try to detect duplicates comparing a few attributes that are likely to uniquely identify an item.

There are 2 scenarios where recursive browsing can happen:

- initiated by a user from any folder with a CP that allow this. Not many CP have this functionality. And I'm not sure how often users recursively load a folder.
- initiated by the program to crawl the whole Content directory. A program that would do this and not filter duplicates is flawed in my opinion. Unfortunatly WMP does this and does not filter duplicates (more on this below).

Personaly I'm not too keen on deep and complicated hierarchies. Anything over 3 or 4 levels is too much I think.

Quote: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.

The UPnP standard has something for this: the UpdateID return value of the Browse action. Theorically a browsing CP would need to reinitialize an ongoing Browse on a container if it receives a different UpdateID. In pratice I'm certain very few CP uses this value.
A container whose content changes can also be notified to clients through an eventing variable I forgot the name but it is also probably not taken into account by many CP.
So in theory dynamically chaing containers are possible but in reality there is very little support for it.

Quote: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.

WMP does indeed crawl the MS and do not remove duplicates as mentionned aboved. However it crawls the MS as a last resort if a particular search query fails:

upnp:class derivedfrom "object.item.audioItem"

If you implement that search query and returns all tracks it will solve the problem.

Quote: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.

Do you mean using paging with RequestedCount for display purpose ?
This can be done but it is not very user friendly introducing lag. I dislike apps using lazy loading of lists. Some UPnP apps do it btw.
I consider that if a container has two many items, it should be further split, for example by first letter (or group of letters).
And to some extend, hierarchical browsing shows its limit with huge collections. That's where UPnP Search becomes useful.