multidisc albums, DISCSUBTITLE and GROUP tags: conflictual ?

[Andre Gosselin]

I have a multidisc classical album (6 CDs), all ripped inside the same directory and with all tracks tagged with the same Album value. DISCNUMBER tags are set to 1, 2, ... 6, reflecting the disc number inside the album. With this setup I get disc merging, as expected. However, tracks are renumbered. Since I would like to retain my original track numbers and the original album disc separation, I tried (as suggested in a previous post) to set a DISCSUBTITLE tag (CD 1, CD 2, etc) to the album tracks.

The album is composed of works divided into movements. I then went further and used the GROUP tag to group the album movements into their respective works (Symphony 1, Symphony 2, etc). I also defined the Group tag format as "Group.displayFormat={$group^^ - $album^ [^]}" in order to retain the original album title in the group names.

However, minimserver now crashes with a java exception each time I attempt to browse the album (I am using BubbleUPnP as a control point). See the attached log file.

The crash is systematic. To avoid it I have to remove either the GROUP tags (loosing a very intereting functionnality), the DISCSUBTITLE tags (loosing my original track numbers), or the DISCNUMBER tags (this removal has a side effect of disabling the DISCSUBTITLE tags, as can be seen in the log file). Having both GROUP and DISCSUBTITLE tags simultaneously set seems to induce a fatal bug in the server.

I hope I am not trying to achieve an impossible result.
Regards

[simoncn]

(20-10-2013 18:44)Andre Gosselin Wrote:  I have a multidisc classical album (6 CDs), all ripped inside the same directory and with all tracks tagged with the same Album value. DISCNUMBER tags are set to 1, 2, ... 6, reflecting the disc number inside the album. With this setup I get disc merging, as expected. However, tracks are renumbered. Since I would like to retain my original track numbers and the original album disc separation, I tried (as suggested in a previous post) to set a DISCSUBTITLE tag (CD 1, CD 2, etc) to the album tracks.

The album is composed of works divided into movements. I then went further and used the GROUP tag to group the album movements into their respective works (Symphony 1, Symphony 2, etc). I also defined the Group tag format as "Group.displayFormat={$group^^ - $album^ [^]}" in order to retain the original album title in the group names.

However, minimserver now crashes with a java exception each time I attempt to browse the album (I am using BubbleUPnP as a control point). See the attached log file.

The crash is systematic. To avoid it I have to remove either the GROUP tags (loosing a very intereting functionnality), the DISCSUBTITLE tags (loosing my original track numbers), or the DISCNUMBER tags (this removal has a side effect of disabling the DISCSUBTITLE tags, as can be seen in the log file). Having both GROUP and DISCSUBTITLE tags simultaneously set seems to induce a fatal bug in the server.

I hope I am not trying to achieve an impossible result.
Regards

Thanks for reporting this crash. From the crash log file, I see that the crash is caused by having a group that contains no tracks, which should not be possible. Some questions:

1) When you have GROUP / DISCSUBTITLE / DISCNUMBER enabled, are there any error messages or warning messages in the MinimServer log about problems with groups?

2) Are you attempting to create a group that spans multiple discs? This isn't supported, but it should produce a warning message instead of a crash.

If neither of these applies, please post a complete list of all the discs, tracks and groups. Many thanks!

[Andre Gosselin]

(20-10-2013 21:27)simoncn Wrote:  Thanks for reporting this crash. From the crash log file, I see that the crash is caused by having a group that contains no tracks, which should not be possible. Some questions:

1) When you have GROUP / DISCSUBTITLE / DISCNUMBER enabled, are there any error messages or warning messages in the MinimServer log about problems with groups?

2) Are you attempting to create a group that spans multiple discs? This isn't supported, but it should produce a warning message instead of a crash.

If neither of these applies, please post a complete list of all the discs, tracks and groups. Many thanks!

Simon,
The album does have a "Symphony No. 4" group which spans muliple discs (disc 1, tracks 5-6, and disc 2, tracks 1-2). The log file indicates :
"Sun Oct 20 13:24:15 Error: group spans multiple discs: Symphony No. 4"

Reading in your post that a group spanning multiple discs is not supported makes me feel sad, since the need for such groups is not a rare occurence at all. The 6-disc album in question shows 3 cases where a group needs to span multiple discs. Such a prohibition would, if fully enforced, somewhat hampers the usefullness of the group concept, and I would hesitate spending the time needed to do the tagging if some groups cannot be defined. However, as I mentioned in my original post, groups appear to work OK if DISCSUBTITLES tags are removed, irrespective of the fact that they span multiple discs or not (track numbers are changed because of merging, but at least groups are functional). So it appears that this prohibition can be lifted under some circumstances.

I hope that this problem can be solved.

Regards

[simoncn]

(20-10-2013 22:39)Andre Gosselin Wrote:  Simon,
The album does have a "Symphony No. 4" group which spans muliple discs (disc 1, tracks 5-6, and disc 2, tracks 1-2). The log file indicates :
"Sun Oct 20 13:24:15 Error: group spans multiple discs: Symphony No. 4"

