What kind of performance/speed issue are you experiencing?
· Tracks take a long time to play
Please try to reboot your Roon Server
· Yes, rebooting helps, but the issue returns after some time
Please try to reboot your networking gear (Router/Switches/etc.)
· No, the issue is still the same even after a reboot
Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?
· No, the issue is still the same
Does the issue happen on multiple Roon Remotes (controllers) or just one?
· Issue happens on multiple remotes
Router Domain Name System (DNS) change
· I was able to change my router's DNS servers but it did not help
What is the operating system of your Roon Server host machine?
· Roon Optimized Core Kit (ROCK)
Timestamp of issue occurrences
· 5:20 PT (and for a while before that)
Describe the issue
Roon intermittently responds slowly to play commands, skips tracks, and stops. The most recent incident was today at around 5:20 PT. It happens with both Tidal and Qobuz. I have to reboot the Roon server, and things get better for a while but the problem returns. After my last support request, I know to reboot Roon, and my Eero devices, and I even did a factory reset (as instructed by Vadim) of a Bluesound Node that logs showed was doing some odd things. The problem persists. I have 1GB Ethernet service and all endpoints are wired.
Describe your network setup
Xfinity, Eero 7 Pro, 1GB internet, all devices have wired connections
Thank you for the detailed report and for your patience through multiple troubleshooting rounds. After reviewing your logs we can confirm the root cause of this specific incident - and it is a completely different issue from what we found in your previous ticket in June.
This time the problem is server-side: Roon Server accumulated excessive memory usage over an extended uptime, which eventually caused the entire process to freeze and kill all active streams simultaneously. This explains why the Marantz and all Bluesound Nodes dropped out at the same time rather than one at a time.
Our engineering team is actively working on this memory management issue and a fix is targeted for an upcoming release. In the meantime, as a workaround please reboot your ROCK unit daily - this resets memory to baseline and prevents the buildup from reaching the point of freezing.
Please update once the next release is available and let us know if the issue recurs.
This is so helpful, Vadim. I worried that one of my devices was failing and affecting the others, but also wondered if it was just a Roon memory management issue (given the benefit of a reboot). Thank you so much for explaining this clearly and quickly! I’ll continue to reboot daily and look forward to a fix in an upcoming release.
So glad this helped clarify things! Please do keep us posted - if the issue recurs before the fix is released, let us know and we will take another look at the logs. Otherwise, we look forward to hearing from you after the next update.
Yes, please use the Stop button in the ROCK Web UI to gracefully stop Roon Server, wait a few seconds, then press Start again. This is safer than using the physical power button as it gives Roon time to finish any writes before shutting down.
The most recent public update contains some performance and memory improvements that we’ve discussed earlier in this thread.
Are you still encountering these symptoms? Please let us know the name of any Tidal/Qobuz tracks that skipped and we can investigate the playback event separately, as well.
Thank you for following up on this, connor. I just installed the update yesterday and things seem better but I still had some odd delays this morning. Perhaps that has something to with the updated iOS apps being unavailable still. I’m not sure if this is a related issue, but I’ve noticed that streaming from Qobuz or Tidal directly to a Bluesound Node can lead to no sound/output and/or delay problems when I try to stream from Roon (also using Qobuz or Tidal) to the Node. Rebooting the affected Node seems to help but the problem persists and I’d of course prefer not to do reboots regularly to get Roon working. I know that some other folks have had issues with Nodes lately, so I wanted to point that out in case it’s useful. I’ll reply with specific tracks and timestamps if these issues return. I really appreciate your being so responsive.
I switched my Node devices out for some WiiM Pro Plus units and a Cambridge CXNv2, just in case the Nodes were the culprits. I also ordered a WiiM Ultra (arriving in a few days) to see how things function with 3 WiiM devices and my one Roon Ready AVR. At 12:09 PT today, the Roon server stopped playing and did not restart until I pressed play again in a Roon remote.
Thank you for your patience while we reviewed your latest diagnostic logs from July 11th to 13th.
The good news is that the recent update was successful in resolving the severe memory leak you previously experienced. Your Roon Server’s overall memory footprint is now stable and properly bounded. However, while analyzing the logs, we discovered a different underlying mechanism that is causing your current track skips and stops.
The server is occasionally executing highly intensive Garbage Collection (GC) passes—an internal process used to clean up temporary memory. These specific cleanup cycles are causing the server process to briefly pause for several seconds. This transient pause stalls data delivery just long enough to drop your active audio streams, which perfectly aligns with the dropouts you are seeing across your WiiM and Cambridge endpoints. (This also confirms your new endpoint hardware is working perfectly and simply reacting to the server pausing).
Because this is a core application behavior, I am escalating this specific GC-pause issue directly to our R&D team for further investigation. We need to determine exactly what is triggering these intense cleanup cycles now that the memory leak is resolved.
In the meantime, your workaround of rebooting the ROCK daily via the Web UI is still the best mitigation strategy, as it resets the environment before these heavy pauses can occur.
We will keep you updated in this thread as soon as we hear back from engineering. Thank you again for your detailed reports and for working through this with us!
Thank you, vadim, for finding this new issue and doing what you can to make the cleanup process more efficient. As I mentioned in a previous post, I decided to swap out my Cambridge Audio streamer with another WiiM device, so I now have 3 Roon Ready WiiM endpoints and 1 Roon Ready Marantz AVR endpoint. I’m hoping these devices will play nice with each other.
The CA device upsampled everything to 384, with no way to disable it, and I had constant out-of-sync problems because of it. My Bluesound devices were also somewhat unpredictable. I’m hoping that a WiiM-centric system will clean things up in general and that the processes you’re noticing and fixing will address the more specific performance issues. Thanks again for your assistance.
Thanks for the update on the endpoint swap, and glad to hear the plan there.
One more thing worth mentioning: the GC-pause fix we escalated should already be included in Roon 2.71 (build 1674), which is live now on the Early Access branch. If you’d like to try it before the general release, you’re welcome to. Here’s more info: EarlyAccess: Roon 2.71 Build 1674 and ARC 1.81 Build 422 are Live!
Either way, please let us know how things go, particularly whether the track skips and stops still happen once the pauses hit. We’ll keep this open and watch for your reply.
