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…