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
· No, the issue is still the same even immediately after a reboot
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 don't know how to do this
What is the operating system of your Roon Server host machine?
· Roon Optimized Core Kit (ROCK)
Timestamp of issue occurrences
· Pretty much all the time but June 29th at 13:42
Describe the issue
Roon is very slow. The library takes a long time to load; searches are slow and sometimes just don't work; tracks take a long time to load and play.
Describe your network setup
ISP is SKY, Full Fibre 500, Sky Max Hub, One Sky Max Pod (range extender). No other switches
Thanks for writing in and sharing your report! We were able to further examine a fresh Roon Server diagnostic report, and have found the following:
The hardware seems to be the root cause. The ROCK is a NUC with an Intel Core i3-6100U (Skylake, 2-core/4-thread, 2.3 GHz) and 8 GB RAM. The i3-6100U is a 2015-era low-power laptop chip (15W U-series, 2 physical cores). Pair that with:
A classical-heavy library (31k tracks but 19k works / 24k performances)
RoonServer consuming ~6.4 GB physical out of 8 GB total, leaving almost nothing for OS file cache
15–17% of runtime lost to GC pauses, up to ~3-second stalls
That combination is the whole story. The CPU can't keep up with the metadata/work-computation load this library demands, and with 6.4 GB resident on an 8 GB box the .NET runtime is collecting aggressively. Reboots don't help because nothing changes the hardware ceiling, which matches your report exactly.
The i3-6100U with 8 GB is below the recommendations for a library of this complexity. I’d consider something toward an i5+ for large/classical libraries.
That said, here are some next steps you can try:
Interim relief on the current box: keep audio analysis Off, and consider whether the library can be trimmed or whether very large composition-heavy content is driving the work-explosion. It will help marginally but won't fully resolve it.
Do a clean database test before spending money, back up, start a fresh database, and see if responsiveness improves. If a fresh small DB is snappy on the same hardware, it confirms the library size/complexity is the trigger (expected here). If even a tiny library stalls, something else is wrong.
Shut down cleanly going forward (the journal recovery on boot indicates a previous hard power-off). Use the proper shutdown in Roon Settings rather than pulling power.
Hi Benjamin - thanks for confirming what I suspected, I will try the steps you suggest but am definitely going to update the server. Just need to decide what. Thanks again, Christopher
Benjamin, can I just ask whether you think the Roon Nucleus One would be up to the job as a replacement server? I have read it has only 4gb RAM and based on your comments I wonder if that is sufficient. Thanks, Christopher
Thanks for the follow-up! Good question, and an important one to get right before you buy.
The Nucleus One indeed does come with 4 GB of RAM. For a typical library that fits comfortably within its rated ceiling, it’s a great turnkey option. But for your library specifically, I’d steer you away from it.
The issue isn’t raw track count (31k is moderate) it’s the composition complexity. Your library has ~19k works and ~24k performances, which is what was driving the work-computation load and the heavy GC pressure on your current ROCK. That’s a metadata/memory problem more than a storage problem, and the Nucleus One’s 4 GB of RAM would put you right back in the same situation we just diagnosed: not enough headroom for the runtime, aggressive garbage collection, and stalls. Going from 8 GB to 4 GB would likely make things worse, not better.
For a classical-heavy library like yours, I’d point you toward something with an i5 or better and at least 8 GB of RAM (16 GB is the sweet spot if you go the DIY/mini-PC-with-ROCK or Linux route). Within Roon’s own lineup, the Nucleus Titan is the platform built for exactly this kind of demanding, composition-rich library. A self-built ROCK box or a Linux/Windows/Mac machine on an i5/i7 with 16 GB would also do the job well.
So in short: the Nucleus One would be a sideways or backward step for your particular library. I’d consider something higher on both CPU and RAM.
My Roon is also very sluggish lately. Scrolling through albums takes (on startup->lafter it’s a bit faster) up to 12 seconds before covers become visible. Playback is not immediate and sometimes music stops in the middle of a song. Made a support ticket.
We recommend both of you try migrating to the Early Access branch, if you haven’t already. Our team is testing some performance improvements there that should help with sluggish loading and searching in Roon.
