Closed CrendKing closed 4 months ago
I took some time to redo some tests. I found that the current system state, such as what other processes are running or how they affect the video driver state, could affect the test result of the method above, so I recommend to do a system reboot before testing.
I tested many nightly CI builds from the GitHub Action, and even the earliest non-expired build, https://github.com/LizardByte/Sunshine/actions/runs/6041792681, has the issue. Again, v0.20.0 is fine. So the issue must be introduced between 31e8b798dabf47d5847a1b485f57cf850a15fcae and a3eec98ae177c95bae3734241bcbad3a2960191b.
I currently do not have a MinGW environment to further bisect the root cause. Can someone help?
Nightly builds are available here: https://github.com/LizardByte/Sunshine/releases/tag/nightly-dev
Thanks. But I need nightly builds BEFORE Aug 31. Or more precisely, all nightly builds SINCE v0.20.0 to bisect the root cause. Do you guys somehow archive historical nightly builds?
We only keep artifacts for 90 days.
Thought so. Looks like the only way is to build myself. Gonna take a while... Would anyone be interested to a fix if I can find the culprit commit?
Yes, it would be helpful if you can track down a specific commit that is causing the issue.
Found it. I think it's 11aedf56. I don't know enough about Sunshine to see why though.
FYI, in order to build with the current MinGW, I have to backport some commits. Specifically, https://github.com/LizardByte/Sunshine/commit/f3a257b1 and https://github.com/cgutman/enet/commit/880e41f3ab572ad6d8f064c6cc77e04f46d00956. I verified these wouldn't change the outcome of the issue.
@cgutman I didn't see anything obvious in that commit which could cause this. Any Idea?
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
Still waiting for a proper fix. Is anyone interested in taking this?
As of v0.23.1, I can no longer reproduce the issue. Maybe it's fixed?
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the nightly release?
Describe the Bug
Base line
Install Sunshine as a Windows service and make it auto start. After booting, use Start menu to sleep. Wake it up with mouse, behave normal.
Minimum reproducible steps
Other tests
It seems the trigger must include a command being in the Sunshine application, and the command terminates itself.
Expected Behavior
Regardless if there is a command in the application, or if client quits or not, the host should be able to sleep then wake afterwards.
Additional Context
There is a similar (and probably related) issue at https://github.com/LizardByte/Sunshine/issues/1809. But the trigger seems different. Also, I use WIFI.
Host Operating System
Windows
Operating System Version
Windows 11 23H2
Architecture
64 bit
Sunshine commit or version
0.21.0 and tested in nightly. I verified that earlier versions (such as 0.20.0) does not have the problem.
Package
Windows - Scoop (Third Party) Nightly (https://github.com/LizardByte/Sunshine/commit/29a1b1539fb2e0e82d02e521954b163c6d9d55d1, Portable)
GPU Type
Nvidia
GPU Model
RTX 2070 Super
GPU Driver/Mesa Version
546.17
Capture Method (Linux Only)
No response
Config
Apps
Relevant log output
There is no outstanding log. The last line is just the standard "Process Terminated" line.