What kind of performance/speed issue are you experiencing?
· The app takes a long time to respond to commands
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?
· Nucleus
Which model Nucleus do you have?
· Nucleus One
Timestamp of issue occurrences
· I rebooted the Nucleus One approximately 2 days and 10 hours before this report. The server was responsive immediately after the reboot. The issue has since returned, and on 15 July 2026 at approximately 10:50 PM (UTC+8, Macau Time), Roon Remote again displayed "Waiting for your Roon Server" for more than 30 seconds before connecting. The server becomes progressively slower after one to two days of uptime, while rebooting temporarily restores normal performance.
Describe the issue
My Nucleus One has recently become very slow and unresponsive. After rebooting, it works normally and connects instantly, but within one to two days the problem returns. When I open Roon Remote on my Mac, it often shows “Waiting for your Roon Server” for more than 30 seconds before connecting, and the interface remains sluggish. This started after a recent Roon update. I have around 2,300 albums, no DSP enabled, and rebooting only fixes the issue temporarily.
Describe your network setup
ISP: CTM Fibre Broadband (Macau). Network setup: CTM modem/ONT → GL.iNet Flint 2 (GL-MT6000) router → Ansuz PowerSwitch A3 → Roon Nucleus One → Gustard R26 (Roon Ready endpoint). An ASUS ZenWiFi BT10 is configured in Mesh AP mode and connected to the Flint 2 for wireless coverage. All audio devices are connected via wired Ethernet. I have also tested using Cloudflare DNS (1.1.1.1 / 1.0.0.1) instead of my ISP's DNS, but it did not improve the issue.
Sorry to hear about your Nucleus issues! We’re not seeing the device linked to your account to enable diagnostics, so we’ll need to review a set of manual Roon Server logs from the machine.
Can you please use the directions found here and send over a set of logs to our File Uploader? Once logs have been uploaded, please let us know so that we can check the server for your files, thanks!
With that, it’s worth noting that we did just release additional memory-related optimizations over in our Early Access version of Roon, which you can read more about here:
As well as:
If you’d rather wait until these updates are pushed to our Production branch, that shouldn’t be very long of a wait.
Thanks, Nicholas, we’ll be monitoring for your reply!
Thank you for your quick response and for pointing me in the right direction.
I’ve now uploaded the requested Roon Server logs via the File Uploader. Please let me know if you’ve received them or if you need anything else from my side.
Regarding the Early Access build, I don’t mind giving it a try. However, I’d first like to understand the root cause of the issue before deciding whether to move to the Early Access branch or wait for the fixes to be released to the Production version.
Thanks again for your help. I look forward to hearing your findings.
Thanks for sending those logs over so quickly, I’ve been through the full set and can share what’s going on.
Your logs confirm this is a memory-related issue on the Nucleus One, and the good news is it’s exactly the behavior the Early Access optimizations I mentioned are designed to fix.
Here’s what I’m seeing: after your reboot on July 13 (~05:07 server time), RoonServer starts at around 150 MB of memory and then climbs steadily the longer it stays up, roughly 2.5 GB by that evening, ~3 GB the next day, and pinned at ~4 GB (the Nucleus One’s ceiling) by July 15. As memory fills up, the server has to spend more and more time on garbage collection, and those become “stop-the-world” pauses where Roon briefly freezes. Early after a reboot they’re a fraction of a percent; by the time you reported the problem on the evening of the 15th, I can see individual pauses of up to ~14 seconds. A few of those back-to-back is what produces the “Waiting for your Roon Server” hang and the general sluggishness you’re experiencing.
This also explains why rebooting helps but only temporarily, it resets memory back to ~150 MB, and the slowdown returns as it climbs again over a day or two. Importantly, I’m not seeing any crashes, network, DNS, or storage errors in the logs, so you can rule those out, this is purely the memory-growth pattern, which lines up with normal use across multiple remotes.
So to directly answer your question on root cause: this is a memory-growth/GC regression in the current Production build, and the fix is the memory work in our latest Early Access release (Roon 2.71, build 1674). You have two good options:
Move to Early Access now to get the fix immediately, or
Stay on Production and wait, it shouldn't be a long wait before these changes are promoted.
In the meantime, a periodic reboot (and closing any idle remotes you're not actively using) will keep things responsive.
Happy to walk you through switching to Early Access if you’d like to go that route. Let me know how you’d like to proceed!
Thank you so much for taking the time to dig into the logs and for the detailed explanation—it was incredibly helpful and really helped me understand the root cause.
I’ve now migrated to the Early Access build, and so far it seems to have resolved the issue. Everything is running smoothly again, so hopefully that confirms your diagnosis.
I really appreciate your support and the time you spent investigating this. Thanks again for the excellent help!
