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
The author of BubbleUPnP has informed me that a container is displayed with a Play button if its UPnP container type is musicAlbum and not if its UPnP container type is a generic container, with one exception. If the container is a generic container and its metadata includes an albumArtist value, it is displayed with a Play button. The containers for the Schubert works are generic containers with an albumArtist value and the container for the Britten work is a generic container without an albumArtist value. This is why BubbleUPnP displays the containers for the Schubert works in a different format than the container for the Britten work.
(02-04-2019 16:19)simoncn Wrote: [ -> ]The author of BubbleUPnP has informed me that a container is displayed with a Play button if its UPnP container type is musicAlbum and not if its UPnP container type is a generic container, with one exception. If the container is a generic container and its metadata includes an albumArtist value, it is displayed with a Play button. The containers for the Schubert works are generic containers with an albumArtist value and the container for the Britten work is a generic container without an albumArtist value. This is why BubbleUPnP displays the containers for the Schubert works in a different format than the container for the Britten work.
But why is the container for the Britten work a generic container without an albumArtist value? The Britten tracks have an associated albumArtist value in exactly the same way as the Schubert tracks do!

[attachment=1689]

[attachment=1688]
When you browse by Work from the top level, there can be many hundreds or even thousands of results. MinimServer shows a list of all these works and this list displays quickly because MinimServer is using information that is entirely held in memory. The containers in this list do not include albumArtist information because this would require analysing all the files that match all these works. Doing this would require a lot of processing including disk I/O and would make it much slower to display the list of works.

As soon as you select one of these works, MinimServer analyses the files for the selected work (a much smaller number of files) and sends the metadata for these files to the control point, including albumArtist information. Unfortunately, BubbleUPnP is ignoring this metadata when deciding how to display the files for the work.
(03-04-2019 09:08)simoncn Wrote: [ -> ]As soon as you select one of these works, MinimServer analyses the files for the selected work (a much smaller number of files) and sends the metadata for these files to the control point, including albumArtist information. Unfortunately, BubbleUPnP is ignoring this metadata when deciding how to display the files for the work.

BubbleUPnP makes that specific object.container => object.container.album.musicAlbum promotion at a point it does not know the tracks of the containers (Browse action just return a container list at this point).
That's why it looks at just albumArtist of the container. There is no way to change the container class id afterwards (when the container is loaded and tracks are known) and that's the object.container.album.musicAlbum that entirely determine the presentation of the album view of a container (album header + big play button).

Would it be feasible for MinimServer to use object.container.album.musicAlbum on these partial album containers ?
See my previous post. When this container is sent to the control point, MinimServer doesn't know it represents the contents of a single album. This is only known when MinimServer loads its contents after the user has selected it.
Ah ok, that makes sense.
So why does Linn Kazoo in this specific case present a consistent view of the two subsets of tracks (Britten and Schubert) while BubbleUPnP does not?
(03-04-2019 12:12)nbpf Wrote: [ -> ]So why does Linn Kazoo in this specific case present a consistent view of the two subsets of tracks (Britten and Schubert) while BubbleUPnP does not?

Because (unlike BubbleUPnP) it doesn't try to infer that a generic container is an album container based on the presence of "Album Artist" metadata associated to the container.
BubbleUPnP do this to workaround some media servers not using the proper class id on containers holding an album, so it can properly display them as albums. I will probably blacklist MinimServer from this behavior so you'd have consistent views (generic list of tracks). Other solution would be for MinimServer to not set an Album Artist on these generic folders.
(03-04-2019 11:30)simoncn Wrote: [ -> ]See my previous post. When this container is sent to the control point, MinimServer doesn't know it represents the contents of a single album. This is only known when MinimServer loads its contents after the user has selected it.
The only difference between the Britten and the Schubert case is that in the first case there is exactly one album whose content partially matches the search whereas in the second case there are two.

Why does the container sent to the control point know that it represents the contents of a single album in the Schubert case but not in the Britten case? From a logical point of view the two cases are perfectly equivalent and should have equivalent representations, in my view. This is also the case with Linn Kazoo (Schubert-like output) and mconnect (Britten-like output) but with BubbleUPnP the two cases are represented in a different way.

From a user's perspective, the expected behavior is that of Linn Kazoo and it would be nice if this behavior could be taken as a specification for the way a control point shall display a subset of tracks that 1) match a search and 2) belong to the same album.
(03-04-2019 12:21)bubbleguuum Wrote: [ -> ]
(03-04-2019 12:12)nbpf Wrote: [ -> ]So why does Linn Kazoo in this specific case present a consistent view of the two subsets of tracks (Britten and Schubert) while BubbleUPnP does not?

Because (unlike BubbleUPnP) it doesn't try to infer that a generic container is an album container based on the presence of "Album Artist" metadata associated to the container.
BubbleUPnP do this to workaround some media servers not using the proper class id on containers holding an album, so it can properly display them as albums. I will probably blacklist MinimServer from this behavior so you'd have consistent views (generic list of tracks). Other solution would be for MinimServer to not set an Album Artist on these generic folders.
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.
Pages: 1 2 3 4
Reference URL's