Threaded Mode | Linear Mode

winxi · 09-09-2013, 21:54

Hi Simon,

I want to suggest some more flexibility for the extra selection choices (the ones with the >> prefix which lead to the 'Hide Contents' intermediate step). In my wishful thinking, the showExtras property would not only allow true/false, but it would allow to enable/disable single extra choices and also to enable/disable the Hide Contents intermediate step for each of these.

There has already been some discussion about this and I'm aware that the 'Hide Contents' intermediate step is required to prevent duplicated or unwanted items. So let me give some motivation why I think that more flexibility for the showExtras property would be good:

I'm aware of the following extra selection choices, please correct me if there are more:
>> Complete Album
>> Show All
>> Tag View
and for multi-disc albums the '>> Disc n' or '>> DISCSUBTITLE' extra selection choices.

- If I understand it correctly, the '>> Complete Album' selection choice contains additional items compared to the current view and the other three selection choices contain just duplicate items compared to the current view. So, if a control point cares for filtering duplicate items, the 'Hide Contents' intermediate steps for the latter three selection choices have gone out of use. I was in contact with bubbleguuum recently and he considers adding the duplicate filter in one of the next releases of the Bubble control points.

- I personally never use the '>> Show All' selection choice nor would I want to add such a large amount of items to a playlist, as I use alphagrouping usually only for 200 or more list entries. On the contrary, I find the '>> Disc n' selection choices for multidisc albums extremly useful. Here, the 'Hide contents' intermediate step avoids duplicated items when adding the whole multidisc album to a playlist, but it also prevents me from directly adding just a single disc to the playlist (using the context menu in BubbleUPnP).

- When UPnP search is available, BubbleUPnP allows to show the full album for any item in any view. So I wouldn't want to use the '>> Complete Album' selection choice anymore.

So if the showExtras property would for example allow a comma separated list of strings to enable/disable single selection choices (e.g. the strings completeAlbum, showAll, tagView and singleDisc) and if it additionally would allow +/- to enable/disable the corresponding 'Hide Contents' intermediate steps, i would then set showExtras to '-tagView, -singleDisc' :-)

simoncn · 10-09-2013, 13:22

I understand the reasons for your request.

Let's start with the easy part. I don't think there are any problems with allowing the different extras to be selected individually. As you suggested, this could be done by setting the default value of showExtras to

albumDisc, completeAlbum, showAll, tagView

and allowing people to customize which combination of these they want to see. It would also make sense to allow the displayed text to be renamed, for example:

completeAlbum:Komplettes Album, showAll:Alle Anzeigen

Now for the more difficult part. I'm still not convinced that it would make sense to allow the "Hide Contents" step to be removed. This extra step is somewhat inconvenient, but it prevents unpleasant surprises with having duplicate tracks or extra tracks added to the playlist. I understand that some control points have solved this problem either by using UPnP search or by flitering duplicates, but there are many control points that use a naive implementation and I think it's important to make MinimServer work well with these control points.

I also understand the argument that an option like this would be used only by expert users who will know how to avoid any problems that this will cause. In practice, I think it's likely that many nonexpert users who find the extra Hide Contents step inconvenient would select the option to remove this step without fully appreciating the consequences of doing this.

I would very much like to find a way to overcome the inconvenience of the current approach without the disadvantages mentioned above. One possibility would be to have a way to tell the control point that the container that is protected by the "Hide Contents" choice should be displayed for interactive browsing purposes but should not be used for recursive browsing. For example, this could be done with nonstandard marker elements within the <container> tags for both the "Hide Contents" container and the protected container, and a control point that understands these markers could avoid showing the extra "Hide Contents" menu to the user.

winxi · 10-09-2013, 20:59

(10-09-2013 13:22)simoncn Wrote: I understand the reasons for your request.

Let's start with the easy part. I don't think there are any problems with allowing the different extras to be selected individually. As you suggested, this could be done by setting the default value of showExtras to

