· Playing a single album, Rainbow's Rising, and it is taking Roon a ridiculous amount of time switch tracks. This has been ongong problem for many, but I thought I solved it recently by starting with a completely fresh database. But the problem just occurred again, between the tracks "Startstruck" and "Do You Close Your Eyes".
Tell us about your home network
· 400 megabit per second Internet access. New state-of-the-art TP-Link router, which I have connected to a new TrendNet gigabit switch, to which my Roon Core (a Roon-spec NUC) and all endpoints are connected via new Ethernet cables.
I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.
And there’s the problem in a nutshell. When the delays starting playlists/moving to the next track started yesterday, I rebooted the NUC (Roon-spec) on which my Core runs, and now performance is fine. As of now, I cannot recreate the extremely slow performance.
But I shouldn’t have to reboot the NUC, at least not weekly!
As a reminder: I just started with a completely fresh database from scratch less than one week ago. I re-connected to TIDAL, and re-scanned my library; I have a total of approximately 40,000 tracks.
What is possibly corrupting things so badly that performance goes from essentially perfect to 15 second or more delays between the playing of tracks in a playlist, in less than one week? I will say again this problem only recently started occurring and I’ve had Roon for almost 10 years.
In terms of timing, the performance was awful at the time I took that screenshot, which was between 4 and 6 AM Pacific Daylight Time on Tuesday
If rebooting temporarily helps with performance, and it slowly degrades over time, it sounds like you’re experiencing a known issue that our development team is actively working on a fix for.
We don’t have any additional troubleshooting steps to provide, other than performing a daily reboot of your server for the time being.
While the process itself only takes a minute or so to complete, I understand it causes friction during the initial start-up process before a listening session.
We have a first draft of these optimization updates released via our Early Access branch of Roon, and are collecting feedback to make additional optimizations, so it shouldn’t be very long before these are pushed to Production.
That said, we took another look at a fresh Roon Server diagnostic report from your ROCK, and saw that during the problem window on April 8, there are recurring “long rtt sync” warnings on your HiFiBerry Digi endpoint (snd_rpi_hifiberry_digi):
04/08 11:24:04 Warn: long rtt sync snd_rpi_hifiberry_digi: rtt=66000us ... (-4992ms/hr)
04/08 11:24:14 Warn: long rtt sync snd_rpi_hifiberry_digi: rtt=36500us ... (-2221ms/hr)
The first warning shows the RTT at 66ms and clock drift of ~5 seconds/hour, which is high. These warnings appeared on April 6 and 7 as well. RAAT requires tight clock synchronization between the Server and endpoints; when RTT spikes (due to CPU load on the NUC or network jitter), Roon can stall playback waiting for the sync to stabilize. This likely explains the long gaps between tracks.
Something for you to test in the meantime - Play to a single zone for the first few days after you reboot next. See if that changes any behavior.
