multidisc issues

[Andre Gosselin]

Hi,
I am using MinimServer 0.72, and found some weird behavior regarding the handling of multi-disc allbums. I will take as a concrete example three albums by Rached Podger in FLAC format, which are stored in my Contents directory as:
Podger, Rachel \
Bach- Double and Triple Concertos \ <-- 1 disc album
Vivaldi- LaCetra, Op. 9 \ <-- 2 discs album
Vivaldi- La Stravaganza, Op. 4 \ <-- 2 discs album

Inside each subdirectory, each music track is tagged with the Album tag set to the the subdir name, and the Track number tag set to "101", "102", ... for the tracks of the first disc, "201", "202", ... for the second one, etc. (I use this numbering scheme to be able to keep a reference to the disc number on devices which do not support the Disc number tag, for ex. the iPod., otherwise the tracks 01 will come first, all tracks 2 next, resulting in a confusing mix of the tracks among the album).

The problem I found is as follows. If in a 2 disc album I set the Disc number tag to value 1 for tracks of the first disc and to value 2 for those of the second disc, when browsing this album I get a merged list with tracks numbered "101", "102", ..., "118" for tracks of the first disc (which holds 18 tracks), and "319", "320", ..., "336" for those of the second disc (which holds 18 tracks). Notice the unexpected "hundred" digit here, and the weird jump from "118" to "319".

If I now reset the disc number tags from 1 to 3 (for tracks of first disc), and from 2 to 4 (for tracks of disc 2), browsing the album shows the track list as
>> Disc 3
101 ...
...
118 ...
>> Disc 4
201 ...
...
218 ...

I did a few tests to understand what was going on, and found that as long as value 1 is used as disc number on some tracks, MinimServer will merge the album track list as shown above. If value 1 is not used for disc number , then no merging will occur. I even tried this setup for the disc number tag: leave it unset for tracks of first disc, set to value '2' for tracks of second disc. I then get the following when browsing the album tracks:
>> [no disc]
101 ...
>> Disc 2
201 ...

Is all this a bug, or an undocumented feature of the software ?

I realized that avoiding the "merge" feature was in fact not such a bad thing after all, since it lets you exploit the disc number tag and see the CD number on multi-disc albums, without having to append the disc number to the the track titles (which I personnaly find ugly). Also, the way the tracks are currently renumbered in merged lists is not satisfying (maybe because of my track numbering scheme, but as explained above I need a way to keep a reference to the disc number on devices which do not support the disc number tag).

I think it would be nice if a property was added to allow/disallow list merges. When disallowed, albums where tracks are tagged with disc number values would be listed as :
>> Disc 1
...
>> Disc 2
...
In fact, this is what happens now except that you cannot use value 1 as disc number, and resort to the "no value" hack shown above.

I agree that merged lists can be usefull too. But now, you just cannot get them to work for multi-disc albums inside "compilation" boxed sets holding many albums. Take for example the "Karajan 1960s" box set comprised of 70+ discs, where the 2-disc album "Haydn: The Creation" are held on discs 53-54. Keeping a reference to the disc numbers is important to be able to easily refer to the booklet and obtain the recording details. But since the discs are not numbered beginning at 1, you cannot get MinimServer to output a merged list for this album, unless I have overlooked something.

What do you think ?

[simoncn]

(11-10-2013 19:54)Andre Gosselin Wrote:  Hi,
I am using MinimServer 0.72, and found some weird behavior regarding the handling of multi-disc allbums. I will take as a concrete example three albums by Rached Podger in FLAC format, which are stored in my Contents directory as:
Podger, Rachel \
Bach- Double and Triple Concertos \ <-- 1 disc album
Vivaldi- LaCetra, Op. 9 \ <-- 2 discs album
Vivaldi- La Stravaganza, Op. 4 \ <-- 2 discs album

Inside each subdirectory, each music track is tagged with the Album tag set to the the subdir name, and the Track number tag set to "101", "102", ... for the tracks of the first disc, "201", "202", ... for the second one, etc. (I use this numbering scheme to be able to keep a reference to the disc number on devices which do not support the Disc number tag, for ex. the iPod., otherwise the tracks 01 will come first, all tracks 2 next, resulting in a confusing mix of the tracks among the album).

The problem I found is as follows. If in a 2 disc album I set the Disc number tag to value 1 for tracks of the first disc and to value 2 for those of the second disc, when browsing this album I get a merged list with tracks numbered "101", "102", ..., "118" for tracks of the first disc (which holds 18 tracks), and "319", "320", ..., "336" for those of the second disc (which holds 18 tracks). Notice the unexpected "hundred" digit here, and the weird jump from "118" to "319".

