High CPU Usage Causing Playback Dropouts in Roon (ref#EYIDUA)

Papatistos · April 5, 2025, 11:02am

What’s happening?

· I am experiencing freezes or crashes

How can we help?

· I am experiencing freezes or crashes

Other options

· Other

Describe the issue

I am having intermittent playback dropouts and my impression is that it has to do with high CPU usage. I noticed that RoonAppliance is using huge amounts of CPU even without any playback. I have turned off "Background audio analysis".

I checked the logs and found this (see below).

Describe your network setup

This is not a network issue, but the network is using TP-Link devices controlled through the TP-Link Omada network controller

04/05 12:39:48 Trace: [Broker:Media] [library] endmutation in 31ms
04/05 12:39:51 Trace: [Broker:Media] [library] endmutation in 25ms
04/05 12:39:57 Trace: [Broker:Media] [library] endmutation in 25ms
04/05 12:39:57 Trace: [Broker:Media] [library] endmutation in 32ms
04/05 12:39:57 Trace: [Broker:Media] [library] endmutation in 17ms
04/05 12:39:57 Trace: [Broker:Media] [library] endmutation in 15ms
04/05 12:39:58 Info: [7] [stats] 5455mb Virtual, 1384mb Physical, 791mb Managed, 499 Handles, 99 Threads
04/05 12:40:04 Trace: [Broker:Media] [library] endmutation in 14ms
04/05 12:40:05 Trace: [Broker:Media] [library] endmutation in 31ms
04/05 12:40:08 Trace: [Broker:Media] [library] endmutation in 11ms
04/05 12:40:08 Trace: [Broker:Media] [library] endmutation in 44ms
04/05 12:40:12 Trace: [Broker:Misc] [broker/accounts] [heartbeat] now=04/05/2025 10:40:11 nextauthrefresh=04/05/2025 11:38:48 nextmachineallocate=04/05/2025 12:35:11
04/05 12:40:13 Info: [7] [stats] 5568mb Virtual, 1384mb Physical, 801mb Managed, 499 Handles, 113 Threads
04/05 12:40:18 Trace: [Broker:Media] [library] endmutation in 51ms
04/05 12:40:20 Trace: [Broker:Media] [library] endmutation in 11ms
04/05 12:40:28 Info: [7] [stats] 5624mb Virtual, 1383mb Physical, 720mb Managed, 500 Handles, 120 Threads
04/05 12:40:28 Trace: [Broker:Media] [library] endmutation in 32ms
04/05 12:40:28 Trace: [Broker:Media] [library] endmutation in 17ms
04/05 12:40:39 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:40:43 Info: [7] [stats] 5423mb Virtual, 1383mb Physical, 722mb Managed, 500 Handles, 91 Threads
04/05 12:40:52 Trace: [Broker:Media] [library] endmutation in 13ms
04/05 12:40:56 Trace: [Broker:Media] [library] endmutation in 23ms
04/05 12:40:58 Info: [7] [stats] 5455mb Virtual, 1384mb Physical, 724mb Managed, 500 Handles, 98 Threads
04/05 12:41:05 Info: [Broker:Media] [library stats] tracks: 11423 (hidden: 73), albums: 1228 (hidden: 6), artists: 716, works: 6448, performances: 7348
04/05 12:41:08 Trace: [Broker:Media] [library] endmutation in 62ms
04/05 12:41:09 Trace: [Broker:Media] [library] endmutation in 23ms
04/05 12:41:15 Info: [7] [stats] 5512mb Virtual, 1384mb Physical, 729mb Managed, 499 Handles, 106 Threads
04/05 12:41:30 Info: [7] [stats] 5592mb Virtual, 1384mb Physical, 730mb Managed, 501 Handles, 116 Threads
04/05 12:41:31 Trace: [Broker:Media] [library] endmutation in 67ms
04/05 12:41:36 Trace: [Broker:Media] [library] endmutation in 17ms
04/05 12:41:43 Trace: [Broker:Media] [library] endmutation in 18ms
04/05 12:41:45 Info: [7] [stats] 5423mb Virtual, 1386mb Physical, 735mb Managed, 499 Handles, 95 Threads
04/05 12:41:45 Trace: [Broker:Media] [library] endmutation in 22ms
04/05 12:41:45 Trace: [Broker:Media] [library] endmutation in 27ms
04/05 12:41:48 Trace: [Broker:Media] [library] endmutation in 49ms
04/05 12:41:55 Trace: [Broker:Media] [library] endmutation in 26ms
04/05 12:41:56 Trace: [Broker:Media] [library] endmutation in 19ms
04/05 12:42:00 Info: [7] [stats] 5423mb Virtual, 1384mb Physical, 737mb Managed, 500 Handles, 95 Threads
04/05 12:42:08 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:42:10 Trace: [Broker:Media] [library] endmutation in 19ms
04/05 12:42:15 Info: [7] [stats] 5528mb Virtual, 1385mb Physical, 721mb Managed, 500 Handles, 108 Threads
04/05 12:42:27 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:42:30 Info: [7] [stats] 5552mb Virtual, 1385mb Physical, 723mb Managed, 499 Handles, 111 Threads
04/05 12:42:34 Trace: [Broker:Media] [library] endmutation in 22ms
04/05 12:42:38 Trace: [Broker:Media] [library] endmutation in 20ms
04/05 12:42:39 Trace: [Broker:Media] [library] endmutation in 28ms
04/05 12:42:39 Trace: [Broker:Media] [library] endmutation in 18ms
04/05 12:42:43 Trace: [Broker:Media] [library] endmutation in 32ms
04/05 12:42:44 Trace: [Broker:Media] [library] endmutation in 18ms
04/05 12:42:45 Info: [7] [stats] 5423mb Virtual, 1386mb Physical, 727mb Managed, 500 Handles, 93 Threads
04/05 12:42:58 Trace: [Broker:Media] [library] endmutation in 40ms
04/05 12:43:00 Info: [7] [stats] 5423mb Virtual, 1386mb Physical, 727mb Managed, 500 Handles, 93 Threads
04/05 12:43:06 Trace: [Broker:Media] [library] endmutation in 25ms
04/05 12:43:15 Trace: [Broker:Media] [library] endmutation in 17ms
04/05 12:43:15 Info: [7] [stats] 5560mb Virtual, 1385mb Physical, 734mb Managed, 500 Handles, 112 Threads
04/05 12:43:17 Trace: [Broker:Media] [library] endmutation in 47ms
04/05 12:43:22 Trace: [Broker:Media] [library] endmutation in 28ms
04/05 12:43:23 Trace: [Broker:Media] [library] endmutation in 75ms
04/05 12:43:23 Trace: [Broker:Media] [library] endmutation in 22ms
04/05 12:43:24 Trace: [Broker:Media] [library] endmutation in 36ms
04/05 12:43:24 Trace: [Broker:Media] [library] endmutation in 25ms
04/05 12:43:29 Trace: [Broker:Media] [library] endmutation in 94ms
04/05 12:43:30 Info: [7] [stats] 5560mb Virtual, 1386mb Physical, 734mb Managed, 501 Handles, 112 Threads
04/05 12:43:31 Trace: [Broker:Media] [library] endmutation in 33ms
04/05 12:43:34 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:43:34 Trace: [Broker:Media] [library] endmutation in 41ms
04/05 12:43:45 Trace: [.NET ThreadPool Worker] [roondns] flushed 7 last-known-good entries
04/05 12:43:45 Debug: [.NET ThreadPool Worker] [easyhttp] [4359] POST to https://api.roonlabs.net/swim/1/session/7edf5bc2bf844da98f05a1c23d9c2e83/ping returned after 547 ms, status code: 200, request body size: 2 B
04/05 12:43:45 Trace: [Broker:Media] [library] endmutation in 14ms
04/05 12:43:45 Info: [7] [stats] 5463mb Virtual, 1386mb Physical, 742mb Managed, 502 Handles, 100 Threads
04/05 12:44:00 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:44:01 Info: [7] [stats] 5463mb Virtual, 1385mb Physical, 723mb Managed, 500 Handles, 100 Threads
04/05 12:44:03 Trace: [Broker:Media] [library] endmutation in 26ms
04/05 12:44:05 Info: [Broker:Media] [library stats] tracks: 11423 (hidden: 73), albums: 1228 (hidden: 6), artists: 716, works: 6448, performances: 7348
04/05 12:44:14 Trace: [Broker:Media] [library] endmutation in 19ms
04/05 12:44:16 Info: [7] [stats] 5592mb Virtual, 1386mb Physical, 728mb Managed, 502 Handles, 116 Threads
04/05 12:44:29 Trace: [Broker:Media] [library] endmutation in 15ms
04/05 12:44:31 Info: [7] [stats] 5592mb Virtual, 1386mb Physical, 730mb Managed, 500 Handles, 116 Threads
04/05 12:44:45 Trace: [Broker:Media] [library] endmutation in 22ms
04/05 12:44:46 Info: [7] [stats] 5399mb Virtual, 1386mb Physical, 735mb Managed, 500 Handles, 92 Threads
04/05 12:44:47 Trace: [Broker:Media] [library] endmutation in 97ms
04/05 12:44:49 Trace: [Broker:Media] [library] endmutation in 12ms
04/05 12:44:49 Trace: [Broker:Media] [library] endmutation in 51ms
04/05 12:45:01 Info: [7] [stats] 5399mb Virtual, 1386mb Physical, 738mb Managed, 500 Handles, 92 Threads
04/05 12:45:01 Trace: [Broker:Media] [library] endmutation in 17ms
04/05 12:45:12 Trace: [Broker:Misc] [broker/accounts] [heartbeat] now=04/05/2025 10:45:11 nextauthrefresh=04/05/2025 11:38:48 nextmachineallocate=04/05/2025 12:35:11
04/05 12:45:13 Trace: [Broker:Media] [library] endmutation in 15ms
04/05 12:45:16 Info: [7] [stats] 5576mb Virtual, 1387mb Physical, 742mb Managed, 500 Handles, 114 Threads
04/05 12:45:24 Trace: [Broker:Media] [library] endmutation in 18ms
04/05 12:45:28 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:45:29 Debug: [.NET ThreadPool Worker] [easyhttp] [4360] POST to https://api.roonlabs.net/swim/1/session/181050836c1b438982ca8f4e6ed58cd8/ping returned after 1345 ms, status code: 200, request body size: 2 B
04/05 12:45:31 Info: [7] [stats] 5584mb Virtual, 1386mb Physical, 721mb Managed, 500 Handles, 115 Threads
04/05 12:45:46 Info: [7] [stats] 5399mb Virtual, 1386mb Physical, 727mb Managed, 500 Handles, 88 Threads
04/05 12:45:53 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:45:56 Trace: [Broker:Media] [library] endmutation in 60ms
04/05 12:46:01 Trace: [Broker:Media] [library] endmutation in 39ms
04/05 12:46:01 Info: [7] [stats] 5399mb Virtual, 1386mb Physical, 728mb Managed, 500 Handles, 88 Threads
04/05 12:46:02 Trace: [Broker:Media] [library] endmutation in 17ms
04/05 12:46:16 Info: [7] [stats] 5560mb Virtual, 1386mb Physical, 736mb Managed, 499 Handles, 112 Threads
04/05 12:46:29 Trace: [Broker:Media] [library] endmutation in 31ms
04/05 12:46:31 Info: [7] [stats] 5560mb Virtual, 1386mb Physical, 737mb Managed, 500 Handles, 112 Threads
04/05 12:46:33 Trace: [Broker:Media] [library] endmutation in 15ms
04/05 12:46:34 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:46:40 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:46:46 Info: [7] [stats] 5415mb Virtual, 1387mb Physical, 744mb Managed, 499 Handles, 90 Threads
04/05 12:46:47 Trace: [Broker:Media] [library] endmutation in 22ms
04/05 12:46:55 Trace: [Broker:Media] [library] endmutation in 92ms
04/05 12:47:02 Info: [7] [stats] 5415mb Virtual, 1386mb Physical, 745mb Managed, 500 Handles, 90 Threads
04/05 12:47:05 Info: [Broker:Media] [library stats] tracks: 11423 (hidden: 73), albums: 1228 (hidden: 6), artists: 716, works: 6448, performances: 7348
04/05 12:47:10 Trace: [Broker:Media] [library] endmutation in 46ms
04/05 12:47:13 Trace: [Broker:Media] [library] endmutation in 41ms
04/05 12:47:15 Trace: [Broker:Media] [library] endmutation in 19ms
04/05 12:47:17 Info: [7] [stats] 5552mb Virtual, 1386mb Physical, 727mb Managed, 500 Handles, 111 Threads
04/05 12:47:22 Trace: [Broker:Media] [library] endmutation in 33ms
04/05 12:47:25 Trace: [Broker:Media] [library] endmutation in 19ms
04/05 12:47:26 Trace: [Broker:Media] [library] endmutation in 15ms
04/05 12:47:30 Trace: [Broker:Media] [library] endmutation in 16ms
04/05 12:47:32 Info: [7] [stats] 5552mb Virtual, 1386mb Physical, 728mb Managed, 500 Handles, 110 Threads
04/05 12:47:47 Info: [7] [stats] 5576mb Virtual, 1386mb Physical, 731mb Managed, 499 Handles, 114 Threads
04/05 12:47:56 Trace: [Broker:Media] [library] endmutation in 78ms
04/05 12:48:00 Trace: [Broker:Media] [library] endmutation in 15ms
04/05 12:48:02 Info: [7] [stats] 5640mb Virtual, 1386mb Physical, 734mb Managed, 499 Handles, 122 Threads
04/05 12:48:04 Trace: [Broker:Media] [library] endmutation in 35ms

Papatistos · April 5, 2025, 11:32am

Some more information:

I am not using any SONOS equipment
Assuming that the “endmutation” messages have something to do with database being updated, I disabled all my storage folders as well as all my streaming services (i.e. Tidal). This did not change anything.

vadim · April 7, 2025, 1:26pm

Hello @Papatistos,

Thank you for reaching out to us.

Could you please provide more detailed information about the hardware where your Roon Server is installed? Based on our diagnostic checks, it appears that the server is running on a virtual machine (VM). Could you also confirm whether you are using Docker for this setup?

Does the issue is happened outside of the VM for the same libary? Does the issue gone away for some time after the server reboot?

Looking forward to your response.

Kind regards,
Vadim

Papatistos · April 7, 2025, 2:21pm

Yes, I am running this docker image: steefdebruijn/docker-roonserver

Yes, docker is running on a virtual linux machine on a VMWare ESXi host.

When I created this ticket, the Host CPU was a Celeron G3930. Meanwhile, I have upgraded the CPU to a Xeon E3-1270 v5. The VM has 24 GB of RAM.

Sorry, I don’t understand what you mean here.

I don’t think so. I’m, not able to restart the entire server now, but I restarted the container. Here is its CPU usage before the restart:

(Note that this more than 12 hours after any music has been played or any interaction with the server took place)

Here is the resource usage after restart:

daniel · April 7, 2025, 7:22pm

Hi @Papatistos,

What we’d like to find out is whether the high CPU usage still occurs if you run Roon Server outside of Docker and the VM, using the same library. Docker and VMs aren’t officially supported environments for Roon, so if the issue only occurs there, you will need to post this in the Tinkering section of Community. But if it happens outside of Docker as well, we can continue troubleshooting with you.

Papatistos · April 7, 2025, 8:47pm

So, you are saying I should run Roon on my Mac, for example, or maybe my old Linux laptop with the same settings and only if I get the same kind of idle CPU usage, you can investigate further?

I don’t think I have time this week to set up another Roon instance (I’m not even sure what will happen, when I add another Roon instance to my network, but I assume that I’ll have to turn the first one off, which means I can’t use it, right?), but what I can say is that even when I disable all my storage folders and my Tidal service (i.e. my entire library), Roon continues to use CPU.

So the CPU usage is not related to my library. Or does it keep the library even when I disable the sources? In that case, the more correct conclusion would be that the CPU usage is not related to the storage/streaming service.

Since the log seems to tell us something about what Roon is doing when using CPU in idle state (Trace: [Broker:Media] [library] endmutation in 16ms), could you tell us what this means?

connor · April 7, 2025, 10:34pm

Hi @Papatistos,

Thank you for your post. An endmutation trace simply means that a library update has occurred. This trace will occur thousands of times in RoonServer logs without any consequence during background indexing. In the absence of critical failures, it’s completely expected to see these concentrations of updates in logs.

That doesn’t mean dropouts are anticipated, however. We’d like to investigate these dropouts further.

Do you receive any error message in the UI? These are hard-coded to the transport and will give a clear indication of why the server has stopped playback.

What we do see in diagnostics are I/O failures related to process locking. Another container is also running Roon, or Roon can’t access host tools for another reason. Have you previously installed Roon in this same container before, or elsewhere on the same machine?

We don’t see Roon suffering from resource constraints during playback - the processing available for DSP remains well above 1.0x:

[HighQuality 84.6x, 16/44 TIDAL FLAC => 24/48] [100% buf] [PLAYING @ 5:05/8:21] Spiritual - Charlie Haden / Pat Metheny / Josh Haden

(note the 84.6x above, as this refers to processing available for transcoding from 16/44 - 24/48).

Can you provide an approximate timestamp of when a playback dropout last occurred? We’d like to pinpoint the event in diagnostics to see what RoonServer reports.

Thanks!

vadim · April 7, 2025, 11:36pm

Hello @Papatistos,

Based on my experience, monitoring tools like the one shown in the screenshot typically treat system load per core as a percentage, where 100% usage corresponds to the full utilization of a single core. For instance, a CPU load of 140% would indicate that 1.4 cores are being utilized at their maximum capacity combined.

To monitor the CPU usage of the Roon Docker containers in real time, you can use the following command:

docker stats

And provide us with the higest CPU load by the container itself.

Additionally, the metrics you’re observing represent the overall system load, not just the Roon Server, as it’s running inside a Docker container. This is an important distinction since the values account for all system processes.

Given that the server is running on an Intel Xeon E3-1270 v5 @ 3.60GHz—a 4-core, 8-thread processor—the maximum CPU load would be 400%, corresponding to 100% per core.

Papatistos · April 8, 2025, 1:20am

Thank you @connor and @vadim for your responses. I went ahead and spun up another Roon server on my MacMini (using the Roon app), waited for it to index all the storage (same as in the first instance). I didn’t bother adding tidal. The result is that even on my M1 Mac mini, it uses between 10% and 50% CPU (i.e. 10%-50% of one M1 core. I don’t know how Xeon cores compare to M1 cores, but they are definitely much weaker, so, very roughly speaking, I am seeing the same (or possibly more) idle CPU usage on the M1 mini as I do with the docker instance.

Just to clarify the stats I provided earlier:

Yes, this is my understanding. The "monitoring too"l shown in the screenshot is Portainer and it show the CPU usage of the roon container only. I assume it uses docker stats and visualizes the output.

So what we’re seeing in the screenshots is that Roon moves between 0 and 130% of a Xeon core in idle state. I have no similar visualization of the stats on the M1 mini, but here is a snapshot from Activity monitor:

(I’m actually unsure what the RoonServer process is. I never noticed it before I took the screenshot, probably because it is at zero CPU. I assume it’s the webserver serving the UI to the client app? In any case, just to clarify: it is the RoonAppliance that is using the CPU in both of my instances.)

Not all the cores are assigned to the VM on which docker is running, only 2 cores (4 threads). There are 28 docker containers running on that machine, including a Lyrion Music Server with the exact same set of tracks as the one in Roon, and none of them comes even close to the CPU usage of Roon.

You say that it is normal that Roon is constantly updating the library. Why is it doing that? Based on what, given that both Tidal and the local storage folders are deactivated? And even if it still had access to the folders, what is it updating when the files haven’t changed a bit in years?

I sometimes got an error message stating something like Tidal being too slow and that the track skipped ahead because of this. But I think that is unrelated to the issue we’re discussing here. The dropouts I’m talking about here are much shorter (often less than a second) and don’t cause the track to be skipped. So, I guess the answer is: no, I’m not getting any error message.

What are the time stamps for these I/O failures? I suspect that these occurred during a rather short time span a few days ago when I recreated the docker container to change its name and somehow missed to stop and destroy the previous one. During those few minutes, there were indeed two containers running simultaneously on the same machine. But that didn’t result in dropouts because I wasn’t listening to music.

I don’t think I’ve had any dropout since I upgraded the CPU, but I’ll note the time when it happens again and will let you know.

Regardless of the dropouts, I’m curious to understand why Roon is using so much CPU for no reason. If one thread consumes 10 W at 100%, Roon is consuming a significant chunk of energy, given that it runs 24/7…

vadim · April 8, 2025, 4:48pm

Hello @Papatistos,

Regarding the elevated CPU usage by the RoonAppliance process — this is expected behavior. The RoonAppliance handles the core logic of the Roon Server, including metadata updates, indexing, library management, and database backups. Even if Tidal and local storage are disabled, the server may still perform background tasks as part of its regular maintenance routines.

It’s also important to note that these tasks are executed independently for each new Roon Server instance. So when a new server is spun up, even on the same machine, the system reprocesses and rebuilds its internal structures, which can result in temporarily increased CPU usage.

This usage should decrease once all background tasks, including backups and indexing, metadata updates are completed. If the usage remains high for an extended period or impacts playback, please share the approximate timestamp of the issue so we can investigate it more accurately in diagnostics.

Seems the original CPU preasure issue wasn’t related to the Roon product itself, please let us know if you have any other questions or concerns related to product.

Papatistos · April 8, 2025, 8:28pm

Thanks again for explaining.

I’m not sure how you can conclude that the issue is not related to ”the Roon product itself” but I assume you are referring to the fact that my docker setup is considered tinkering.

In any case, I will make sure to note the exact time when more issues arise.

If I understand you correctly, higher CPU activity in idle mode is expected for several days after the initial scan. Could you give an indication how long this consolidation phase can be expected to last with a library of 12000 tracks?

Do you have an example for what I kind of maintenance task Roon is performimg?

You mention ” metadata updates, indexing, library management, and database backups”, but metadata updates and indexing don’t apply here, nor are any backups being created. What kind of library management is needed?

From what I can see, all the wave forms have been generated during the initial scan, dynamic range is also in place. I’m having a hard time understanding what might justify such immense resource usage, especially when storage and streaming services are disabled and background scanning is turned off.

In fact, even with background scanning turned on, I don’t quite understand what Roon is doing, given that it fails to do the very thing the background scan is supposed to do: find newly added music files. So it would be really helpful if you could shed some light on this mysterious activity.

benjamin · April 10, 2025, 6:42pm

Hi @Papatistos,

Thanks for the follow-up and for sharing those detailed observations.

You’re absolutely right to want more clarity around what’s happening under the hood, especially given your setup and the resource impact you’re seeing. While it’s true that Docker-based installs aren’t officially supported and fall under the “tinkering” category, that doesn’t mean we want to leave questions like yours unanswered — especially when you’re experiencing behavior that seems excessive or unclear.

To your point: yes, during the first few days after setting up a fresh RoonServer instance, CPU usage can remain elevated as the system performs a range of tasks — but you’re also correct that some of the typical culprits (like metadata updates, audio analysis, or backups) may not fully to apply in your case.

There’s a range of tasks your server performs, with some of the ongoing background activity could still including:

Database integrity checks
RAAT protocol housekeeping and zone discovery
Streaming service sync (even if unused)
Tracking state changes across your endpoints
Preparing content for mobile sync with Roon ARC, if enabled

It’d be really helpful if you could capture the next occurrence along with a timestamp on a supported setup, so we can try to correlate it with any log activity. This might help surface exactly what’s triggering the load, whether it’s a stuck process, a polling loop, or some kind of environmental interaction.

We really appreciate your patience and curiosity!

Papatistos · April 13, 2025, 4:32pm

Thank you, I appreciate that.

Correct me if I’m wrong, but none of these, not even all of them combined, comes even close to explaining the kind of CPU usage we’re seing.

To illustrate what I’m talking about, I stopped the Roon container from 17:25 to 17:36 to see how the CPU usage of the host changes:

As you can see, when Roon is not running (in idle mode), CPU usage (of the entire Xeon CPU, not just one core or one thread) goes from 35% to 15%. In other words, Roon is using more CPU that all the other 27 containers combined, plus two other virtual machines (one running Home Assistant, the other running a TrueNAS system).

Think about it: Roon (in idle mode) = 27 containers + a TrueNAS system + a HAOS system.

Wouldn’t you agree that something is not right here?

To make this kind of resource consumtion a bit less abstract, I also monitored the power consumption of the host system. When Roon is off, the system uses 47.37 W:

When Roon is back on, it uses 55.26 W (and, yes, I excluded the initial peak of up to 70 W when the Roon container spins up):

In other words: Roon uses 8W of power while in idle mode. (And note that is is really the Roon softare alone, because all hardware losses and inefficiencies are the same in both scenarios.) 8 Watts!!

Do you agree that there is something to fix here?

I hope you can find something useful in your logs. The testing period above corresponds to 15:26 to 15:43 UTC (on 13 April 2025). Roon was off between 15:26 and 15:35. If you want to exclude any effects related to restarting Roon, look before 15:26 when it was idling for some time.

benjamin · April 14, 2025, 10:30pm

Hi @Papatistos,

We appreciate your findings here - can you please reproduce the behavior within a supported setup:

Thank you!

Papatistos · April 15, 2025, 8:31pm

I have shown earlier that the same high CPU usage exists when I use the Mac App as my Roon server. This is a supported setup, right?

Since changing my setup to the Mac app is quite laborious and because I don’t have the same tools for visualizing CPU load and energy consumption for the Mac setup, please understand that I am not going to invest time and energy into repoducing the observed behaviour on Mac.

Are you saying that you are unable to produce any of what I have reported? What idle CPU usage is Roon expected to have on a Mac? If you can reproduce the kind of CPU I reported above,

What do the logs show for the reported test?

vadim · April 17, 2025, 12:16pm

Hello @Papatistos ,

Thank you for your patience and for sharing the details of your setup. Based on our analysis, we want to clarify that the behavior you are experiencing is actually part of the normal operation of the product.

Roon regularly processes and updates its internal database, including indexing and metadata updates. During this time, the CPU usage may be higher, but once the background tasks are completed, the CPU consumption should decrease. However, if the product detects updates on our servers (such as new content or metadata), it may trigger another round of database processing, which could cause a temporary increase in CPU usage.

We have reviewed the logs and provided screenshots and can confirm that the CPU usage does not appear to be increasing exponentially, and we haven’t observed any indications of underlying issues with CPU performance or CPU leak.

This is considered normal behavior for the product, and we do not see any problems with CPU consumption at this time.

If you experience any other issues, please let us know and we will investigate further.

Kind regards,
Vadim