Reading in your post that a group spanning multiple discs is not supported makes me feel sad, since the need for such groups is not a rare occurence at all. The 6-disc album in question shows 3 cases where a group needs to span multiple discs. Such a prohibition would, if fully enforced, somewhat hampers the usefullness of the group concept, and I would hesitate spending the time needed to do the tagging if some groups cannot be defined. However, as I mentioned in my original post, groups appear to work OK if DISCSUBTITLES tags are removed, irrespective of the fact that they span multiple discs or not (track numbers are changed because of merging, but at least groups are functional). So it appears that this prohibition can be lifted under some circumstances.

I hope that this problem can be solved.

Regards

A group can't span unmerged discs because a group is a containment structure and an unmerged disc is also a containment structure. You can see this containment hierarchy of Album > Disc > Group when browsing in a control point. When you merge the discs of an album, you are removing the discs from the album's containment hierarchy, leaving only the containment hierarchy Album > Group.

For solving this, one option is to merge the album discs, as you have discovered. Another option is to create another tag such as Composition or Work that you can use in place of Group to handle such cases. This Composition or Work tag doesn't create a containment structure, so there are no restrictions on how it can be used. You can then browse the index by Composition or Work to find and play any musical work that consists of multiple tracks, whether or not it is part of a group.

The crash that you reported will be fixed in the next release of MinimServer. In such cases, MinimServer will produce an error message and will show the tracks as ungrouped instead of crashing. Thank you for letting me know about this.

[DavidHB]

(21-10-2013 07:32)simoncn Wrote:  A group can't span unmerged discs because a group is a containment structure and an unmerged disc is also a containment structure ... one option is to merge the album discs, as you have discovered. Another option is to create another tag such as Composition or Work ...

I came across this issue (the error message, not the crash) a couple of days ago. After initially sharing the frustration expressed by André, I looked at the corrected structure in a Control Point and saw the point that Simon is making.

It is perhaps misleading to describe Groups spanning multiple discs as 'not supported'; 'just not possible' is nearer the mark, as Simon has now explained. In neither the real nor the virtual world can you place a container in more than one other container simultaneously and still retain its containment function. It might be worth mentioning in the User Guide that Groups cannot span multiple discs within the same album.

A third workaround (which in the end is the one I decided to use) is to split the offending Group(s) at the disc boundary/boundaries. That way, I can still access the individual discs of the album in the Control Point, which I sometimes like to do, while keeping the Groups as containers within each disc.

David

[simoncn]

(21-10-2013 12:21)DavidHB Wrote:  It is perhaps misleading to describe Groups spanning multiple discs as 'not supported'; 'just not possible' is nearer the mark, as Simon has now explained. In neither the real nor the virtual world can you place a container in more than one other container simultaneously and still retain its containment function. It might be worth mentioning in the User Guide that Groups cannot span multiple discs within the same album.

I have added a new paragraph documenting this limitation and other similar limitations.

[DavidHB]

(21-10-2013 14:00)simoncn Wrote:  I have added a new paragraph documenting this limitation and other similar limitations.

Thank you. I'm sure that will be helpful.

David

[Andre Gosselin]

(21-10-2013 07:32)simoncn Wrote:  

(20-10-2013 22:39)Andre Gosselin Wrote:  Simon,
The album does have a "Symphony No. 4" group which spans muliple discs (disc 1, tracks 5-6, and disc 2, tracks 1-2). The log file indicates :
"Sun Oct 20 13:24:15 Error: group spans multiple discs: Symphony No. 4"

Reading in your post that a group spanning multiple discs is not supported makes me feel sad, since the need for such groups is not a rare occurence at all. The 6-disc album in question shows 3 cases where a group needs to span multiple discs. Such a prohibition would, if fully enforced, somewhat hampers the usefullness of the group concept, and I would hesitate spending the time needed to do the tagging if some groups cannot be defined. However, as I mentioned in my original post, groups appear to work OK if DISCSUBTITLES tags are removed, irrespective of the fact that they span multiple discs or not (track numbers are changed because of merging, but at least groups are functional). So it appears that this prohibition can be lifted under some circumstances.

I hope that this problem can be solved.

Regards

A group can't span unmerged discs because a group is a containment structure and an unmerged disc is also a containment structure. You can see this containment hierarchy of Album > Disc > Group when browsing in a control point. When you merge the discs of an album, you are removing the discs from the album's containment hierarchy, leaving only the containment hierarchy Album > Group.

For solving this, one option is to merge the album discs, as you have discovered. Another option is to create another tag such as Composition or Work that you can use in place of Group to handle such cases. This Composition or Work tag doesn't create a containment structure, so there are no restrictions on how it can be used. You can then browse the index by Composition or Work to find and play any musical work that consists of multiple tracks, whether or not it is part of a group.

The crash that you reported will be fixed in the next release of MinimServer. In such cases, MinimServer will produce an error message and will show the tracks as ungrouped instead of crashing. Thank you for letting me know about this.

Thanks for your help.