Blue circle spinning continuously despite 'complete' status in music library (ref#I5R9KW)

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

· My "adding to music to library" blue circle has been spinning for about 4 weeks now, although It says "complete"

Tell us about your home network

· netgear

Hi @david_klipper,

Thanks for writing in and for sharing your report!

If you haven’t yet, I’d safely stop Roon Server from running, and fully reboot your server machine.

Then, see if the same behavior occurs. We’ll be monitoring for your reply, thank you! :raising_hands:

This has been done more times than you could conceivably imagine. This does not do anything.

@benjamin

I tried to upload a video, however, this system will not allow that.

@benjamin

It is STILL spinning.

Hey @david_klipper,

Thanks for the update! Sorry to hear you’re still having issues! To confirm, what is your total number of tracks? A fresh Roon Server diagnostic shows that Roon is tracking 143,730 tracks (with 4,893 hidden) and 8,705 albums. This massive difference suggests Roon might be indexing a much larger collection than expected, perhaps including your entire TIDAL library or a duplicate storage path.

The logs show “endmutation” tasks taking upwards of 101 to 135 seconds to complete. Normally, these should take milliseconds or a few seconds. This indicates the database is struggling to commit changes, likely due to the volume of data or underlying file issues.

Some next steps for you to investigate:

Go to Settings > Library > Skipped Files. If Roon is repeatedly trying and failing to scan a corrupt file, it will cause the spinner to persist. If you see a long list here, it may point to specific files that need to be removed or repaired.

Investigate the Track Count:

  • Since the log shows 143k tracks, check Settings > Storage to ensure you don't have redundant folders watched (e.g., both a parent and a sub-folder).
  • Also, check if you have "Sync TIDAL Library" enabled, as a very large TIDAL collection will keep the spinner active as it refreshes metadata for those 100,000+ extra tracks.

With that, we’re also seeing hundreds of corrupt files during the scanning process. I would use a third-party app like dbpoweramp to analyze the health of your tracks, and make any repairs to corrupt files.

Roon is also hitting a wall with specific .m4a files in your King Crimson folders.

  • Even though Roon supports .m4a, this container can hold different types of audio. On Linux-based servers (like a SonicTransporter or NUC), Roon often relies on specific system codecs to "unpack" these files.
  • What to check: These files might be ALAC (Apple Lossless) or encoded with a codec your Server doesn't currently recognize. They could also be old files with DRM (Digital Rights Management) from the early iTunes days, which Roon cannot play.

Hope this helps, thanks David! :+1:

Benjamin

Thank you.

Is it possible to speak with someone on how to fix this stuff? I am not a young tech person.

How to I clear the skipped files? The list is really long.

All of King Crimson is in .m4a. I will convert this to flac.

I have dbpoweramp and perfecttunes. How do I use that to analyze my tracks? I do not want to make a mistake and delete stuff. Over 4T is live recordings, so they will have no “proper” metadata in accurateRip.

I do have 143K tracks, it is about 7.1T currently. Over 4T is live recordings, so they will have no “proper” metadata in accurateRip.

I have never used tidal or other streaming services, I have everything on a sonictransporter :slight_smile:

Thank you.

David

I was able to clear out the skipped files. Most of them were .mp3 text with zero bytes. That folder is now empty.

I only have 1 folder in storage. That was a mistake of mine years ago, Andrew at SGC helped me with that.

I did this yesterday evening. It is still spinning this morning as I type.

Ben

It is still spinning and my system still randomly stops playing.

I have restarted everything: Router, SonicTransporter, Roon and all of my Roon endpoints.

The “skipped files” tab is empty.

The “clean up library” is at 0 except for the 6 files that are not associated with a storage location. This has been like this for years and will not delete.

Cache has been cleared, again.

Hi @david_klipper,

Thanks for the follow-up! We’re only offering support via the community at this time, so you’re in the right spot!

This is a key piece of information, as Roon will continuously try to identify your content unless you tell it otherwise. That said, The logs tell the complete story here.

On April 12 at ~2:14 AM, your 143,735-track metadata queue finished processing successfully — it hit zero. Then at 8:33 AM the same day, Roon restarted (likely the SonicTransporter’s scheduled maintenance window), and the entire queue of 143,735 tracks was immediately re-enqueued from scratch. As of your most recent log (April 15, ~3:40 AM), it still has ~42,000 tracks remaining.

The root cause is the 4,193 albums stuck in the identification retry queue. Every single log entry from the past three days shows this same number: retry queue has 4193 albums but none ready for retry yet. These albums failed cloud identification, and the retry backoff timer keeps deferring them, causing Roon to continuously re-process the same large block of your library. This is what triggers the full 143,735-track re-queue on every restart.

What to do:

  1. Check Settings → Library → and make sure "Background audio analysis" is not set to run at max speed simultaneously — on a dual-core i5-6200U with 145k tracks it creates contention. Turn all analysis off and see how that goes.
  2. Avoid restarting Roon until the queue clears — each restart resets the whole queue back to ~143k.
An important note on this - your storage drive /storage/music reports DriveNotReady for a brief moment on every restart before coming online. This is normal for a spinning HDD that needs a moment to spin up, and it does come online cleanly. However, it means each restart triggers a brief re-scan of your 6.1 TB library before Roon confirms all files are present — contributing to the re-queue cycle.

For your audio stoppages, this is a separate issue.

The HiFiBerry DAC+ HD has severe clock drift. It’s consistently running at 49–68 ppm drift, which is far outside the normal range (typically under 10 ppm). You can see Roon logging repeated long rtt sync warnings specifically for snd_rpi_hifiberry_dacplushd. At 50+ ppm, the clock can drift enough over time that the RAAT buffer is exhausted, causing the zone to stop. The Sonore ultraRendu and the HiFiBerry Digi in the same zone are behaving normally (under 7 ppm).

There are also recurring error writing to connection remoting errors and RemotingException: failed to look up object id critical errors appearing on a regular cycle throughout the logs. These suggest a Roon Remote (likely your MacBook or iPhone) is periodically losing its connection to the server in a way that disrupts active sessions.

Some next steps for you to try for this issue:

  • The HiFiBerry DAC+ HD — check that the Pi running it has a stable power supply (underpowering a Pi causes clock instability), that its OS is up to date, and that the HiFiBerry driver is current. You can also try removing it from the grouped zone temporarily to see if playback stops go away — this will tell you definitively if it's the culprit.
  • For the remoting errors — these appear to coincide with your MacBook or iPhone connecting/disconnecting. If you're using the Mac as a Roon Remote and it sleeps, that can cause these. Check Settings → Display and disable any sleep-related settings on the Mac while Roon is active.
  • The BRAVIA TV is constantly cycling in and out of the device list (Chromecast disconnect/reconnect every few minutes throughout the logs) — this is harmless but adds noise. If you're not using it as a Roon endpoint you can disable it.

Thank you!

“make sure “Background audio analysis” is not set to run at max speed simultaneously — on a dual-core i5-6200U with 145k tracks it creates contention. Turn all analysis off and see how that goes.

How do I turn all analysis off? The only options I have are “scheduled” where I pick the time. I have this between 1am and 5am. And “unscheduled”. There is no option for “off”.

Did it say which DAC+ HD? I have 3 of them.

The rest I do not understand. My Macbook is connected via ethernet to the same junction as the sonictransporter.

Not sure how to disable sleep on the Mac?

My TV I not connected to Roon at all. Not sure why it is showing up? It is not listed in Audio as a device.

Ok. I have done everything you have suggested, well, the best that I can, and now my system is almost f—–n useless. Every second or third song it stops, contemplates, thinks and eventually will play the next song.

This forum help has gotten to the point of laughingly unprofessional. I pay for a service, Roon. I have a problem. We are at a point where I should be able to make an appointment to speak with a human and have them log into my system just like every other digital company worldwide.

Hey @david_klipper,

Thanks for all the updates, and I’m sorry to hear you’re still suffering from issues.

If there are any specific steps that you weren’t able to perform, certainly let us know. This would be helpful to know and address.

We were able to review another fresh diagnostic report from your Roon Server, and see that the retry queue was at 4,193 albums in the earlier logs analyzed. In the new logs (April 19–21), it dropped to 3,607 albums — meaning roughly 586 albums actually processed and cleared. Then, on April 21–22 it jumped back up to 4,161 albums. This almost certainly corresponds to the restart that happened at April 21, 6:53 PM.

Every restart re-enqueues the full library and adds newly-failed identifications back to the retry pool. The good news is the queue is slowly shrinking between restarts when left alone.

The spinner will persist until either: (a) those ~4,000+ live recordings either get identified or are explicitly set to “prefer file” metadata via the import settings in Roon, or (b) you let the system run without restarting until the backoff timer finally retries and resolves them.

For your Issue 2: Playback Dropouts

There are four separate snd_rpi_hifiberry_dacplushd clock connections in the logs. You mentioned you have 3 HiFiBerry DAC+ HD boards, the logs show all of them are in the same grouped zone (“Office + Bedroom + Garage + Rendu”), and they are all exhibiting severe clock instability.

The logs show:

  • Routine readings of 100–200+ ppm on the DAC+ HD boards
  • Frequent spikes of 1,000–6,800 ppm
  • Brief extreme spikes of up to 41,585 ppm (this is roughly 150 seconds of drift per hour, quite unstable)
For comparison, the Sonore ultraRendu in the same zone reads 4–13 ppm consistently, perfectly stable. The HiFiBerry Digi also reads well under 15 ppm. The problem is isolated to the DAC+ HD boards.

The logs show 10 “OnPlayFeedback Stopped/Paused” events today alone (April 22), with clustered stops around 9:09 AM, 10:45 AM, 11:26 AM, and 11:31 AM. These correlate directly with the long rtt sync warnings on the DAC+ HD endpoints. When the clock drifts far enough, Roon cannot keep the grouped zone synchronized and kills playback.

Some next troubleshooting steps for your dropout issues:

  1. Go to Settings → Audio, and for each HiFiBerry DAC+ HD, temporarily disable it or remove it from the "Office + Bedroom + Garage + Rendu" grouped zone. Play through just the Sonore ultraRendu alone. See if you run into the same dropouts.
  2. Check the power supplies on each Raspberry Pi running a DAC+ HD. Clock instability at this severity could potentially be a power issue on a Pi, underpowered or failing PSU.
  3. Update the OS and HiFiBerry drivers on each Pi. The logs show the SonicTransporter is running kernel 5.6.13-100.sgc.fc30.x86_64 which is quite old (Fedora 30 kernel from ~2020). The Pi OS on each endpoint should also be current. HiFiBerry has released driver updates that improve clock stability.
  4. Re-add the DAC+ HD boards one at a time after checking power. This will tell you if it's one specific board vs. all three.

For the blue spinner (library identification):

  1. Do not restart Roon Server again unless absolutely necessary. Every restart resets the retry queue to ~143k tracks and adds time. The queue is slowly working through the backlog between restarts.
  2. Bulk-set your live recordings to "Prefer File" for metadata. In Roon, go to Albums, filter or sort to find unidentified albums, select them all, and choose Edit → Metadata Preference → "Prefer File." This tells Roon to stop trying to cloud-identify them. With 4,000+ live recordings that will never match the Roon database, this is the permanent fix. It will shrink the retry queue dramatically and likely stop the spinner for good.
  3. Convert the King Crimson .m4a files to FLAC as you planned. Once re-scanned, those problematic files will no longer cause issues.

We’re sorry you’re not finding the community helpful for offering technical support. We’re always welcome for user feedback on our processes, and always looking for ways to improve - feel free to share your thoughts over in the Feedback category in our community, as it’s actively monitored by our team.

Thanks again, David! :folded_hands: