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.

[mikejazz]

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.

One Thing I like in PlugPlayer is that it also acts as a player (rendering server content on itself)...

[simoncn]

(13-08-2012 15:08)mikejazz Wrote:  One Thing I like in PlugPlayer is that it also acts as a player (rendering server content on itself)...

Yes, that feature of PlugPlayer is very good. I think it's the only way to play FLAC files on an iOS device.

[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.

[simoncn]

(13-08-2012 19:40)bubbleguuum Wrote:  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.

As you say, filtering duplicates is very easy. However, I'm not aware of any control point that does it. And even if 80% if the control points were to start doing it, MinimServer would still have to jump through hoops to accommodate the 20% that don't.

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

Do you mean the "play all" action to put a complete album/artist/genre/etc. into the playlist? This is supported by most control points, and I don't know of any that are smart enough to eliminate duplicates.

Quote:- initiated by the program to crawl the whole Content directory. A program that would do this and not filter duplicates is flawed in my optionion. Unfortunatly WMP do this and do not filter duplicates (more on this below).

PlugPlayer also does this, but seems not to go as far as WMP in crawling the complete contents. I came across another CP that also crawls the complete contents, but I don't remember which it was.

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

With MinimServer, that's up to each user to decide. Each time they look for content, they dynamically create their own hierarchy and browse down as far as they want to. At any point, they can bale out and view a flat list of albums or items (with or without alpha-grouping).

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

This doesn't do anything for the problem of the control point letting the server know that's it's finished using a container.

It also doesn't solve the problem of setting rules for when the control point needs to refresh its view of a container. There are three steps:
1) The control point decides that it feels like re-reading the container.
2) In response, the server sends an incremented UpdateID value for that container.
3) The control point refreshes its view.

Step 3 is required, but step 1 isn't. So if a control never re-reads any containers (perfectly legal), it will never see an incremented UpdateID value.

I've only come across one control point that does the 1/2/3 sequence correctly, and that control point is ChorusDS.

The evented variable (ContainerUpdateIDs) is another of those optional things that servers don't need to implement.

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

I didn't know that. So when MinimServer supports UPnP Search, there's some hope that it might start to work with WMP.

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

Yes, I do mean that. Can you name a control point that does this? I haven't found any.

I don't believe this would cause a lag if the control point implements it correctly and the server is very responsive. It should be like AJAX (Google Maps) where a background thread is reading slightly ahead to anticipate user scrolling. If the user jumps to a completely different point in the list, the time lag to get the necessary data would be a few ms (with MinimServer), which shouldn't be noticeable to the user.

Quote:I consider that if a container has two many items, it should be further split, for example by first letter (or group of letters).

MinimServer supports this as an option.

Quote:And to some extend, hierarchical browsing shows its limit with huge collections. That's where UPnP Search becomes useful.

There's a place for both. I'm not a great fan of typing search queries, but I understand that some people like to do that.

[bubbleguuum]

(13-08-2012 20:49)simoncn Wrote:  As you say, filtering duplicates is very easy. However, I'm not aware of any control point that does it. And even if 80% if the control points were to start doing it, MinimServer would still have to jump through hoops to accommodate the 20% that don't.

Indeed, a common occurence with UPnP often constrained by the lowest common denominator

(13-08-2012 20:49)simoncn Wrote:  Do you mean the "play all" action to put a complete album/artist/genre/etc. into the playlist? This is supported by most control points, and I don't know of any that are smart enough to eliminate duplicates.

You are right, most serious Control Point have it probably

(13-08-2012 20:49)simoncn Wrote:  This doesn't do anything for the problem of the control point letting the server know that's it's finished using a container.

It also doesn't solve the problem of setting rules for when the control point needs to refresh its view of a container. There are three steps:
1) The control point decides that it feels like re-reading the container.
2) In response, the server sends an incremented UpdateID value for that container.
3) The control point refreshes its view.

Step 3 is required, but step 1 isn't. So if a control never re-reads any containers (perfectly legal), it will never see an incremented UpdateID value.

I've only come across one control point that does the 1/2/3 sequence correctly, and that control point is ChorusDS.

The evented variable (ContainerUpdateIDs) is another of those optional things that servers don't need to implement.

Not sure I understand you fully here, but indeed a CP will indeed refresh whenever it feels like to. The Media Server cannot force a CP to refresh although it can give hints it should (ContainerUpdateIDs, UpdateID).
In practice, 99% of containers contain static content so I do not see this as a big issue (but maybe I do not understand the exact use case you have in mind).