This is correct. If you had tagged the first track of disc 2 as '1', it would be shown as 119, following on from the last track 118 on disc 1. Because you have chosen to tag this track as '201', it is shown as 319 (118+201).

Quote:If I now reset the disc number tags from 1 to 3 (for tracks of first disc), and from 2 to 4 (for tracks of disc 2), browsing the album shows the track list as
>> Disc 3
101 ...
...
118 ...
>> Disc 4
201 ...
...
218 ...

I did a few tests to understand what was going on, and found that as long as value 1 is used as disc number on some tracks, MinimServer will merge the album track list as shown above. If value 1 is not used for disc number , then no merging will occur. I even tried this setup for the disc number tag: leave it unset for tracks of first disc, set to value '2' for tracks of second disc. I then get the following when browsing the album tracks:
>> [no disc]
101 ...
>> Disc 2
201 ...

Is all this a bug, or an undocumented feature of the software ?

It is working as designed. You will get disc merging only if all disc numbers are present. So if you have discs 2 and 3 without disc 1, you won't get merging. Similarly, if you have discs 1 and 3 without disc 2, you won't get merging.

The reason for this is that the merging algorithm needs to use track number information from disc n-1 to compute the starting track offset for disc n. If disc n-1 is missing, this offset can't be computed.

Quote:I realized that avoiding the "merge" feature was in fact not such a bad thing after all, since it lets you exploit the disc number tag and see the CD number on multi-disc albums, without having to append the disc number to the the track titles (which I personnaly find ugly). Also, the way the tracks are currently renumbered in merged lists is not satisfying (maybe because of my track numbering scheme, but as explained above I need a way to keep a reference to the disc number on devices which do not support the disc number tag).

The disc merging feature is intended for multidisc albums with consecutive disc numbers (1; 2; etc.) and original track numbers for each disc (1; 2; 3; etc.). With your custom track numbering scheme, you won't get good results from disc merging.

Quote:I think it would be nice if a property was added to allow/disallow list merges. When disallowed, albums where tracks are tagged with disc number values would be listed as :
>> Disc 1
...
>> Disc 2
...
In fact, this is what happens now except that you cannot use value 1 as disc number, and resort to the "no value" hack shown above.

You can do this already by adding the suffix [Disc n] or (Disc n) to the ALBUM tag for each disc. This will give you a single album containing unmerged discs with '>> Disc n' separators. If you don't want to change the ALBUM tag, you can add the 'Disc n' information in a separate DISCSUBTITLE tag instead.

Quote:I agree that merged lists can be usefull too. But now, you just cannot get them to work for multi-disc albums inside "compilation" boxed sets holding many albums. Take for example the "Karajan 1960s" box set comprised of 70+ discs, where the 2-disc album "Haydn: The Creation" are held on discs 53-54. Keeping a reference to the disc numbers is important to be able to easily refer to the booklet and obtain the recording details. But since the discs are not numbered beginning at 1, you cannot get MinimServer to output a merged list for this album, unless I have overlooked something.

What do you think ?

The complete multi-disc album would need to be either merged or unmerged. You can't have some discs within the album merged and other discs unmerged. For this situation, you could have the album unmerged and retag the tracks from disc 54 as being on disc 53. A possible new feature for a future release of MinimServer would be to merge consecutive discs that are tagged with the same DISCSUBTITLE, so that tagging both discs 53 and 54 with "DISCSUBTITLE=Haydn: The Creation" would cause just these two discs to be merged.

A more serious problem with this particular album is that MinimServer is limited to a maximum disc number of 63 and a maximum track number of 1023.

[simoncn]

(12-10-2013 08:53)simoncn Wrote:  A more serious problem with this particular album is that MinimServer is limited to a maximum disc number of 63 and a maximum track number of 1023.

These limitations will be removed in the next release. The maximum disc number will be increased to 32767 and the maximum track number will be increased to 65535.

[Andre Gosselin]

Quote:I think it would be nice if a property was added to allow/disallow list merges. When disallowed, albums where tracks are tagged with disc number values would be listed as :
>> Disc 1
...
>> Disc 2
...
In fact, this is what happens now except that you cannot use value 1 as disc number, and resort to the "no value" hack shown above.

(12-10-2013 08:53)simoncn Wrote:  You can do this already by adding the suffix [Disc n] or (Disc n) to the ALBUM tag for each disc. This will give you a single album containing unmerged discs with '>> Disc n' separators. If you don't want to change the ALBUM tag, you can add the 'Disc n' information in a separate DISCSUBTITLE tag instead.

