MinimServer Forum

Full Version: Intelligent browsing: inconsistent behavior?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
(05-04-2019 10:33)simoncn Wrote: [ -> ]There are two optimization steps happening here. The first optimization is for MinimServer to display the list of tag values (Work tags in this case) without analysing all the files that match these tag values, which would take a long time. The second optimization is for MinimServer to show the list of tracks immediately when all tracks that match a tag value (Work in this case) are part of a simple album, instead of showing 1 album, 3 tracks. Both these optimization steps apply to browsing by other tag values as well as by Work.

Without the first optimization, browsing by any tag that has a large number of values would be much slower. An important feature of MinimServer is its speed when browsing a large library. Making this step slower in all cases would not be acceptable to most users.

Without the second optimization, every browsing selection that matches multiple tracks in a single album would require an extra browsing step to view these tracks. Requiring this extra step in all such cases would be a problem for many users.

MinimServer has been designed to handle this situation for tracks that are part of a single work by supporting work grouping using the Group tag. This provides the extra container that is needed to make this scenario work smoothly with BubbleUPnP. I don't think there is any other solution that doesn't have unacceptable adverse effects for other scenarios and other users.
Thanks, I am going to try using the Group tag and report. What I do not understand is why Linn Kazoo works perfectly

[attachment=1696] [attachment=1697]

whereas BubbleUPnP fails to present a consistent view of the search results, as previously shown.
(05-04-2019 10:33)simoncn Wrote: [ -> ]There are two optimization steps happening here. The first optimization is for MinimServer to display the list of tag values (Work tags in this case) without analysing all the files that match these tag values, which would take a long time. The second optimization is for MinimServer to show the list of tracks immediately when all tracks that match a tag value (Work in this case) are part of a simple album, instead of showing 1 album, 3 tracks. Both these optimization steps apply to browsing by other tag values as well as by Work.

Without the first optimization, browsing by any tag that has a large number of values would be much slower. An important feature of MinimServer is its speed when browsing a large library. Making this step slower in all cases would not be acceptable to most users.

Without the second optimization, every browsing selection that matches multiple tracks in a single album would require an extra browsing step to view these tracks. Requiring this extra step in all such cases would be a problem for many users.

MinimServer has been designed to handle this situation for tracks that are part of a single work by supporting work grouping using the Group tag. This provides the extra container that is needed to make this scenario work smoothly with BubbleUPnP. I don't think there is any other solution that doesn't have unacceptable adverse effects for other scenarios and other users.


@nbpf

Now I understand what you mean by no "Play/Enqueue" buttons.

First screenshot would have a Play and Enqueue button if it the ">>> Complete album" container was not here (if it was just a list of tracks). Reason is that it is a rare scenario (usually, containers contain either only tracks or only containers), where it is unclear if a play/enqueue button would also recursively process the ">>> Complete album" container. Since this is a generic container, BubbleUPnP has no idea of how deep the hierarchy is. A solution would be to only process displayed tracks but you can bet that at least some user would find it illogical because "reasons". Maybe I'll add these buttons though for that case (generic folder containing mixed items + containers).
Other solution would be for MinimServer to set albumArtist on the container, but from what I understand this is not easily doable.
MinimServer uses special logic to ensure that any container starting with >> will produce no tracks if included in a recursive scan.
OK, I've made a simple change resulting in screenshot 1 having Play/Enqueue buttons in the top bar. It's not recursive. It looks like any generic folder containing a list of tracks, for example a "<n> items" container.

It will not be consistent with screenshot 2 that still uses album view, but at least there are easy to access Play/Enqueue buttons.

Other solution on my side (for consistency) would have been to "intelligently" determine if a generic container is an album once it is fully loaded and display it as such (with the header and all), but I'd rather not do that as it is not entirely trivial and could have undesired effects.
(05-04-2019 19:27)bubbleguuum Wrote: [ -> ]OK, I've made a simple change resulting in screenshot 1 having Play/Enqueue buttons in the top bar. It's not recursive. It looks like any generic folder containing a list of tracks, for example a "<n> items" container.

It will not be consistent with screenshot 2 that still uses album view, but at least there are easy to access Play/Enqueue buttons.

Other solution on my side (for consistency) would have been to "intelligently" determine if a generic container is an album once it is fully loaded and display it as such (with the header and all), but I'd rather not do that as it is not entirely trivial and could have undesired effects.
Thanks, for your reference, here are the current outcomes of BubbleUPnP, Linn Kazoo and mconnect for the same search:

[attachment=1698] [attachment=1699] [attachment=1700] [attachment=1701] [attachment=1702] [attachment=1703]
By the way, what speaks against BubbleUPnP behaving exactly as Linn Kazoo? That seems the most logical behavior given that the Britten and the Schubert results are logically perfectly equivalent.
(05-04-2019 19:27)bubbleguuum Wrote: [ -> ]OK, I've made a simple change resulting in screenshot 1 having Play/Enqueue buttons in the top bar. It's not recursive. It looks like any generic folder containing a list of tracks, for example a "<n> items" container.

It will not be consistent with screenshot 2 that still uses album view, but at least there are easy to access Play/Enqueue buttons.

Other solution on my side (for consistency) would have been to "intelligently" determine if a generic container is an album once it is fully loaded and display it as such (with the header and all), but I'd rather not do that as it is not entirely trivial and could have undesired effects.
I am afraid I do not see any change!
(05-04-2019 19:27)bubbleguuum Wrote: [ -> ]OK, I've made a simple change resulting in screenshot 1 having Play/Enqueue buttons in the top bar. It's not recursive. It looks like any generic folder containing a list of tracks, for example a "<n> items" container.

It will not be consistent with screenshot 2 that still uses album view, but at least there are easy to access Play/Enqueue buttons.

Other solution on my side (for consistency) would have been to "intelligently" determine if a generic container is an album once it is fully loaded and display it as such (with the header and all), but I'd rather not do that as it is not entirely trivial and could have undesired effects.

Has the change made it to version 3.2.3 (arm64-v8a)? I received a BubbleUPnP update today but I do not see any changes in screenshot 1. Best, Nicola
Pages: 1 2 3 4
Reference URL's