Roon is splitting an album - even though tags are consistent aross tracks

Roon Core Machine

NUC, 1.8 build 884

Networking Gear & Setup Details

NUC wired to unmanaged switch

Description of Issue

One of the things about Roon that baffles me is that sometimes, even though an album on my local storage is perfectly tagged, Roon will split it when it attempts to scan the content. Here is an example, and I can’t figure out why Roon is making such a mess of the scanning.


All tracks have the same album name and the same album artist, but Roon is messing up the scan

And here is an example of what Roon gives me for one of the newly added albums, i.e. a partial set of the tracks.

Now I know I can fix this manually by merging, but that’s not what I’ve paid for: the tracks are in the same album folder with the same album artist. Why is Roon getting this wrong?

How do they get there? Do you rip them into the watched folder or use a (slow) WiFi connection to copy over the files?
Such behavior was reported in the past and found to be related to slow transfers (Roon already scanning the files while transfer not finished.

1 Like

the files are on the SSD inside the NUC, a download from Qobuz.

So a possibly slow download directly into the watched folder then?

It’s best to download or rip the data onto another machine and then use a fast gigabit Ethernet connection to copy the data to the watched folder. Maybe also a force rescan (from the 3-dots menu in Roon Settings|Storage) after the data is in place may help sort things out?

To clarify, I never download directly to the NUC. The download was to a local desktop first, and then on to my NAS which is my primary storage. My home network is fully ethernet wired so direct transfers to the NUC SSD then run at around 100MB/sec. However, I had the Cloud Sync running on my Synology NAS to auto-mirror my master NAS music folder to the NUC, and it may have interrupted the copy in some way. I deleted the two partial imports from Roon and then did a direct copy via Windows Explorer, and I then had a single album in Roon. So thanks to your remarks I found a workaround - thanks. But it does raise questions for me that Roon’s import functionality may be a bit flaky, as the copy over to the SSD would have been pretty quick.

I can’t help you with that because I don’t have such a setup. If one has/wants to use ways to transfer data that have proven themselves leading to problematic results, I would create a folder (named import or new for example) outside the watched folder as a target for that transfer. Using your desktop after the transfer has finished to move the files into the watched folder should do the trick too (note: needs testing, might depend on the SMB version your desktop uses but I never had issues with that method).

Yes, I might look again at how I do this if Roon can be tripped up when scanning its local storage while syncing activity is still in progress, I just assumed it would be able to cope.

Pause it looking at storage, copy files then unpause.

Thanks, I was hoping for something more elegant, but at least there is a workaround. Also, in case any other Synology owners read this, I’ve noticed that the Cloud Sync app does not preserve the date/time stamp when copying, the target gets the date/time of the sync event, not that of the source file. So for any serious cloning job, not a contender in comparison to rsync.

This happens when some of the tracks get placed on a subfolderl. When using for example JRiver Media Center to convert from ISO (or one big FLAC for the entire album) to individual flac-files for each track, sometimes it actually puts some of the tracks on a sub-folder of the original folder of the remaining tracks; leaving Roon to split them in 2 (or more).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.