Since the OPRA update, RoonAppliance process keeps hogging CPU resources after the play queue runs to its end. Roon runs on 2018 MacBookPro, Sequoia 15.1.1, playing to KEF LSX original version in Roon Tested mode. Since the very first Roon with OPRA update I noticed my MacBookPro with Roon core starts spinning fans when the playback queue runs out after playing to my KEF LSX. Looking at Roon App on my Ipad I see that although the queue is finished with playback head at the very end of the timeline, the II (pause) icon is still displayed as if the playback continues. And immediately the fans on the macbook start sounding heavily. Looking at the System Monitor at this point, I see that RoonAppliance process steadily consumes 100% of CPU resources. Restarting and the second OPRA update did not fix this. Happens always when the KEF LSX payback queue runs to the end. Does not happen with other endpoints (DAC's connected to System Sound Output or iPad)
Describe your network setup
Fully wired Ethernet setup to KEF LSX connected via Zyxel 105 routers
Thanks for reaching out. It is strange that this issue started for you after the OPRA update, I have seen this kind of behavior in the past from before OPRA (with the queue stopping at the end) but we were not able to get to the bottom of this yet. Can you confirm, if instead of trying to reboot RoonServer if you try to press Command + T in Roon, does that release the audio device and stop the CPU usage?
Hi. Control+T does not remedy the situation. But I noticed that the RoonAppliance CPU usage jumps not at the exact moment the queue ends, but about 1 minute before. Wonder if this corresponds to the types of behaviour observed previously?
In the end my quick workaround is to start playback of a different track (the one where the queue ends/gets stuck not always can be played from a different position) and then stop it. The high CPU usage then stops.
I’m having the same issue. rock on i7 NUC, Kef ls50w (1st gen).could this be the cause for the temperature rise and fan speed issues as reported in several threads these past few days?
This doesn’t help - whether doing this before starting playback or once the CPU usage is already high
This behavior happens at any time, date or track either from local library or Qobuz, as long as it is the last track in the queue playing to KEF LSX I. Observed it about a half-dosen times today. The CPU load starts to jump at different times within 2 minutes to 40 seconds before the end of the last track in queue. It looked as if it was dependent on the length of the track, so I checked both 17-minute and 50-sec tracks, maybe there is some correlation, but I didn’t have time to run a sufficient number of tests.
One more observation: high CPU usage can be remedied only if playing a different track or moving the cursor to a different position of the “stuck” track as long as it is outside this “high CPU tail zone”. If moving the playback head within this 2-min - to 40 sec tail zone and hitting play - nothing happens and the CPU usage remains high.
(or, do you request the exact local time, date and track for some other purpose, like logs?)
Yes, please let us know the exact local time + date, we will enable diagnostics mode for your account and review the logging to see if there are further clues.
Also, just to perform a cleaner test here, if you have the KEFs disabled, reboot your Roon Server, and try to play to another zone for a day or the usual amount of time it takes to see the issue, the behavior does not reproduce, correct?
Hi! In the meantime I tried disabling KEF KSX audiozone and playing to other devices (WiiM Pro Plus @ same network router as KEF and local SMSL USB DAC). As before, none of them exhibited this high CPU bug at the end of the queue. I also updated to the very latest ROON build and enabled KEF LSX zone. – All the same - hight CPU hogged by Roon Appliance at the end of the last track of the queue. I am attaching a screenshot with local time and album track where it happened today. (never mind the VPN icon - its on the ROON remote iPad, none is active on the core, and enabling/disabling it on the remote didn’t change anything)
Thanks for sharing that screenshot and letting us know when the issue occurred. We have a development ticket in related to this behavior and we are investigating this issue. I can’t comment on a timeline of when it will be complete, but once the changes are released, I would be curious to know if it helps with your case. Please be on the lookout for improvements in future Roon release(s). Thanks!
