Closed David-Moreira closed 8 months ago
I have this issue too and it is indeed caused by Duo. I believe it stems from the fact windows thinks another user is currently logged in and using the machine in the background, and putting the PC to sleep would interrupt whatever the second user is doing. Windows will even show you a warning if you try to put the PC to sleep manually.
I honestly wish that Duo didn't log itself to windows in the background 24/7 whenever the service is running. It should instead only make the Sunshine instance available in the background with the remote user logged out until you connect to Sunshine. And then once you disconnect your sunshine session the remote windows user should be logged out and remain so as long as you're disconnected.
The current implementation is wasteful when it comes to hardware resources and it causes issues such as the ones mentioned in OP.
A workaround to force the pc to sleep atm is to use a powershell script, that will ignore the second user in the background and force logout. You can use it with the On Idle condition in Task Scheduler. Ask ChatGPT if you don't know how.
The current implementation is wasteful when it comes to hardware resources and it causes issues such as the ones mentioned in OP.
My pc is in my living room, and I actually can tell that my cpu fan keeps spinning up from time to time (which again I didn't experience before as the PC would go to sleep/hibernate), so while I'm not entirely sure it's Duo's fault, it might be doing something continuously from time to time?
A workaround to force the pc to sleep atm is to use a powershell script, that will ignore the second user in the background and force logout. You can use it with the On Idle condition in Task Scheduler. Ask ChatGPT if you don't know how.
This is actually useful as a temporary workaround If I can figure it out, Thanks!
Would be awesome if Duo could improve on this somehow though.
To implement on-demand session spawning we'd need to implement a whole array of changes in Sunshine first.
The biggest issue we'd have to address first is the fact that Sunshine requires a session to be present and active before starting, which undermines the concept as a whole.
To implement on-demand session spawning we'd need to implement a whole array of changes in Sunshine first.
The biggest issue we'd have to address first is the fact that Sunshine requires a session to be present and active before starting, which undermines the concept as a whole.
Would on-demand session spawning be the only way to fix this specific issue though?
Sunshine requires a session to be present and active before starting.
Hmm I see. I worked around this limitation by programmatically turning the Duo service on/off whenever I want to use it. Using a batch file with commands sc start Duo
and sc stop Duo
which I then initiate using a webhook via a GET request from Tasker whenever the app Moonlight is launched/closed on my Android handheld, and it works fairly well. That said, I would much prefer this being built into Duo somehow so I don't have to keep Tasker monitoring my app usage, which impacts battery life.
...
I wonder if the "Wake on LAN" button in Moonlight can be exploited somehow to start the Duo service, and similarly the "Quit Session" button can stop the service. That would be a decent temporary fix, I think. I certainly don't need the service to be running all the time otherwise, I only want the instance to be accessible whenever I need it.
I wonder if the "Wake on LAN" button in Moonlight can be exploited somehow to start the Duo service, and similarly the "Quit Session" button can stop the service. That would be a decent temporary fix, I think.
The instance quit message could definitely serve as a "shutdown trigger", but the Wake-On-LAN request isn't specific enough to serve as a clear enough "start trigger", due to it only transmitting the physical address of the network adapter that Moonlight last saw, which is the host PC itself.
There just isn't any data in that request that could be used to identify what instance the user is asking for specifically.
This could of course be fixed by forking & building a custom Moonlight client, but there's so many of these out there for so many different devices that I'd prefer to stay within the specifications of standard Moonlight, if possible.
Would on-demand session spawning be the only way to fix this specific issue though?
Of course not, we could also just develop a WebUI for Duo, similar to how Sunshine does it, that allows for manual control of sessions, which, IMO, is the best way to fix this problem.
How about we run Sunshine as a service instead? That will allow us to sign out of the windows account without killing the Sunshine instance. So whenever Duo service starts > log into windows > wait for Sunshine to initiate > sign out. The instance will then remain accessible without taking up any resources or keeping windows from idling, and the user will simply have to log in using their password every time they want to start using it. Then Sunshine's undo command can simply be logoff
.
P.S. this is default behavior of official Sunshine, it installs itself as a service and allows you to log out without losing access.
@samkitty It's a bit more complicated than that, as the virtual display adapter and monitor instances get destroyed on a session disconnect, rendering all shared handles invalid.
I'll take a bit more trial and error on my end to see what the best way forward might be.
I still think that some kind of explicit control via a WebUI / webservice might be key here.
Version 1.3.8 implements a WebUI that lets people start & stop instances on-demand, which solves this issue as a side-effect.
Version 1.3.8 implements a WebUI that lets people start & stop instances on-demand, which solves this issue as a side-effect.
Awesome, that will do. Though I needed to allow the 38299 port through windows firewall for http://local.ip:38299 to be accessible on my local network.
Now I wonder if there's a way to trigger the stop/start button programmatically like I used to do with the DuoService directly. Is there any query I can add to the URL to call the functions?
Is there any query I can add to the URL to call the functions?
Found the solution inside the Javascript file:
http://127.0.0.1:38299/instances/<instance name>/start
and http://127.0.0.1:38299/instances/<instance name>/stop
Thanks a bunch @Black-Seraph, awesome update ᵔ⤙ᵔ
Yes the api call is useful to at least start/stop on demand. Thank you.
Glad to hear that you guys now have everything you need.
If there's ever a need to add additional functionality, let me know.
Version 1.3.8 implements a WebUI that lets people start & stop instances on-demand, which solves this issue as a side-effect.
Using Version 1.4.8 and once the Instance is started (whether auto startup or manual) the PC will not sleep until it has been restarted. I have tried disabling the service via the web-ui and the windows Duo Manager application. The Duo service is not running but the PC will not sleep if it has been started at any point.
powercfg -requests shows the "PERFBOOST: [DRIVER] Legacy Kernel Caller, Power Manager" even after the instance/service is stopped.
I generally have my pc turned on 24/7 and rely on it going to sleep/hibernate when I'm not on it.
I recently noticed that my PC stopped going to sleep. And I have the feeling that Duo might be stopping it from going to sleep. Today I tried disabling Duo from startup & restart the pc, the pc promptly went to sleep, so I suspect that's it.
Could you please confirm that it might indeed be Duo, and let me know whether there's a way to use Duo and have the pc sleep as expected?
Thanks!