Nucleus One continuous rescan loop and unresponsive overnight issue (ref#EKQK4U)

Support Nucleus Support
1

Select your Nucleus model from the list below

· Nucleus One

I'm having trouble with my Nucleus hardware

· Other

Select the option that fits best

· The Nucleus boots up and I can connect to it in the Roon app without issue, but I have a question about configuration/storage/attached devices

Describe the issue

Title: Nucleus One — continuous rescan loop (~10s cycle) for 3 days; survives reboot, update, DB migration, storage disable/re-enable, and hard power cycle. Also one overnight full hang.
Setup: Nucleus One (latest build; DB migration completed 8 July), library on SMB share \\192.168.0.4\Music_Master on a Synology DS1522+ (DSM current). ~30,750 local tracks imported. Nucleus connects at SMB 2.1, wired GbE.
Symptom: Since 6 July, Storage shows "Scanning now…" restarting continuously — files-scanned climbs (e.g. 5,649 → 33,327) then resets, on roughly a 10-second cadence, indefinitely. Tracks imported stays constant at 30,754. Playback and browsing work normally throughout.
Context: On 6–7 July we completed a large library reorganisation (folder moves/renames, albumartist retags — all file operations verified clean). A staging folder inside the share was subsequently moved out entirely; the watched share now contains only music. The loop is unchanged.
Additionally: overnight 8–9 July (approx 23:00–09:00 IST) RoonServer became fully unresponsive — clients couldn't find the Core, web admin unreachable, though the device held its network link. Recovered only by hard power cycle.
Already tried, no effect: Core restart from web admin; Roon build update + database migration; ignored-path for the staging folder; storage location disable/re-enable (fresh walk, loop resumed immediately); removal of 1,757 legacy _roon_backup_ marker files from artist folders; staging folder physically moved off the share; all other SMB clients disconnected (verified in DSM — only the Nucleus connected); hard power cycle this morning.
Restore point available: clean Roon backup from 6 July, pre-reorganisation.
Happy to enable diagnostics — please pull logs from the Core; the overnight hang window should be captured.

2

Hey @Martin_Dooney,

Thanks for taking the time to write in and share your report! It’s good to see you on the community.

We appreciate the exceptionally detailed report and for everything you’d already tried as well, it saved us a lot of time, and the logs told a clear story. I pulled the diagnostics from your Roon Server, including the overnight window.

What’s happening

The “Scanning now…” loop isn’t a normal rescan, your library scan is crashing partway through and automatically restarting. Every cycle hits the same internal error in the storage scanner, and Roon Server retries after half a second, which is what produces the ~10-second loop you’re seeing (the file counter climbing and resetting). Because the scan never gets to finish, the status never clears and your imported-track count stays put at 30,754. That also explains why playback and browsing are unaffected, your library database is intact; it’s only the scanner that’s stuck.

The overnight unresponsiveness was a knock-on effect of the same loop. Running the scan thousands of times in a row gradually exhausted memory until the server locked up around 04:09 your time and stopped responding to clients and web admin, which is why only a hard power cycle recovered it.

The crash is landing at a consistent point each pass, which tells us it’s tied to something specific in the library rather than a general fault, and it lines up with the large reorganization you completed on 6–7 July.

What would help us most

To confirm where the trigger lives and to get you stable in the meantime, could you help with a couple of quick tests?

  1. To stop it running unattended and locking up again, please disable the Music_Master storage location in Roon Server settings for now. Playback of already-imported music will continue to work.
  2. If you're willing, temporarily move the folder Yello/Yello 40 Years/ out of the share, then re-enable Music_Master and tell us whether the loop stops or changes. The logs point to that area as the likely trigger. Roon’s having trouble with this specific folder/album.
  3. If that doesn’t help, as an isolation test, copy a few hundred tracks to a separate, new storage location, add that as a watched folder, and let us know whether that scan completes cleanly. If it does, it confirms the issue is in the share's current contents rather than the setup generally.
One note on the 6 July backup: restoring it reverts Roon's database but not the files on your Synology, so if the trigger is in the reorganized files on the share, a restore on its own probably won't clear the loop. Let's hold that option until the tests above narrow things down.

Separately, a few files in the library are flagged as corrupt or unreadable (some MP3s, an AIFF, and the cover-art files under Son Volt / Electro-Melodier). They’re not the root cause, but they’re worth cleaning up once we’re through this.

Thanks again for your patience and the great groundwork. Reply whenever you’ve had a chance to run the tests and I’ll take it from there. :+1:

3

Ran test 2: quarantined the entire Yello artist folder (not just 40 Years) to outside the share, restarted the Core. The loop continues unchanged — same ~10-second cycle, files-scanned climbing to ~33k and resetting, imports fixed at 30,754. One symptom did clear: the “9 not-associated” files no longer regenerate after cleanup. Stale _Pending_Delete version records also persist (paths removed from the share 30+ hours ago, surviving completed cleanups). Fresh diagnostics from tonight should show the crash point with Yello absent — presumably it’s moved or was never solely there. Happy to run the step-3 isolation test (fresh watched location, subset of tracks) tomorrow — advise whether you want that, or whether we go to the 6 July restore.

4

Hey @Martin_Dooney,

Thanks for running that so thoroughly, that was exactly the right test, and it moved us forward. You’re right that Yello isn’t the culprit: it’s completely absent from tonight’s logs and the loop is unchanged, so we can put that hypothesis to bed. My earlier read on that folder was wrong, and your quarantine test is what proved it.

The new logs point somewhere much more specific: your Playlists/ folder, not any album.

Here’s what’s happening. Every cycle is the exact same crash, 555 times across tonight’s session, always the same signature: the scanner is enumerating the file list, reaches Playlists/, and re-resolves all 37 of your .m3u files. Those playlist updates modify the in-memory file collection while the scan is still walking it, which throws an internal “collection was modified” error and kills the scan. Roon Server retries half a second later, the walk restarts from the top, and it repeats, that’s your ~10-second loop.

The reorganization on 6–7 July is what set it off. The playlists still reference the old track paths from before the folder moves and renames, so on every pass Roon tries (and fails) to reconcile the same 37 stale playlists. That’s also where the leftover errors you’ve been seeing come from.

This lines up with everything you’ve observed: it survives reboots, the build update, and the DB migration because the .m3u files never left the share; imports stay frozen at 30,754 because the scan never finishes; and the overnight hang was the crash/retry cycle running thousands of times until memory ran out.

So let’s target it directly rather than run the subset test:

  1. With Music_Master disabled (as you have it now), move the entire Playlists/ folder out of the share to somewhere off the watched location.
  2. Re-enable Music_Master.
I expect the scan to complete cleanly on the first pass and the loop to stop. Playback stays fine throughout.

Once we’ve confirmed that’s the trigger, we can look at rebuilding or repointing those playlists, the reorganization invalidated the track paths inside them, so they’ll need the paths corrected before they go back on the share. Happy to walk you through that.

Reply once you’ve had a chance to try it and I’ll take it from there. :folded_hands:

5

Loop stopped, scan completed first pass, imports moved 30,754 → 30,124, ghosts presumably clearing. Great.

6

Hey @Martin_Dooney,

Great to hear it confirmed clean scan and the import count settling at 30,124 lines up with exactly what we’d expect once those 37 stale playlists stopped colliding with the scanner.

Marking this resolved for now. Thanks for the thorough testing throughout — made this a fast diagnosis.