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:
- 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.
- 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!