Roon is preventing Windows from sleeping [Ticket In]

Hmm, was uncategorized, fixed.

Man this forum software is terrible; original post was dropped in limbo with no category and tagged with nothing. Let’s try again.

I’m running Roon (Core only, not being used as a local playback source, via RoonServer.exe) on a Windows 10 machine. It is keeping the PC from ever going into sleep mode – is this expected behavior? Kind of annoying. I know that it’s responsible for keeping the PC awake as checking powercfg -requests from the shell shows that RoonAppliance.exe is keeping the system from sleeping.

@support Can you clarify if this is an expected behavior, or not? If it is, I can stop troubleshooting it and come up with workarounds for putting the machine to sleep when not in use.

Hey @Joselito_Tagarao – I merged your posts here. You can always find your posts by clicking on your avatar in the top-right.

We should prevent sleep only when music is playing, but that means on any zone – even if you don’t have a local zone connected to your Core, if you’re playing in the Living Room (or whatever) the server should not go to sleep.

If you don’t have any music playing on any zone, we can have our QA team look at this and do some testing, then Support will follow up here. Can you confirm whether anything is playing?

1 Like

There’s definitely no music playing anywhere, and I’ve even cut shut down all the Roon clients on all devices (other machines, tablets, and phones). Still stays awake.

Addendum: the actual music store it scans is on a NAS, not sure if that changes anything. It shouldn’t, but who knows?

Thank you for the continued feedback @Joselito_Tagarao and more importantly, thank you for your patience here. Both are very appreciated!

Continuing forward, I spoked about this support issue you raised with Mike this morning and asked our tech team if they could try and reproduce this behavior you are reporting with your setup. Our techs just got back to me and said they were unable to reproduce this behavior where Roon is preventing WIn10 to go to sleep even when no music is being played.

In light of this observation, may I very kindly ask you to please provide me with the following:

  • Please provide a brief but accurate description of your current setup using this link as a guide.

  • Please outline the steps you are taking (procedurally speaking) that trigger this behavior with your setup. The more detail you can provide, the better :microscope:


Good news - I found out what the issue was. It was a combo of the Roon Core needing an update and a device that wasn’t claimed by a driver; something about Windows constantly trying to load a driver every time Roon did anything caused it to constantly stay awake and report RoonAppliance.exe as the problem . Resolving either one allowed the machine to sleep.


So I thought this was solved due to the errant unclaimed driver interacting with Roon, but that was only part of the problem. Turns out if you have Roon running it will sleep normally. However if you RDP into the machine at any point (and disconnect your session), RoonAppliance.exe will never allow the machine to go to sleep after that. You have to reboot the machine to return to normal. Running Roon / Roonserver again will result in normal sleep operations, until you make an RDP connection again.

I’m guessing this has something to do with the sketchy Roon security measures in place that don’t like RDP sessions with with the GUI (where it complains about it needing OpenGL access), probably due to audio redirection. Note that this is the server version, not the GUI version, but who knows.

Continuing the discussion from Roon is preventing Windows from sleeping [Solved]:

Hi @Joselito_Tagarao ---- Thank you for the follow up on this behavior you raised in “support”. Being as the original thread you had posted was not “closed out” I have migrated your most recent post back to the original thread and removed the “[solved]” from the title for further troubleshooting.

Continuing forward, I know we have user whom make use of team viewer as opposed to using RDP (which we have seen issues with) and am curious if you have tried a different method of remoting into the RoonServer box, and if so what was the experience like?


I mean I guess I could try TeamViewer, but it seems to be a little strange to implement a workaround rather than focusing on fixing the actual problem. I’d be more inclined to continue supporting Roon and using workarounds if I knew this was an issue that was actively being worked on / had a bug report open on rather than just living with the fact that it’s a known issue that might never be addressed.

Just adding my experience with Roon preventing Windows from sleeping. I have confirmed that once I access my Core via a remote Control (iOS app or separate Windows tablet used only for control), my Windows HTPC running the Roon Core/Control will not sleep anymore. Here’s what I did:

  1. Cold reboot of PC and used Roon for a bit from the same PC as a Control.
  2. Minimized Roon Core/Controller on the PC. (Kept it “running” but minimized and not being used.)
  3. After some time, PC went to sleep just as expected and as desired.
  4. Next day, woke PC (still keeping Roon minimized), but accessed this time via iOS Controller app. Computer will no longer sleep!
  5. “Powercfg -requests” confirms that roon.exe is the only item shown preventing the PC from sleeping.

As another poster noted, it seems once you use a remote application into the Roon Core, something prevents the PC from ever sleeping again (until next cold restart).

Note that in my case my amplifier draws several hundred watts and is triggered on and off along with my PC sleeping/waking. So an awake PC means my amplifier is also fully powered on. Roon preventing the PC from sleeping also prevents my amplifier from entering standby.

Just to add myself to the list, I had reported the same issue with my Macbook a long time ago and after some poster reported it being possibly connected to remote control of the Roon core I checked it, and in fact it seemed that my Macbook Roon Core will sleep if I don’t connect via the MacOS built-in Screen Sharing which I need to do most of the time though. So I too am still having problems with Roon preventing sleep.

Hey guys – I’m going to have the QA team look into this. (cc @vova)

Assuming we’re able to reproduce, we’ll get this fixed for a future release. If we can’t reproduce, we’ll come back to you guys with some more questions.

Thanks all!

Thanks for report. I think we’ve reproduced the bug.

Has there been a solution to this? I can’t get my computer with Roon Server on Windows to sleep.

Hello @Shayne_Hodge,

We have been able to reproduce this issue in-house and a ticket has been filed. It is still pending review by the dev team and as soon as we have any other new info to share we will update this thread.

– Noris

Hello Roon,

am testing in trial here, and this is a deal breaker for me. I have a powerful desktop computer which I hardly use (occasional gaming and video editing) which is perfectly capable of running Roon. However, if computer is not sleeping automatically, my energy bill will be pretty high. This would be the only reason for me to buy a separate NUC running ROCK, which is pretty expensive. Any more news on this?

If I quit and restart Roonserver in Windows, computer sleeps OK. If Roon control app in Android is opened, computer still sleeps. If music is played and paused (Roon endpoint on Raspberry pi, Allo Boss DAC), computer stops sleeping.

Hi @Pieter81,

Thank you for your additional report here. We have an active ticket regarding this behavior and we have managed to reproduce this issue in-house but I do not have any further details to share at this time. As son as we have any new information regarding this issue I or one of the staff members will be sure to update this thread. Thanks!

Hi Roon Team,
I have similar issue, any update on the resolution so far. Thanks.

Hello @Eric_Chung,

There is a ticket with the dev team regarding this behavior, but it hasn’t reached the dev team’s queue yet. I can’t comment on an exact timeline but I’ll remind the technical team that this issue is still ongoing, thanks for your additional report!