albumDisc, completeAlbum, showAll, tagView

and allowing people to customize which combination of these they want to see. It would also make sense to allow the displayed text to be renamed, for example:

completeAlbum:Komplettes Album, showAll:Alle Anzeigen

This sounds great and it would complement the already awesome configurability of MinimServer Smile

Quote:Now for the more difficult part. I'm still not convinced that it would make sense to allow the "Hide Contents" step to be removed. This extra step is somewhat inconvenient, but it prevents unpleasant surprises with having duplicate tracks or extra tracks added to the playlist. I understand that some control points have solved this problem either by using UPnP search or by flitering duplicates, but there are many control points that use a naive implementation and I think it's important to make MinimServer work well with these control points.

I also understand the argument that an option like this would be used only by expert users who will know how to avoid any problems that this will cause. In practice, I think it's likely that many nonexpert users who find the extra Hide Contents step inconvenient would select the option to remove this step without fully appreciating the consequences of doing this.

I see your points. Maybe it would be less problematic if the default setting would be to keep the 'Hide Contents' step and that it would have to be disabled by explicitely adding the '-' character. The user would then have to read the user guide to be able to disable the 'Hide Contents' step and at the same time he/she would be informed about the consequences.
Maybe this would also be a predestinated question for a possible FAQ (something like "Why do I get duplicated items in my playlist and how can this be avoided?"). However, if you ever decide to establish such a FAQ, I'm sure that the first entry would be something like: "Does a common abbreviation exist for MinimServer?" Wink

Quote:I would very much like to find a way to overcome the inconvenience of the current approach without the disadvantages mentioned above. One possibility would be to have a way to tell the control point that the container that is protected by the "Hide Contents" choice should be displayed for interactive browsing purposes but should not be used for recursive browsing. For example, this could be done with nonstandard marker elements within the <container> tags for both the "Hide Contents" container and the protected container, and a control point that understands these markers could avoid showing the extra "Hide Contents" menu to the user.

This sounds very interesting. Unfortunately, I've not enough knowledge to comment much on the mechanics of the UPnP protocol. I think that the most important thing is that MinimServer stays compliant with all standard UPnP control points which don't know how to handle such nonstandard marker elements.

simoncn · 10-09-2013, 21:28

(10-09-2013 20:59)winxi Wrote: I see your points. Maybe it would be less problematic if the default setting would be to keep the 'Hide Contents' step and that it would have to be disabled by explicitely adding the '-' character. The user would then have to read the user guide to be able to disable the 'Hide Contents' step and at the same time he/she would be informed about the consequences.
Maybe this would also be a predestinated question for a possible FAQ (something like "Why do I get duplicated items in my playlist and how can this be avoided?"). However, if you ever decide to establish such a FAQ, I'm sure that the first entry would be something like: "Does a common abbreviation exist for MinimServer?"

I still think the explanation of what this option does would involve too much complexity for the average user to understand. There are probably only a handful of MinimServer users who fully understand the subtleties of what "Hide Contents" is doing. I'd much prefer to pursue a simple robust solution based on a protocol extension that allows the server and control point to collaborate to do the right thing in all cases. Of course, the success of this approach would depend on control point authors being willing to support it.

Quote:This sounds very interesting. Unfortunately, I've not enough knowledge to comment much on the mechanics of the UPnP protocol. I think that the most important thing is that MinimServer stays compliant with all standard UPnP control points which don't know how to handle such nonstandard marker elements.

To ensure this, it would be necessary to wrap the nonstandard marker element inside a <desc> element. A UPnP control point is required to accept this and ignore any elements within <desc> that it doesn't understand.

simoncn · 11-09-2013, 08:55

I've been considering other possible approaches for using the UPnP protocol to solve this problem.

Ideally, the control point would have some way to flag a Browse request as either of the following:

1) the result of the request is for interactive presentation to the user

2) the result of the request is part of a recursive subtree search and not for interactive presentation to the user

