· My Roon server gets stuck on “Rescanning files.” It shows rescanning 1 file to update the metadata, but it never ends and the scan indicator keeps spinning all day.
A few more details: - updated to the latest Roon version: 2.65 (build 1653) - I have uploaded my Logs to the Logs Upload Server running - Rock on intel nuc - no VPN - Goole mesh router - I've had this issue intermittently but now it will not go away
We’ve enabled diagnostics for your system. Please reboot your Roon Server, then let us know once that’s done so we can review the logging to see if there are any clues. Thanks!
Thanks for the update, sorry to hear you’re still seeing some scanning going on.
We were able to review a fresh diagnostic from your ROCK, and observed no issues tied to a specific single track, but rather, the logs show Roon’s updatemetadata engine queued your entire library (~37,800 tracks) for a metadata refresh from Roon’s servers. The queue was still at ~18,500–28,600 tracks in the April 25 logs, meaning the process takes many hours to complete. Roon processes these in batches of ~50–75 tracks every few seconds, while continuously making calls to metadataserver.roonlabs.net.
Roon’s metadata had gone ~23 hours without a refresh cycle, well past due. When it finally restarted, it re-queued everything. This likely corresponds to a period where the server had lost internet connectivity or the metadata service was unreachable.
How are things looking now? If the spinner persists after the queue fully drains, go to Settings → Library → Clean Up Library, then do a Force Rescan. This is the “clean slate” approach after the underlying issue is resolved.
Hi Roon Support team, thank you very much for your response, that explanation makes sense!
One important pattern I should clarify: the spinner does eventually stop, usually after being left overnight for 12+ hours. However, if I reboot the ROCK/Roon server, the spinner returns again and then takes another ~12+ hours to clear.
So it does not appear to be permanently stuck, but it does seem like every reboot / software update causes Roon to re-enter a very long metadata refresh/scanning state across the library.
Does that suggest the metadata queue is being re-triggered from scratch after each restart? Is there anything I should check on the ROCK/network side to prevent the full-library metadata refresh from being re-queued every time the server restarts / software update?
I wanted to confirm whether this behavior is expected for a ~37,800-track library or whether it points to something that still needs investigation.
It’s normal for reboots to trigger some background work and “housekeeping” in your server that would normally take place during the scheduled interval for Background Work. See here for some context on that:
That said, 12 hours is a long re-indexing time for a library with under 100,000 tracks, and there are two likely explanations:
The first possibility is that a non-fatal network error is repeating and congesting the metadata update queue. Roon checks cloud servers for available new data, and it has to repeat those requests.
One way to mitigate this is to ensure that the DNS server in your router is reliable; we recommend assigning Cloudflare (1.1.1.1) as the DNS primary server in your router settings admin page.
We see evidence of this happening in logs, but it might not be the only (or dominant) reason for the slow scanning if it consistently resolves after 12 hours.
A second possibility is that something in your library (or multiple things) are choking up library metadata updates and/or audio analysis. This can happen at ~38k tracks if you have a large amount of various artists compilations, bootleg files (concert recordings, non-canonical releases, etc), or custom tagging. Sometimes, it’s a single offending album that Roon can’t identify. Restarts in particular tend to trigger Roon to “try again” at unidentified content.
Here’s what I recommend. Reboot RoonServer and let us know the approximate time that it took to stop scanning. We’ll gather logs from that particular reboot event and look for patterns that can determine if problem #1, problem #2, or both are causing this issue for you. We’ll provide a menu of options from there.
I rebooted the ROCK/RoonServer at approximately 7:30 AM on May 11. The metadata/scanning process was still running when I last checked at approximately 10:30 PM that evening, so it had been running for at least 15 hours. When I woke up on May 12th the process was completed.
For additional context, the library does include a lot of various artist compilations, DJ mixes, ripped CDs, international music, Bandcamp downloads, and some less mainstream albums. Some of the DJ mixes are also quite long — in some cases 3–5 hours continuous in one file — so it is very possible that the second scenario you mentioned is relevant as well.
Hopefully that gives you a clear reboot window to review in the logs. Please let me know whether the issue appears to be more network/DNS-related, library-content-related, or a combination of both.
I’m curious, if you head to your Roon Settings > Library > Scroll down to background work, what time do you have scheduled?
From a fresh diagnostic report, we see every identification and metadata-refresh check logged is_within_window=False, should_update=False.
The system loaded the library into RAM immediately and was fully operational for playback, but the deep identification/metadata work was intentionally deferred. It may be the case that the background scheduler is set for the default time of 1am-5am local time.
Let me know if this makes sense and what your settings are looking like.
This could definitely be tripping things up as well, but we didn’t see any obvious errors in relation to the files you mention here.
As a side test, you could always temporarily move your questionable files into an unwatched folder, then perform a library cleanup and see if you experience the same situation.
I checked Settings → Library → Background Work, and the current schedule is set to 1 am - 5 am.
Based on your note, it sounds like the metadata/scanning activity I was seeing during the day may not have been actively running the entire time, but instead may have been queued and waiting for the scheduled Background Work window. That would make sense, especially since the spinner typically clears overnight.
For now, I have not moved any files out of the watched folder or run a cleanup, as I did not want to introduce another variable before confirming the Background Work schedule with you.
Please let me know if you’d suggest adjusting the Background Work window first, or if you’d still like me to test temporarily moving the more questionable files out of the watched folder.
