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
(03-04-2019 12:53)nbpf Wrote: [ -> ]But Linn Kazoo does offer "Play now", "Play later" and "More" options both for the Britten tracks and for the Schubert tracks while BubbleUPnP does so for the Schubert tracks but not for the Britten tracks!

Thus, no matter what they do, Linn Kazoo displays the leafs of a search tree consistently whereas BubbleUPnP displays logically equivalent results in different ways.

I do not think that blacklisting MinimServer would be a good solution. This would fix the consistency problem but one would be missing the standard controls ("Play now", "Play later" and "More") for sets of tracks that are legitimate results of a search query! Why shouldn't one be able to just play (enqueue, etc.) these tracks in much the same way as one is able to play (enqueue, etc.) a whole album?

From a user's perspective, there should not be first-class and second-class outcomes of a search query. The way a leaf is reached on the search tree should not have any impact on the way that leaf is displayed, in my view.

I agree that this solution would be preferable to "blacklisting" MinimServer.
(03-04-2019 22:47)simoncn Wrote: [ -> ]I agree that this solution would be preferable to "blacklisting" MinimServer.

BubbleUPnP only displays its album view when... the container is an album and defined as such by the media server (or inferred to be if AlbumArtist is present, really a special case ).
The generic container view with a list of tracks does not prevent to play/enqueue/etc. It's just not presented as an album. I have no plan to change this.
(04-04-2019 10:22)bubbleguuum Wrote: [ -> ]
(03-04-2019 22:47)simoncn Wrote: [ -> ]I agree that this solution would be preferable to "blacklisting" MinimServer.

BubbleUPnP only displays its album view when... the container is an album and defined as such by the media server (or inferred to be if AlbumArtist is present, really a special case ).
The generic container view with a list of tracks does not prevent to play/enqueue/etc. It's just not presented as an album. I have no plan to change this.
I have not been arguing that BubbleUPnP should present an album view when no album information is available!

But BubbleUPnP should present the play/enqueue/etc. menu for a set of tracks as it does it for a whole album. It is indeed possible to play/enqueue/etc. a set of tracks. But this requires opening the dot-dot-dot menu of the first track which is very annoying.

Notice that Linn Kazoo offers for a set of tracks the same play/enqueue/etc. controls as for full albums. This is perfectly logical: there is no reason why the controls for a set of tracks should be different from the controls for an album which is, indeed, just a set of tracks!
Since intelligent browsing is being discussed, I thought that when browsing down from Artist to album, if a single album is present for the artist then Minimserver should immediately descend to the album track list? Or did I imagine that? With Linn Kazoo I don't find the browsing to be that intelligent in that respect, though in others it is quite nice.
(04-04-2019 18:24)ac16161 Wrote: [ -> ]Since intelligent browsing is being discussed, I thought that when browsing down from Artist to album, if a single album is present for the artist then Minimserver should immediately descend to the album track list? Or did I imagine that? With Linn Kazoo I don't find the browsing to be that intelligent in that respect, though in others it is quite nice.
Intelligent browsing is a property of MinimServer, not of the control point. What we are discussing here are the controls (play now, enqueue, etc.) that a control point should display for a set of tracks that (for technical reasons that I do not fully understand) is (not yet) known to belong to the same album.
(04-04-2019 10:22)bubbleguuum Wrote: [ -> ]
(03-04-2019 22:47)simoncn Wrote: [ -> ]I agree that this solution would be preferable to "blacklisting" MinimServer.

BubbleUPnP only displays its album view when... the container is an album and defined as such by the media server (or inferred to be if AlbumArtist is present, really a special case ).
...

That does not appear to be the case. Both in the case of Britten (first screenshot) and in the case of Schubert (second screenshot) AlbumArtist is present. However, the two selections are displayed in a very different way!

[attachment=1693]

[attachment=1694]
In the Britten case, albumArtist is present on the tracks but not on the Work container. In the Schubert case, albumArtist is present on the tracks and also on the partial album container.
(04-04-2019 18:24)ac16161 Wrote: [ -> ]Since intelligent browsing is being discussed, I thought that when browsing down from Artist to album, if a single album is present for the artist then Minimserver should immediately descend to the album track list? Or did I imagine that? With Linn Kazoo I don't find the browsing to be that intelligent in that respect, though in others it is quite nice.

If you select an artist and the artist matches a single complete album, MinimServer shows an album container for the complete album. For many control points, this provides a convenient way to select the complete album container for playing. To show the track list for the album, you would need to click on the album container.

If you select an artist and the artist matches a single incomplete album (i.e., not all tracks on the album are by this artist), MinimServer shows a track list for the matching album tracks together with a ">> Complete album" selection for showing the complete album. This gives you the option to play any of the matching tracks and also enables you to view and play the complete album.

The first case shows the complete album and requires an extra step to show or play individual tracks. The second case shows the matching tracks and requires an extra step to show or play the complete album.
(04-04-2019 22:22)simoncn Wrote: [ -> ]In the Britten case, albumArtist is present on the tracks but not on the Work container. In the Schubert case, albumArtist is present on the tracks and also on the partial album container.
Which is odd because the two cases are perfectly equivalent from a logical point of view. The only difference is that, in the Britten case, one partial album matches the search whereas two partial albums do match the search in the Schubert case. This difference should not have any consequence on the attributes that are present or absent on the two containers. Either albumArtist should be present on both containers or it should be absent on both containers.

What seems to be missing here is the introduction of an attribute (albumArtist) on a container that is known to enjoy that attribute by but is missing it because of an optimization step. The optimization consists of not presenting to the user a page that would otherwise merely display 1 Album, 3 Tracks, etc. The optimization is good but it should be perfectly transparent to the user. In particular, it should not prevent albumArtist (and, perhaps, other relevant attributes) to be present on the container of the Britten tracks, it seems to me!
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.
Pages: 1 2 3 4
Reference URL's