Thanks for this prompt reply. I now understand better how minimserver handles list merges.

Regarding your suggested use of the DISCSUBTITLE tag to get ">> Disc n" groupings avoiding the list merge feature, I would like to report the following. If I set DISCSUBTITLE=Disc n (for n=1,2,...), I do get ">> Disc n" groups when browsing to the album, with the original track numbers left untouched. But when I browse any specific ">> Disc n" heading, I get empty sets displaying no tracks at all. If I set DISCSUBTITLE to someting other than "Disc" (for ex. "DISCSUBTITLE=CD n"), the above issue disppears. I get ">> CD n" groupings which, when browsed into, display the correct list of tracks inside the group. It seems that "Disc" is a reserved word which cannot be used for the DISCSUBTITLE tag.

I admit this is a really mute point, but nevertheless worth mentionning.

Thanks again for this great piece of software.

[simoncn]

(12-10-2013 21:35)Andre Gosselin Wrote:  Thanks for this prompt reply. I now understand better how minimserver handles list merges.

Regarding your suggested use of the DISCSUBTITLE tag to get ">> Disc n" groupings avoiding the list merge feature, I would like to report the following. If I set DISCSUBTITLE=Disc n (for n=1,2,...), I do get ">> Disc n" groups when browsing to the album, with the original track numbers left untouched. But when I browse any specific ">> Disc n" heading, I get empty sets displaying no tracks at all. If I set DISCSUBTITLE to someting other than "Disc" (for ex. "DISCSUBTITLE=CD n"), the above issue disppears. I get ">> CD n" groupings which, when browsed into, display the correct list of tracks inside the group. It seems that "Disc" is a reserved word which cannot be used for the DISCSUBTITLE tag.

I admit this is a really mute point, but nevertheless worth mentionning.

Thanks again for this great piece of software.

I am not seeing this problem with DISCSUBTITLE=Disc n. A empty list can be caused by selecting ">> Hide Contents" from the ">> Disc n" menu, or by using a control point that isn't fully compatible with MinimServer. See Note 3 in this section for more information. Which control point were you using when you saw this problem? Had you previously selected ">> Hide Contents"?

Also, the main purpose of the ">> Disc n" link isn't to browse the disc contents (which are already visible at the album level) but to enable one-click selection of the entire disc contents for adding to the playlist.

[Andre Gosselin]

(13-10-2013 05:11)simoncn Wrote:  

(12-10-2013 21:35)Andre Gosselin Wrote:  Thanks for this prompt reply. I now understand better how minimserver handles list merges.

Regarding your suggested use of the DISCSUBTITLE tag to get ">> Disc n" groupings avoiding the list merge feature, I would like to report the following. If I set DISCSUBTITLE=Disc n (for n=1,2,...), I do get ">> Disc n" groups when browsing to the album, with the original track numbers left untouched. But when I browse any specific ">> Disc n" heading, I get empty sets displaying no tracks at all. If I set DISCSUBTITLE to someting other than "Disc" (for ex. "DISCSUBTITLE=CD n"), the above issue disppears. I get ">> CD n" groupings which, when browsed into, display the correct list of tracks inside the group. It seems that "Disc" is a reserved word which cannot be used for the DISCSUBTITLE tag.

I admit this is a really mute point, but nevertheless worth mentionning.

Thanks again for this great piece of software.

I am not seeing this problem with DISCSUBTITLE=Disc n. A empty list can be caused by selecting ">> Hide Contents" from the ">> Disc n" menu, or by using a control point that isn't fully compatible with MinimServer. See Note 3 in this section for more information. Which control point were you using when you saw this problem? Had you previously selected ">> Hide Contents"?

Also, the main purpose of the ">> Disc n" link isn't to browse the disc contents (which are already visible at the album level) but to enable one-click selection of the entire disc contents for adding to the playlist.

Hi,
You were right in suspecting a possible incompatibility with my control point.

I realized that the setting "DISCSUBTITLE=CD n" appeared to work on BubbleUPnP simply because I first happened to tap ">> CD n" then the album icon so to see what was there. Going back two steps and then long tapping ">> CD n" correctly let me enque the tracks grouped by the DISCSUBTITLE value. If I do not first browse to the album tracks using the above sequence (tapping ">> Disc n" , then the album), then enqueing tracks directly from the ">> Disc n" entry simply does not work. Having browsed to the album tracks seems to have caused BubbleUPnP to cache the list of tracks in memory, which it then used to queue tracks from the ">> Disc n" link.

