Spinning wheel issue in Roon app persisting for a week (ref#12QNCL)

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· I've had a spinning wheel in my Roon app for about a week

Tell us about your home network

· Deco XE75

Hi @markp,

Thank you for your post. Does this persist if you restart RoonServer on this machine?

Diagnostics indicate that your library has several hundred unidentified tracks. Did you recently add a new storage location to Roon or import new local content? What do you see in Settings → Library → Roon can get hung on metadata resolution, file analysis (loudness/waveform), or library maintenance after a big add.

Please navigate to Settings → Library and select “Clean Up Library.”

We’ll watch for your response. Thank you!

Hi there – thanks for the reply.

Yes, I’ve restarted the Roon server at least three times.

There hasn’t recently been any “big” adds to my local directory. I would say at most it’s been 20 new files a week for at least a couple of months.

I actually think what may have started this WAS the “clean library” command?

Here’s what I see when I do that now:

Hey @markp,

Thanks for the follow-up! From a fresh Roon Server diagnostic report, we can see that the spinning wheel you saw was Roon’s UI reflecting an ongoing full metadata refresh of essentially the entire library. The _SpinQueue was processing ~50–70 tracks every 2–4 seconds, at that rate, 24,000 tracks takes many hours spread across nightly maintenance windows.

What triggered the full refresh? The logs show the _ReadyForFullRefresh condition fires when the metadata timestamp hasn’t been updated for longer than the UpdateInterval. The queue on Apr 18–19 was already very large (~23,600 tracks), suggesting the refresh had already been accumulating, likely triggered a week or more before the your complaint, possibly by:

  • The Roon v2.64 → v2.65 update on Apr 27 (which would trigger re-processing), though the queue precedes this
  • A prior update or a Clean Up Library operation resetting metadata timestamps on a large portion of the library

Can you now confirm the queue has fully drained? Is the spinning wheel gone now? The logs show the queue hit 0 recently.

Thanks for looking into this! Unfortunately the wheel is still spinning.

Sorry to hear this @markp.

What happens if you naviagte to your local watched folders and select the ‘Force Re-scan’ for each watched folder?

Recent server logs show the server was in a healthier state, the queue was actively processing and should_update=True — so the restart did help clear the condition. But the spinning wheel persists, which points to something else keeping it busy.

If the above doesn’t help, you may want to consider restoring from a backup taken before the issue started (approximately before April 22).

We’ll be monitoring for your reply :+1:

Thanks for the reply. I only have one shared folder and there’s fewer than 1000 files in it. It looks like this is where things are hanging because I’m unable to force rescan.

Hi @markp,

Thanks for the update! And if you disable and re-enable your watched folder, does that help at all?