rclone my library from its master location on a NAS (wouldn’t mind having rclone/ssh support on ROCK, thank you very much).
I often update files after improving metadata or lyrics, or adding new albums. At some point this leads to albums appearing in the wrong sort order (which was what triggered my Huey Lewis question from a while ago).
Restarting the docker container immediately fixes things.
The two numbers in the screenshot should make it possible for roon to see when the problem appears?
Thanks for writing in and sharing your report! From a fresh Roon Server diagnostic report, we can see the correlation with rclone is visible in import behavior. When you rclone an album, Roon logs a burst like this for the entire album at once:
undeleting deleted track with the same file key
importing file .../Chris_Rea/The_Road_To_Hell.../01_04_Texas.flac
undeleting deleted track with the same file key
importing file .../01_10_Tell_Me_There_s_A_Heaven.flac
... (all 10 tracks of the album)
The undeleting deleted track with the same file key lines are the tell. rclone is rewriting whole files (new inode/mtime, same path), so Roon sees every track as deleted-then-recreated rather than modified in place. That whole-album delete+re-add churn is what occasionally races the index and leaves a stale album_id behind in the SortedSet, producing the duplicate album entry.
This is something we’ll want our development team to take a closer look at. To help them, it would be essential to have a fresh copy of your current database, if possible.
Please create a fresh backup, and then zip up the backup folder, and share to our uploader here:
The way rclone writes files is the heart of this problem. When rclone updates a file, it typically writes to a temporary name and then renames it into place, which changes the file’s identity (inode/timestamp) on disk. Roon’s folder watcher sees that as “the old track was deleted and a brand-new track appeared” rather than “this track was edited.”
That said, in the meantime, see if you can mitigate the trigger with rclone flags. You can reduce it by making rclone touch as few files as possible:
Use rclone sync with --checksum instead of size/modtime comparison so unchanged files aren't rewritten.
Avoid --inplace-defeating behavior; rclone writes to a temp name then renames by default, which Roon sees as delete+create. Test whether --inplace reduces the churn for in-place metadata edits.
If only tags/lyrics changed, the entire-album re-import suggests every file's bytes are changing, does rclone rewrite whole files?
As I said, I frequently improve existing albums with metadata, covers or lyrics, or replace them with better versions.
All this happens on the NAS copy of my library, and once edits are done, I rclone everything over to the ROCK server. I switched from ‘native’ ROCK to docker, because there only was SMB on ROCK, and that didn’t work reliably. Now there’s SSH and I can rclone properly.
Now I only need to get roon to not stumble over my new files
Thank you for uploading the backup and for sharing your exact rclone command - both have been passed along to our development team together with the diagnostics.
One point worth clarifying: rclone itself isn’t creating duplicate files on disk. Your rclone sync keeps the destination as an exact mirror of the source, and the fact that a container restart immediately clears the duplicates confirms this - if there were a second physical copy, it would still be in your library after a restart. What you’re seeing is a stale entry in Roon’s album index caused by the delete-and-recreate churn described above, not duplicate content.
In the meantime, two small suggestions that may reduce how often this triggers:
Add --checksum to your sync command, so files whose content hasn't actually changed aren't rewritten. With your workflow (frequent tag/lyrics edits), this should noticeably cut down the number of files Roon sees as deleted and re-added on each sync.
After an interrupted sync, it's worth checking the destination for leftover partial files (find /mnt/flac -name "*.partial"), just to keep stray fragments out of the watched folder.
We'll follow up here once the development team has news on the underlying issue. Thank you for the detailed report - reproducible cases like this one are genuinely helpful.
