· Environment Roon Version: 2.0 (Build 1598) Installation: Docker container using mackid1993/docker-roonserver image Hardware: Synology DS923+ NAS, 32Gb memory Library Size: ~6,495 albums / ~68,835 tracks Unidentified Content: Approximately 10% of albums
· Issue Description My Roon Server is constantly running at 25% CPU usage on my Synology DS923+, which strongly suggests it's maxing out one of the four CPU cores. This behavior persists even when no playback is occurring and the library hasn't changed. 10% of my albums remain unidentified.
I understand that Docker is not an officially supported deployment method for Roon Server. However, I wanted to report this behavior in case it points to a broader issue with how Roon handles unidentified albums or background processing.
Thank you for building such a fantastic product. I appreciate all the work the team puts into it, and I hope this feedback can be useful. Keep up the great work! 🎵
Tell us about your home network
· Network Setup NAS Connection: Synology DS923+ connected via 1Gbps Ethernet directly to Freebox router (French ISP) Wi-Fi Infrastructure: Netgear Orbi RBR750 running in AP mode, with 2x RBS750 satellites
· Roon Endpoints: 5x Apple HomePods (2 of them joined as stereo speakers) 1x FiiO SR11 network player
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
2
The CPU has barely the performance to run Roon server if it was installed on bare bones, so this is unsuprising.
Thank you for your answer. As I understand your point, Roon is constantly maxing out the CPU Core, it never gets down even when it idle. When I read other users comments on their experience with similar devices (on the Nas experience Index thread), it seems that they do not encounter the same problem.
Note that the user experience from my Roon client on my Mac is quite good, and the app is responsive.
I might offer some counterpoint. I and many others have been running Roon on NAS on this hardware with splendid performance for quite some time now. I myself have a 2.7TB collection on a 1522+ (which is a 923+ with an extra drive bay) with 16GB of RAM and:
That said, I only have 146 unidentified albums. @Josef seems to be reporting that he has about 650 unidentified albums, and that can be part of the problem. But I started with a similar number of unidentified albums 4 years ago and never had any real performance problems.
I suggest trying it outside of Docker for at least a bit.
1 Like
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
5
Which is why I said it’s not unsuprising. The library is getting close (70k) to the maximum (100k) for and i3, a large quantity of unidentified albums, and quite a few other containerized apps running, and consuming overall resources.
Whilst memory helps, single thread performance is the likely culprit.
Inidentally, I run Roon in a container, too, but have far more headroom, and few unidentified albums.
Thank you @DDPS for your answer. It seems we have a similar configuration. So I understand you run Roon directly from the Synology package? I just tried that, and it’s exactly the same, see screenshot below. I checked your extensive post, very interesting. As for my unidentified albums, I tried yesterday to manually re-identify some of them, but very very few are “findable” in Roon Database. @Suedkiez’s post explains that a few hundreds unidentified albums should not hurt the system performances…
@mjw As you can see in my server stats, I have some docker containers, but the server is not busy at all and @DDPS as exactly the same processor and similar databese without any problem. What could explain the experience difference?
I’m gonna try on a spare M1 Mac with 8gb of RAM to see how it works, but I feel there’s something wrong going on…
As @mjw was stating the CPU in the NAS is barely hitting minimal requirements.
But despite that do you mind rolling out a native (non docker) clean Roon Server on your nas (with previously made backup) and check if it is going to hit the same CPU load ?
Also, you can try to play with “Background audio analysis speed”.
Please try to set it to Throttled and Off positions and check whether it alters the CPU load.
I agree that there is something else going on. If I were in your shoes, I would see what happens if you only expose half your collection at a time to Roon, and see if you can narrow it down to some strange files that might be driving it a bit crazy. Yes that takes some work, but based upon my experience I think it would be worth pursuing (it’s precisely what I would do.)
@DDPS Okay, thanks a lot for your answer. I’m going to try to stick to the RoonOnNas version for now and the testing period. What’s your advice?
Should I restore a backup of my database and point the music folder to an empty one to test the potential faulty files?
Or should I start with a empty database?
In any case, I will need my database because I have many rated/tagged songs and I want to keep all this hard work…
@alex_h both switches are on “off” position and the Roon process is still at 26% CPU, maxing out a core. The restore is finished and the NAS is quiet otherwise…
What you’re seeing is normal and does not indicate a malfunction.
Roon Server is not an “idle” service — even when nothing is playing it continuously performs background work such as database maintenance, metadata reconciliation, identification retries, duplicate and version matching, search indexing, and recommendation calculations. Because much of this work is single-threaded, a steady ~25–30% CPU on a 4-thread system simply means one core is fully utilized.
The DS923+ uses an AMD Ryzen Embedded R1600 (2 cores / 4 threads), which is below Roon’s recommended single-thread performance for a library of ~70,000 tracks. On hardware in this class, sustained CPU usage is expected, especially with several hundred unidentified albums generating ongoing background processing. Docker is also not supported and can further increase CPU and I/O load, even if the numbers look similar in native mode.
Since playback and the UI are responsive, this behavior is within expectations for this hardware and library size.
I am going to suggest that the processor usage @Josef is seeing is not aligned with my own experience. To reiterate my earlier post, I have a similarly sized collection and once had the same number of unidentified albums (on my prior NAS, a DS918+, no less) as he did and I never saw processor usage like this. Because of this, I suspect that Roon is struggling with a particular subset of his collection that can be determined by elimination.
Many here know that I am weary of people underestimating the capability of these NASs to run Roon well.
So to @Josef’s point, I. think you should restore a backup of your database and point Roon to a folder that has half of your music to see what happens. If you find the processor usage to be good, then try the same with the other half. If the processor usage is good on that half, too, then Roon is right and I am wrong, and I am OK with that.
But if the processor usage on either half is not good, then I suspect you know what to do next :). Best of luck.
After a few days of testing, here are my results. I migrated my Roon database to a base-config M1 Mac Mini (8GB/256GB). It seems to work well, but one of the 8 cores of the Mac is still maxed out by Roon, see the screenshot.
As @DDPS suggested, I think this might come from some faulty files or a corrupted database. Is there a way to check the logs and understand what’s happening, rather than spending time going back and forth? I’d rather not waste (my/your/fellow users) time if I can troubleshoot this on my own first.
I’d be happy to split my files into different batches to test them as DDPS suggested, but I have to be honest:
Is this really something I should be doing as a paying customer?
Is this the most efficient approach? It feels like a brute-force way to debug a software, when checking the logs would likely point to the issue much faster.
I’m not trying to be difficult, I just want to make sure we’re tackling this in the smartest way possible.
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
13
Why not start with a clean database, pointing at the same library files, to see if there is any difference in performance? At least this will give you an indication of database corruption vs. a library/media issue.
Why not, but first I’d like to know, again, if I can see the logs. I’m paying a lot for a software, and I’d like to get a real assistance. I’m spending more time finding a solution and writing here than listening to music.
Because, see, you first answered me it was because of my NAS, or Docker, and it’s clearly not. Logs would have helped and save us time. I’ve nothing against you obviously, thank you a lot for your time and answers, but I’d like real help from the Roon support, not keeping you busy with my problem, you have probably other users questions to answer.
Side question, many of my unidentified albums will never be identified (dirty Youtube rips for instance). Can I flag them as such and keep them away from next indexing? For others, can I add them to Valence in some way ?
I understand that what I have suggested is not ideal, but as an end user, that’s all I’ve got, and I think it will help guide you pretty quickly.
The way a lot of the more intense hobbyists around here (I might be one of those people…) handle the unidentified album situation is by using MusicBrainz Picard. You can point it to a local album and then submit the album to MusicBrainz from there.
MusicBrainz is one of two sources (the other being TiVo) that Roon uses to identify albums.
I don’t use Picard for tagging, at all (I use Tag Editor and Yate). I use Picard only to submit the albums Roon can’t identify, sending the metadata I’ve already curated to MusicBrainz through Picard to save time because otherwise using MusicBrainz to add a new album or artist from scratch is a total PITA.
After you submit a record to MusicBrainz, it takes about a day and a half or two days to get through the voting process (or lack thereof) on MusicBrainz and to get picked up by the Roon database servers.
FWIW, you can check your logs on the server, but good luck, because there is a (pardon the pun) bad signal-to-noise ratio in those logs.
1 Like
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
16
Roon support have your ticket, and will reply in due course. However, community may also pitch in with suggestions.
I’m not suggesting you ditch this. You have a backup, and may restore this after testing with an empty (new) database. If the problem remains, your database is probably sound, and something else, e.g., unidentified albums, is the culprit.
As a workaround, move these recordings to a separate folder, and add as a separate storage location. Disable when not needed. Presently, there is no way to tell Roon to ignore such “albums” – I have a few like this.
I haven’t had a chance to test your solutions yet, but I’ll get back to you with my results as soon as I can. Thanks to all of you who tried to help me.
