|
selecting 'Hide Contents' may crash MinimServer
|
|
13-08-2012, 20:49
Post: #15
|
|||
|
|||
RE: selecting 'Hide Contents' may crash MinimServer
(13-08-2012 19:40)bubbleguuum Wrote: Yes, I understand what you mean. 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: 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. 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: 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 ? 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. |
|||
|
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)

Search
Member List
Calendar
Help




