· None of the above quite fits
· None of these quite match
· RoonApplication uses 100% of CPU on Win11 for periods in the evening when it is inactive. During this time it is not responsive to remotes even after restart.
· Virgin home network (fastest available) on which Roon is extremely fast and responsive the rest of the time.
Hello @David_White1,
Sorry to see you are having this issue.
Could you please make a note of the exact date and time the next time this happens(CPU loads at 100% by Roon)? We would like to check the diagnostics from your PC to see exactly what is going on when the process starts taking up so many CPU resources.
Also, please note how long the high usage lasts and whether it goes back to normal on its own.
Looking forward to your reply.
Thanks.
22:10 just now. I added one album, the first of the evening, was 100% for 1 minute, and took that long (whirling) to add it (would be more like a second in the daytime)
Same for second release added
2 mins whirling at 100% for third release added
Restarted server as I want to be adding things at a normal rate
Cleared my [currently playing] queue of thousands of songs worried that that in itself is what is causing everything to be slow
Stuff is now adding and editing very fast a couple of minutes after restarting server (but no music playing), server using almost no CPU while doing so
Started playback of smart playlist of 150,000 songs
Everything fast again even when playing that back (so that in itself doesn’t look to have been it)
…
Server had only been running ~22 hours and needed to be kicked (and spend 5 mins at 100% while booting) for any responsivity to occur. But when unresponsive it wasn’t always at 100% this time, only when actually trying to browse/add/edit.
Will monitor further thanks
@David_White1, thanks for following up with the timestamps and logs.
We’ve analyzed the diagnostics from your Beelink machine around the 22:10 mark, and the data confirms exactly what you described.
We can see that database operations, specifically writing changes to the DB which should be near-instantaneous, are taking excessive amounts of time during these imports. At 22:15, a database mutation took over 8 seconds, and at 22:19, it reached nearly 9 seconds.
While the system is trying to process these writes and re-sort the library indices, the CPU spikes to 100%, causing the UI unresponsiveness you are experiencing.
Regarding the root cause, we noticed your server hostname is BEELINK. These units often run on Intel N100 or similar low-power processors. While these are great for smaller setups, your library size is significant at approximately 150,000 tracks.
For a library of this magnitude, Roon requires strong single-core performance to manage the database structure in real-time. An N100 processor simply lacks the raw throughput to handle imports and indexing for 150k+ tracks efficiently, leading to the bottleneck we see in the logs.
To get the snappy performance you expect with a library of this size, we strongly recommend moving your Roon Server to a machine with a higher-performance CPU, such as an Intel Core i7 or Apple Silicon M-series. The N100 barely meets the minimum requirements for playback, but not for managing a library of this scale.
Let us know if you have any questions about migration or hardware specs.
Hi Alex
I had considered this. However there are a couple of other things I could mention that would not quite chime with that.
Have you any thoughts on these, many thanks again
By the way right now, I have added a couple dozen [Qobuz] albums and the CPU is just persistent at a hot 100%. All those albums have been already added to the database across the past half hour, all the metadata is in and has been edited, and both analysis options are set to “throttled”.
After 10-15 minutes at 100% with no responsivity, have just closed the server (is there a more elegant way to do this than ending the task? given also that it is not responding) and restarted. After a 4-minute restart the CPU dropped to minimal again, but upon adding one more release it is stuck at 100% again. edit: it has now been at 100% for ten minutes
Again, this is not normal operation - this machine has added many releases very quickly and smoothly in between these periods and is normally very responsive. I can also shuffle a >150,000 track smart playlist [it likely doesn’t add all those tracks to the live queue, but a few thousand?] via RoonARC smoothly for hours (long drives/android auto) whether lossless or optimised.
I’m going to do a db backup then clean the database. Although I do not tend to remove much data (only when replacing a qobuz release with my own CD rip, at which point I remove the qobuz one from the library altogether)
If you check the last updates at 14:40 (and onwards) that is an example of adding and editing lots of qobuz releases at quick pace (with instantly responsive server, not maintaining any maxed CPU) while streaming local 24bit audio to a separate PC endpoint, thanks
BTW I expect to cap out at about 200,000 tracks and stuff currently runs great almost all the time with 158,000.
BTW the library additions where you describe 8 or 9 seconds took over a minute, I was not being loose with the timing.
Right now I’ve come back to my office and Roon is driving at 100% CPU. 21:25 onwards, nothing is happening but CPU is 100%.
It seems to be the case that I can end its uninterruptible tyranny by ending the task and restarting the application, whereupon 22 hours of normal fast operation may be had, give or take
Hello @David_White1,
Thanks for the additional details and for sticking with us — we understand how frustrating this behavior is.
To address the core of the situation directly:
Your server is running on an Intel N100 processor. While this CPU can handle basic playback tasks, it is below the hardware level we test and validate against for Roon Server.
Our minimum supported CPU class is Intel Core i3 (or equivalent). Processors below this level, including N-series low-power CPUs like the N100, are not part of our regular test matrix, and as a result we can’t guarantee consistent or stable performance — especially with large libraries (150k+ tracks) and frequent library mutations.
Even when no music is actively playing, Roon performs background work such as:
On lower-power CPUs, these operations can occasionally monopolize the CPU, leading to the sustained 100% usage and UI unresponsiveness you’re seeing. A restart clears the backlog, which explains why things return to normal for many hours afterward.
While this won’t eliminate all background work, it can help reduce pressure on the system:
This won’t stop all background processing, but it will noticeably reduce sustained CPU load.
Given the CPU in use, what you’re seeing is consistent with running Roon Server outside supported hardware specifications. For long-term stability with a library of your size (and future growth toward ~200k tracks), we strongly recommend:
If you’d like, we’re happy to advise on migration options or suitable hardware targets.
Thanks again for the detailed feedback — it’s genuinely appreciated.
Many thanks for these details (the whole post, not just this part). When I am settled in on Roon for a few months I may consider looking at an upgrade.