Did you make any changes to address the issue? In that case, I cannot see any improvement. This is the CPU usage of the roon sever in idle mode:
And the roon server still accounts for almost as much CPU usage as all the other 27 conatiners plus the operating system combined, as illustrated by the following CPU usage graph:
I turned roon server off at 23:28 and turned it back on at 23:36. The dip in CPU usage us strikingly clear,
There seems to be another issue causing playback hiccups: high memory usage. Yesterday, I was running short of memory on my macbook pro M4 (24GB) and noticed that the roon client’s memory usage had increased from 1.5 or 1.8 GB (which is already insanely high for such an app) to almost 3 GB. I wasn’t even listening to music, so I turned it off.
This morning, I kept having brief interruptions in the audio while listening via a a different device but when I checked the CPU usage of the roon server, there was nothing special to be noticed that might explain the hiccups (CPU was high, as usual, but it can’t explain the outages, since memory usage is always high not just when outages occur.
Then noticed that roon server was using 6.4GB. A few minutes later that had increased to 6.5GB and then 6.6 GB. When I restarted roonserver, its memory usage went down to 1.5GB. So, it looks like there is some memory leak going on, for sure on the server and probably also in the client app.
TBH, my overall impression is that the Roon codebase is in a bad state and probably in dire need for a major overhaul.
Hi @Papatistos,
Thank you so much for your detailed reports and for sticking with us while we work through this issue. We know it’s been a frustrating wait, and we truly appreciate your patience and persistence.
I want to assure you that our development team is actively working on a fix. Your feedback has been incredibly helpful in guiding the investigation, and we’ll be sure to keep you updated here as soon as we have more information to share.
Thanks again for bearing with us! We really value your time and support.
I have similar trouble with my linux-based Roon server. I periodically need to reboot the machine when Roon’s CPU usage surpasses 100% of a single core. This usually corresponds to RAM usage steadily increasing to over 5GB. A reboot always fixes the trouble, which usually reappears every month or two.
Glad I‘m not alone (though that doesn’t improve the UX for either of us, LOL). Yes, it seems pretty obvious that there is some kind of memory leak and I hope they manage to figure it out. Don’t know if the memory issue is related to the CPU issue, but it would be great if they managed to fix it. While I want to believe that they are working on it (I’m giving a lot of feedback and bug reports to the devs of various apps and it is sometimes hard to tell how serious they are about solving the issue, especially when you’re not communicating with them directly) I‘m still flabbergasted that this CPU issue even exists. I really makes me wonder how they work with their codebase.
For now I‘m trying to work around these issues by restarting roonserver every night, but I think I‘m going to cancel my subscription. Roon is so freaking expensive that I‘m not really willing to accept anything but a flawlessly working app/service. Another annoying issue that just shouldn’t exist in such a „high-end“ app are the frequent repetitions of tracks on roon Radio. Am I asking too much? I don’t know, but these are my expectations when I‘m paying 15 USD per month.
We‘ll see how much I miss it once I lose access. I suppose many people stick around because of that one feature they can’t live without…
I wonder if the many variations of supported systems makes this difficult to fix. I attached a description of this issue along with screenshots of the high CPU and memory usage on my cores back in December 2024. I didn’t get any feedback , but I now run a bash script on my dietpi-based Roon core that reboots the machine when it gets stuck in the high CPU and memory condition, so I can live with the problem. Maybe the dedicated Roon hardware behaves better.
I don’t know to what extent the problem is specific to the different systems used. I have confirmed it on an M1 Mac and on a Linux system (running on a Vmware host. If it works without issues on the Nucleus hardware, then that’s probably because the nucleus has so much more power than roon should ever need. It almost seems they solved the problem by selling overpriced and overdimensioned hardware to people willing to pay for it,.
I don’t know either. Admittedly, I’m running the core on an old (~2012) Mac mini (i5-2415M, 8GB RAM), but I feel like this should be adequate. Coincidentally, my core is currently suffering through the usual symptoms. It’s been repeatedly generating the following types of logs for the past 45 minutes, using over 100% CPU and 5GB RAM with nothing playing:
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648056
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648057
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648058
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648059
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648060
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648061
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648062
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648063
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648064
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648065
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648066
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648067
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48648068
06/30 00:45:09 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770484
06/30 00:45:09 Trace: [library] starting cleanup with , 0 tracks to retain, 0 auxfiles to retain
06/30 00:45:09 Trace: [clumping] clumping 63 tracks and 0 auxfiles
06/30 00:45:09 Trace: [clumping] finished
06/30 00:45:09 Trace: [library] finished with 63 dirty tracks 6 dirty albums 16 dirty performers 45 dirty works 45 dirty performances 13 dirty genres 1 dirty tags 50 clumping tracks, 0 clumping auxfiles 0 compute tracks, 0 deleted tracks, 63 tracks to (re)load, 0 tracks to retain, 0 auxfiles to (re)load, 0 auxfiles to retain, and 189 changed objects
06/30 00:45:09 Trace: [music/searchindex] [search-index] removed in 0ms: 6 album documents, 63 track documents, 0 work documents, 0 performer documents, 0 genre documents, 0 label documents, 0 tag documents
06/30 00:45:09 Trace: [music/searchindex] [search-index] added in 30ms: 6 album documents, 63 track documents, 0 work documents, 0 performer documents, 0 genre documents, 0 label documents, 0 tag documents
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryPerformer:16 dirty items, rebuild threshold: 2000, rebuilding? False
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryTrack:63 dirty (< rebuild threshold of 28165.600000000002). re-sorting item-by-item (internaltype=LibraryTrack)
06/30 00:45:09 Debug: [query] Sooloos.Broker.Music.LibraryTrack:63 dirty (< rebuild threshold of 28165.600000000002). re-sorting item-by-item (internaltype=LibraryTrack)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryTrack:63 dirty (< rebuild threshold of 28165.600000000002). re-sorting item-by-item (internaltype=LibraryTrack)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:11 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryPerformer:16 dirty items, rebuild threshold: 2000, rebuilding? False
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryTagDetails:1 dirty items, rebuild threshold: 2000, rebuilding? False
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryTagDetails:1 dirty items, rebuild threshold: 2000, rebuilding? False
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Info: [ProfileDuplicateObjects] [seq=4900] duplicate object in NotifyEndUpdates count: 5, total albums from query perform: 1956 (compare this value to the library stats, should be the same if unfiltered) (might be useful to grab this users database)
06/30 00:45:12 Info: [ProfileDuplicateObjects] [seq=4900] skipping force rebuild, cooldown until 6/30/2025 12:55:12AM
06/30 00:45:12 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:12 Info: [stats] 10437mb Virtual, 4930mb Physical, 2504mb Managed, 2426mb estimated Unmanaged, 444 Handles, 87 Threads
06/30 00:45:13 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:14 Debug: [query] Sooloos.Broker.Music.LibraryAlbum:6 dirty (< rebuild threshold of 2331.2000000000003). re-sorting item-by-item (internaltype=LibraryAlbum)
06/30 00:45:14 Trace: [dbperf] flush 230168 bytes, 288 ops in 29 ms (cumulative 859074339 bytes, 689176 ops in 251914 ms)
06/30 00:45:14 Trace: [library] endmutation in 4878ms
06/30 00:45:14 Trace: [dbperf] flush 0 bytes, 0 ops in 4 ms (cumulative 859074339 bytes, 689176 ops in 251918 ms)
06/30 00:45:14 Trace: [storage/streaming] [Qobuz] Scan reported 0 items modified
06/30 00:45:14 Trace: [storage/streaming] [Qobuz] Scan reported 0 items discovered
06/30 00:45:14 Trace: [storage/streaming] [Qobuz] Scan reported 0 items modified
06/30 00:45:14 Trace: [storage/streaming] [Qobuz] Scan reported 0 items discovered
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770485
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770486
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770487
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770488
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770489
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770490
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770491
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770492
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:48770493
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:51894630
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:51894631
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:51894632
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:51894633
06/30 00:45:14 Debug: [music/storage] [Qobuz Storage Library] processed full update for 202:0:51894634Well, at least it’s doing something 
That’s what they keep telling you: it’s updating the library. Of course, there is no reason why that should consume any significant amount of CPU, but at least it’s telling you what keeps it busy. In my case, there was, I believe, no updating to explain things.
Hello All,
Thanks for your continued interest into this issue. This issue is still in our review queue, but progress is a bit slow, I’ve bumped the development ticket to see if we can speed things up a bit.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.