|
More flexibility for extra slection choices
|
|
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. 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. |
|||
|
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)

Search
Member List
Calendar
Help