(13-08-2012 20:49)simoncn Wrote:  

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

Yes, I do mean that. Can you name a control point that does this? I haven't found any.

The few that do just implement lazy loading. When the end of the list is reached, new items are loaded with an annoying delay (and if possible an in your face popup so you can be sure it is loading).

(13-08-2012 20:49)simoncn Wrote:  

Quote:I consider that if a container has two many items, it should be further split, for example by first letter (or group of letters).

MinimServer supports this as an option.

Quote:

That's great =)

[quote='simoncn' pid='645' dateline='1344887374']
There's a place for both. I'm not a great fan of typing search queries, but I understand that some people like to do that.

People are used to search in regular desktop media players to filter stuff.


Wooo, these monster post become a real sport for proper quoting =)

[simoncn]

(13-08-2012 23:09)bubbleguuum Wrote:  Not sure I understand you fully here, but indeed a CP will indeed refresh whenever it feels like to. The Media Server cannot force a CP to refresh although it can give hints it should (ContainerUpdateIDs, UpdateID).

The point is that a server can only send UpdateID to a control point when the control point is reading an item from that container. So if the control point takes a snapshot of a container and never reads the container again, it will never know that the container's UpdateID has changed.

You are right that the server can send the evented ContainerUpdateIDs variable as a solution to this problem. Does BubbleDS support this evented variable and refresh its containers accordingly?

Quote:In practice, 99% of containers contain static content so I do not see this as a big issue (but maybe I do not understand the exact use case you have in mind).

The use case is that a user adds a new album to their collection. This could cause updates to a number of containers that the control point is caching (albums, composers, artists, genres, etc.)

Quote:The few that do just implement lazy loading. When the end of the list is reached, new items are loaded with an annoying delay (and if possible an in your face popup so you can be sure it is loading).

Not good. It sounds like there might be an opportunity for a control point that does this in a smarter way.

Quote:People are used to search in regular desktop media players to filter stuff.

If I'm sitting on my sofa using an iPod as control point, I'd prefer not to pop up the small on-screen keyboard to type a search query.

[bubbleguuum]

(14-08-2012 08:46)simoncn Wrote:  You are right that the server can send the evented ContainerUpdateIDs variable as a solution to this problem. Does BubbleDS support this evented variable and refresh its containers accordingly?

It doesn't but it really should. There's a manual reload action in the menu.

(14-08-2012 08:46)simoncn Wrote:  If I'm sitting on my sofa using an iPod as control point, I'd prefer not to pop up the small on-screen keyboard to type a search query.

I understand your point, but if you know what you want to play you prefer to browse a huge folder hierarchy instead, with loading times involved, scrolling etc ? Not me.
And past search queries are cached (not the query result, but the search term) so they are 1 click away.

[simoncn]

(14-08-2012 12:21)bubbleguuum Wrote:  I understand your point, but if you know what you want to play you prefer to browse a huge folder hierarchy instead, with loading times involved, scrolling etc ? Not me.
And past search queries are cached (not the query result, but the search term) so they are 1 click away.

I don't usually sit down and think "I want to play X". Normally I think "how about something from this composer and/or this artist, let's have a look at some options and choose one".

[winxi]

(14-08-2012 12:21)bubbleguuum Wrote:  

(14-08-2012 08:46)simoncn Wrote:  If I'm sitting on my sofa using an iPod as control point, I'd prefer not to pop up the small on-screen keyboard to type a search query.

I understand your point, but if you know what you want to play you prefer to browse a huge folder hierarchy instead, with loading times involved, scrolling etc ? Not me.
And past search queries are cached (not the query result, but the search term) so they are 1 click away.

IMHO, both smart browsing and UPnP search have their entitlement, and there is also a need for both.

Smart browsing (which is already implemented perfectly with MinimServer) is a cool feature to explore your media library or for creating a playlist if you don't already certainly know what you want to listen to.

UPnP search is comfortable for large music collections if you already exactly know the title you want (as bubbleguuum mentioned, you don't have to browse, scroll, wait for a container to load multiple times...). Moreover, UPnP search it's a necessity when you for example just remember a part of the title and don't know the artist or ohter information.

This is the only reason I use twonky in parallel to MinimServer, because it supports UPnP search. I use them approximately to equal portions, Minim for browsing and twonky for searching. Once if UPnp search may be available with MinimServer, i will be happy to get rid of the 'old diva' twonky.