Possible Regression Bug: Roon doesn't display multiple discs in a multi-disc album

Core Machine (Operating system/System info/Roon build number)

Mac Mini, MacOS running 10.13.6, Roon Core 1.7 build 667

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Mini’s internal gigabit ethernet into Cisco gigabit switch (I don’t have the model offhand, and I’m not near it). Synology NAS containing media also attached to said switch, mounted to the Mac Mini

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

This happens with any connected device or connection type, wired or wireless.

Description Of Issue

When uploading a new album folder with multiple discs (each disc in their own folder inside the parent album folder), Roon in some circumstances no longer shows all the discs, and displays a seemingly random (often not Disc 1) single disc, and no amount of in-Roon Rescanning will fix it.

Steps to Reproduce

  1. Move your multi-disc album folder into Roon’s watch folder
    • In my case, I chose Smashing Pumpkins’ Mellon Collie and the Infinite Sadness 2012 remaster
    • each disc subfolder was named “Disc N - $NameOfDisc”
    • each FLAC file had correct embedded metadata for track number, title, and disc number (X of Y)
  2. Wait for Roon to process the album
  3. Notice that not all tracks are shown

What I Expected

I expected all the tracks to be scanned and shown within the Roon UI.

Notes

  • When Roon encounters the album, it processes the folder and the subfolders (you can verify this by the number of tracks it thinks it sees, and how many it has processed in Settings > Library
  • The embedded file metadata for each individual track is ‘correct’ in the sense that it shows “disc X of Y” with the same album title.
  • This is different behaviour from the longstanding OS bug where sometimes remote changes in the remote filesystem weren’t registered by the host OS and passed to Roon
    • A workaround for this was to create a new folder in that directory on the host, which would force Roon to re-scan the directory and ‘pick up’ the missing files. This workaround does not fix the current issue
  • This bug doesn’t usually crop up if the subfolders are called simply “Disc 1”, “Disc 2”, etc.
    • However, simply renaming them after the bug has occurred does not
      1: cause a rescan
      2: does not cause the missing tracks to be shown in Roon
    • The bug will always occur if the disc folders have arbitrary names, even if prefixed with “Disc N” (ex: Disc 1 - Dawn to Dusk; Disc 2 - Twilight to Starlight
  • There is a current workaround for this bug
    1. Remove the entire album from the watch folder
    2. Go into Settings > Library, and choose “Clean Up Library”
    3. Tick the “Clean up N Deleted Files”, Choose "Clean Up Library
    4. Make sure your folders are specifically labelled “Disc N” and nothing else.
    5. Roon should now correctly rescan the album and all files should be visible.

Hope this isn’t changed before roon re-engineers box-set navigation. There are many feature requests going back at least 4 years now to improve box-set handling so clearly it has an extremely low priority.

You may not have come across this but many Classical and Jazz box sets can run to 30-60 CD’s, are often 100 or more CD’s and in extreme cases more than 200 CD’s. Essentially this makes the current roon box-set UI un-navigable.

One common work-around is to use the “feature” that roon does not usually recognise CD folders with descriptive title text (as in your example) as part of the same box-set as a deliberate strategy to split the box-set into individual albums with individual art-work in roon.

As you point out this splitting of the box-set does not usually happen when the CD’s are simply named CD1, CD2, CD3 . . . etc. (or similar) without any descriptive text in the CD folder names. In fact in the knowledge base this is the recommendation. If you are expecting roon to support box-set clumping and identification then the knowledge base specifically warns that you should not organise your box-sets with descriptive CD folder names.

You can always “merge” split box-sets by highlighting the individual albums and using the “merge albums” feature in the album editor if it is important to you to both retain the descriptive folder names and then navigate the box-set as a single album in roon.

That is, it is usually not necessary to go through the deleting, re-naming, library clean up and re-identification work-around process you describe. Sometimes roon does get confused and that will be necessary, but a simple merge will work in most cases (provided you have numbered the disks in your tags).

There are many, many feature requests, going back many years asking roon to improve box set handling and navigation. This may never be addressed. In the meantime, to my knowledge, the feature that roon (in general) handles box-set identification differently depending on whether there are CD folder descriptions or not has been there since at least roon 1.2 and maybe before. In the absence of a proper fix for box-set handling (and scaling in general in the UI, eg. composition handling), the present compromise at least provides some flexibility. It seems to be a good example of one man’s “feature” being another man’s “bug”.

1 Like

I think you’re missing the point of my bug report. The bug isn’t about whether or not the UI is unusable with a large number of discs in a set, nor is it about personally categorising subfolders based on a name. This bug is new, introduced with the new build, that causes Roon to mishandle albums that happen to have subfolders, and that manually changing the files/folders on-disk no longer triggers a re-scan/reveal in the app as it used to in prior builds, and that a ‘scorched earth’ workaround is needed to get it working again.

Strange. I am going through the process of re-importing a largish library I first imported about 2 years ago and I am not noticing this issue (although I have noticed other changes). I have several copies of that Pumpkins album and cannot reproduce your issue in Windows 10. Maybe there is a difference with MacOS?

If I understand you correctly, your issue is that albums with sub-folders are no longer handled correctly by roon and that renaming labelled CD folders in multi-disc sets is not triggering a re-scan? I am not seeing this and cannot reproduce it. One possibility is I have a different naming convention to you and others probably also have different variations also. So for example, I will number disks 1/5 rather than 1 of 5 as that is what my tagger (mp3tag) does when it autonumbers albums. I also use a convention CD1, CD2 etc. rather than Disc 1, Disc 2.

So starting with:

CD1 - Dawn to Dusk
CD2 - Twilight to Starlight
CD3 - Morning Tea
CD4 - High Tea
CD5 - Special Tea

As expected, roon does not group the CDs into a single album. I then tried renaming the folders (Windows 10) to:

CD1
CD2
CD3
CD4
CD5

This triggers a rescan and roon groups the CDs and identifies them as a 5CD release.

Initially I thought this may have something to do with my different disk numbering and naming conventions. So after clearing the library I repeated the exercise numbering the discs 1 of 5 etc. and labelling the folders:

Disc 1 - Dawn to Dusk
Disc 2 - Twilight to Starlight
Disc 3 - Morning Tea
Disc 4 - High Tea
Disc 5 - Special Tea

Renaming the folders Disc 1, Disc 2 etc. (Windows 10) also triggers a roon rescan and roon groups and identifies a 5CD release.

Maybe there is another difference. IOS vs. Windows?

Hi @CM_Harrington,

Is there any files in particular that trigger this issue or does it not seem to be dependent on file type? Does the issue occur only with FLAC or MP3 for example?

Can you please share a few screenshots of the process you use?

What happens if you try the same process and have the files on the Core local HDD instead?

I’ll see what I can do this weekend.

As for the local drive, I don’t know, as I don’t have a Roon Library on the boot drive of the Mini (Core) (I’d have to add one).

It doesn’t seem to matter re: file type. These were FLAC files, but it happened with another multi-disc collection that I originally had as MP3s but then replaced with FLACs. That’s why I sent in the bug report… it wasn’t just that first incident.

Thanks for following up!

1 Like