If MinimServer receives a request of type 2), it would omit the extra items. For requests of type 1), the extra items would be included. If neither 1) nor 2) is specified, MinimServer would return the current "Hide Contents" container for the extra items.

The difficulty with this is finding a way to specify 1) and 2) that will be harmlessly ignored by servers that don't support this extension. At the moment, I don't see anything in the arguments passed with the Browse request that would be suitable.

winxi · 11-09-2013, 09:24

(10-09-2013 21:28)simoncn Wrote: To ensure this, it would be necessary to wrap the nonstandard marker element inside a <desc> element. A UPnP control point is required to accept this and ignore any elements within <desc> that it doesn't understand.

Quote:Ideally, the control point would have some way to flag a Browse request as either of the following:

1) the result of the request is for interactive presentation to the user

2) the result of the request is part of a recursive subtree search and not for interactive presentation to the user

If MinimServer receives a request of type 2), it would omit the extra items. For requests of type 1), the extra items would be included. If neither 1) nor 2) is specified, MinimServer would return the current "Hide Contents" container for the extra items.

If I understand it correctly, both these approaches are not mutually exclusive and both of these could be applied by MinimServer (given that there is a way to pass such an argument in a browse request for approach 2).

Please let me summarize approach 1) to see whether I understand this right:
MinimServer could mark the extra selection choice containers when sent to a control point. Standard control points ignore this nonstandard marker. A control point which makes use of this marker and receives a marked container, should:

1) ignore this container if it is the result of a recursive subtree search.
2) omit the 'Hide Contents' step (i.e. automatically select the second entry in the following step where 'Hide Contents' is the first entry) if it is the result of a request for an interactive representation.

simoncn · 11-09-2013, 09:33

(11-09-2013 09:24)winxi Wrote: If I understand it correctly, both these approaches are not mutually exclusive and both of these could be applied by MinimServer (given that there is a way to pass such an argument in a browse request for approach 2).

In theory they aren't mutually exclusive, but I don't think MinimServer should support both of them. The ideal solution would be a single simple extension that would eventually be adopted by a reasonable number of control points and possibly other servers.

Quote:Please let me summarize approach 1) to see whether I understand this right:
MinimServer could mark the extra selection choice containers when sent to a control point. Standard control points ignore this nonstandard marker. A control point which makes use of this marker and receives a marked container, should:

1) ignore this container if it is the result of a recursive subtree search.
2) omit the 'Hide Contents' step (i.e. automatically select the second entry in the following step where 'Hide Contents' is the first entry) if it is the result of a request for an interactive representation.

Yes, that's right. It might be possible to refine step 2) so that the ordering of the subselections doesn't need to be fixed. For example, the nonstandard metadata could say whch subselection to use.

winxi · 11-09-2013, 09:42

(11-09-2013 09:33)simoncn Wrote: In theory they aren't mutually exclusive, but I don't think MinimServer should support both of them. The ideal solution would be a single simple extension that would eventually be adopted by a reasonable number of control points and possibly other servers.

Thanks for these explanations! Given that there exists a way for control points to mark browse requests without violating the protocol, I think your second approach is preferable. It may be easier to implement for control point authors and thus it is more likely that it is supported by a reasonable number of control points.

simoncn · 11-09-2013, 10:20

(11-09-2013 09:42)winxi Wrote: Thanks for these explanations! Given that there exists a way for control points to mark browse requests without violating the protocol, I think your second approach is preferable. It may be easier to implement for control point authors and thus it is more likely that it is supported by a reasonable number of control points.

I agree. I will continue to investigate whether adding such a marker to Browse requests is possible.

winxi · 11-09-2013, 11:44

(11-09-2013 08:55)simoncn Wrote: Ideally, the control point would have some way to flag a Browse request as either of the following:

1) the result of the request is for interactive presentation to the user

2) the result of the request is part of a recursive subtree search and not for interactive presentation to the user

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