In all fairness to BubbleUPnP, I tried three other Android control points (UPnPlay, MediaHouse, Foobar) which usually work pretty well. I found that those two exhibit pretty much the same behavior. Trying to queue straight from ">> Disc n" does not work, unless you first browse under the ">> Disc n" link.

This is a bit sad, because BubbleUPnP is a great control point (imho the best one for Android). Given that other control points behave similarly here, I do not see how to report the problem, if indeed there is one. Do you know of a control point capable of qeuing tracks straight from the ">> Disc n" link without first having to drill into it ?

Thanks for your help.

[simoncn]

(13-10-2013 18:06)Andre Gosselin Wrote:  Hi,
You were right in suspecting a possible incompatibility with my control point.

I realized that the setting "DISCSUBTITLE=CD n" appeared to work on BubbleUPnP simply because I first happened to tap ">> CD n" then the album icon so to see what was there. Going back two steps and then long tapping ">> CD n" correctly let me enque the tracks grouped by the DISCSUBTITLE value. If I do not first browse to the album tracks using the above sequence (tapping ">> Disc n" , then the album), then enqueing tracks directly from the ">> Disc n" entry simply does not work. Having browsed to the album tracks seems to have caused BubbleUPnP to cache the list of tracks in memory, which it then used to queue tracks from the ">> Disc n" link.

In all fairness to BubbleUPnP, I tried three other Android control points (UPnPlay, MediaHouse, Foobar) which usually work pretty well. I found that those two exhibit pretty much the same behavior. Trying to queue straight from ">> Disc n" does not work, unless you first browse under the ">> Disc n" link.

This is a bit sad, because BubbleUPnP is a great control point (imho the best one for Android). Given that other control points behave similarly here, I do not see how to report the problem, if indeed there is one. Do you know of a control point capable of qeuing tracks straight from the ">> Disc n" link without first having to drill into it ?

Thanks for your help.

At the present time, there is no alternative to opening the extra menu underneath ">> Disc n" to do the queueing. There has been some discussion about this issue in this thread.

[Andre Gosselin]

(13-10-2013 19:16)simoncn Wrote:  

(13-10-2013 18:06)Andre Gosselin Wrote:  Hi,
You were right in suspecting a possible incompatibility with my control point.

I realized that the setting "DISCSUBTITLE=CD n" appeared to work on BubbleUPnP simply because I first happened to tap ">> CD n" then the album icon so to see what was there. Going back two steps and then long tapping ">> CD n" correctly let me enque the tracks grouped by the DISCSUBTITLE value. If I do not first browse to the album tracks using the above sequence (tapping ">> Disc n" , then the album), then enqueing tracks directly from the ">> Disc n" entry simply does not work. Having browsed to the album tracks seems to have caused BubbleUPnP to cache the list of tracks in memory, which it then used to queue tracks from the ">> Disc n" link.

In all fairness to BubbleUPnP, I tried three other Android control points (UPnPlay, MediaHouse, Foobar) which usually work pretty well. I found that those two exhibit pretty much the same behavior. Trying to queue straight from ">> Disc n" does not work, unless you first browse under the ">> Disc n" link.

This is a bit sad, because BubbleUPnP is a great control point (imho the best one for Android). Given that other control points behave similarly here, I do not see how to report the problem, if indeed there is one. Do you know of a control point capable of qeuing tracks straight from the ">> Disc n" link without first having to drill into it ?

Thanks for your help.

At the present time, there is no alternative to opening the extra menu underneath ">> Disc n" to do the queueing. There has been some discussion about this issue in this thread.

Thanks for your help. Reading the contents of the thread you pointed me at, I realize this is a diffficult issue, and admit not being among those who fully understand the details of the ">> Hide Contents" container. My understanding is that there is nothing wrong here in the current behavior of BubbleUPnP. I hope I am not mistaken this time!
Regards,

[simoncn]

(13-10-2013 20:52)Andre Gosselin Wrote:  Thanks for your help. Reading the contents of the thread you pointed me at, I realize this is a diffficult issue, and admit not being among those who fully understand the details of the ">> Hide Contents" container. My understanding is that there is nothing wrong here in the current behavior of BubbleUPnP. I hope I am not mistaken this time!
Regards,

You are not mistaken. With the current UPnP specifications, it would be possible for MinimServer to provide either one-click opening/queueing of the whole album (without duplicate tracks) or one-click opening/queueing of each individual disc. Given this choice, I think it would be worse to show the extra "Hide Contents" menu when opening/queueing the whole album than it is to show this menu when opening/queueing an individual disc.