Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
More flexibility for extra slection choices
11-09-2013, 12:48
Post: #11
RE: More flexibility for extra slection choices
(11-09-2013 11:44)winxi Wrote:  Just wanted to add that with this approach, the control point should also mark the top-level container of a recursive search as 1). This way it should be even possible to recursively add a '>> ...' extra selection container to a playlist (e.g. a single disc of a multidisc album).

I don't think this is correct.

If the top-level container is a multidisc album and the recursive Browse request is marked as 2), MinimServer would return the complete list of tracks for the album because these are direct children of the top-level container. There is no need to return the disc containers as well, because these contain the same tracks as the top-level container.

If the top-level container is a single disc of a multidisc album, this means the container for the single disc was returned by a previous Browse request marked as 1) for the album. If the recursive Browse request for the single disc is marked as 2), MinimServer would return the complete list of tracks for the single disc because these are direct children of the disc container.

So in both these cases it is correct to mark the top-level recursive Browse request as 2).
Find all posts by this user
Quote this message in a reply
11-09-2013, 13:29
Post: #12
RE: More flexibility for extra slection choices
(11-09-2013 12:48)simoncn Wrote:  I don't think this is correct.

If the top-level container is a multidisc album and the recursive Browse request is marked as 2), MinimServer would return the complete list of tracks for the album because these are direct children of the top-level container. There is no need to return the disc containers as well, because these contain the same tracks as the top-level container.

If the top-level container is a single disc of a multidisc album, this means the container for the single disc was returned by a previous Browse request marked as 1) for the album. If the recursive Browse request for the single disc is marked as 2), MinimServer would return the complete list of tracks for the single disc because these are direct children of the disc container.

So in both these cases it is correct to mark the top-level recursive Browse request as 2).

I mainly use BubbleUPnP as the control point. With BubbleUPnP, it is possible to play/enqueue a whole container using its context menu. I consider such a selected container as the top-level container of a recursive search, but maybe it's the wrong terminology.

Let me give an example: when the current view is a whole multidisc album, there are all tracks visible and also '>> Disc n' containers. When now selecting one of the '>> Disc n' containers to be played via the context menu (long tap in BubbleUPnP), this '>> Disc n' container should be marked as 1), because otherwise MinimServer would return it empty.

So, my comment from before should be: When a single container is selected to be played recursively, it should be marked by the control point as 1) and all its sub-containers should be marked as 2).
Find all posts by this user
Quote this message in a reply
11-09-2013, 13:52
Post: #13
RE: More flexibility for extra slection choices
(11-09-2013 13:29)winxi Wrote:  Let me give an example: when the current view is a whole multidisc album, there are all tracks visible and also '>> Disc n' containers. When now selecting one of the '>> Disc n' containers to be played via the context menu (long tap in BubbleUPnP), this '>> Disc n' container should be marked as 1), because otherwise MinimServer would return it empty.

I think there is a misunderstanding about what I'm proposing. The result from a Browse request marked as 1) for a multi-disc album would look like what MinimServer currently returns, except that the "Disc n" containers that are returned would directly return a list of tracks when browsed. The result from a Browse request marked as 2) for a multi-disc album would look like what MinimServer currently returns, except that it wouldn't include the "Disc n" containers.

With this approach, the context menu play operation in BubbleUPnP will work correctly on individual album discs.

I think I've found a way to send the 1) and 2) markers on Browse requests by including these within the SortCriteria field. The server could advertise some predefined "fake" sort capabilities on its GetSortCapabilities response, and these "fake" capabilities could be used as markers on Browse requests. If the server doesn't advertise these "fake" sort capabilities, this means it doesn't support this nonstandard extension.
Find all posts by this user
Quote this message in a reply
11-09-2013, 14:28
Post: #14
RE: More flexibility for extra slection choices
(11-09-2013 13:52)simoncn Wrote:  I think there is a misunderstanding about what I'm proposing. The result from a Browse request marked as 1) for a multi-disc album would look like what MinimServer currently returns, except that the "Disc n" containers that are returned would directly return a list of tracks when browsed. The result from a Browse request marked as 2) for a multi-disc album would look like what MinimServer currently returns, except that it wouldn't include the "Disc n" containers.

With this approach, the context menu play operation in BubbleUPnP will work correctly on individual album discs.

Thanks for clarifying this! I think I do now understand what your are proposing. So, when MinimServer gets a browse request for a '>> ... ' container, it would have to remember whether the browse request that led to the current view was marked with the 1) flag or if it wasn't marked at all to decide whether to directly show the contents of the '>> ...' container or to show the 'Hide Contents' step, is this correct?.

Quote:I think I've found a way to send the 1) and 2) markers on Browse requests by including these within the SortCriteria field. The server could advertise some predefined "fake" sort capabilities on its GetSortCapabilities response, and these "fake" capabilities could be used as markers on Browse requests. If the server doesn't advertise these "fake" sort capabilities, this means it doesn't support this nonstandard extension.

This sounds good and would also provide a way for the control point to check whether the server supports this extension.
Find all posts by this user
Quote this message in a reply
11-09-2013, 16:19
Post: #15
RE: More flexibility for extra slection choices
(11-09-2013 14:28)winxi Wrote:  Thanks for clarifying this! I think I do now understand what your are proposing. So, when MinimServer gets a browse request for a '>> ... ' container, it would have to remember whether the browse request that led to the current view was marked with the 1) flag or if it wasn't marked at all to decide whether to directly show the contents of the '>> ...' container or to show the 'Hide Contents' step, is this correct?.

It will have this effect, but there's no need for MinimServer to remember anything. When the flag 1) is set, MinimServer will return the ID for a disc (etc.) container that directly shows its contents. When the flag 2) is set, MinimServer will omit the disc (etc.) container (similar to showExtras=false). When neither of these flags is set and showExtras is true, MinimServer will return the ID for a disc (etc.) container that uses the "Hide Contents" extra step. When neither of these flags is set and showExtras is false, MinimServer will omit the disc (etc.) container. The memory of what's needed is in the container ID(s) that MinimServer returns to the control point.

Quote:This sounds good and would also provide a way for the control point to check whether the server supports this extension.

Yes, it's good practice for both sides to indicate their support for an extension in order for it to be active.

The next step is to produce a draft proposal to see if any control point authors are interested in implementing it. I probably won't be able to do this immediately.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)