Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
None
Describe the Bug
While actively streaming (no client disconnect, no config change, no app switch), Sunshine periodically logs Starting async encoder teardown on its own, with nothing preceding it that would explain the trigger. Right after, I get:
Warning: Previous active display [\.\DISPLAY1] is no longer present
Error: NvEnc: NvEncOpenEncodeSessionEx() failed: NV_ENC_ERR_NO_ENCODE_DEVICE
repeated dozens to hundreds of times over a few seconds. It sometimes also briefly mentions my secondary monitor ([\.\DISPLAY5]) even though that's not the active capture target. The session usually recovers on its own within a few seconds (correctly re-acquiring the right GPU), but sometimes drops the client entirely and I have to reconnect.
On the Moonlight client side, the log shows this is a server-initiated termination, not a network issue:
SDL Info (0): Server notified termination reason: 0x80030023
SDL Error (0): Connection terminated: 0
I traced 0x80030023 into src/stream.cpp - it's sent as a "graceful termination" reason when the main server loop's proc::proc.running() == 0 check trips.
Setup: RTX 5070 Ti, two monitors (primary 4K/144Hz HDR TV via output_name pinned to its device_id, secondary 4K/240Hz monitor), Windows 11 Pro, LAN-only streaming.
Before reporting, I spent a while ruling out anything on my end that could explain it:
Screensaver and display sleep timeout - both confirmed disabled
A machine-inactivity lock policy - not configured
Scheduled tasks on a matching interval - none found
Windows/NVIDIA driver crash or TDR - Event Viewer (System + Application) is completely silent at the exact failure timestamps, down to the second
Parsec (installed but not running) - ruled out
Second monitor being the trigger - tested by switching Windows to single-display mode and restarting Sunshine fresh; the identical teardown still happened, and the log still referenced the secondary display even though Windows wasn't using it
An active RDP session stealing the interactive session - this turned out to be a real, separate issue on my end (fixed by disconnecting RDP before connecting), but this specific teardown still happens with RDP fully disconnected and the console session properly active
Under a clean isolated test (one connection, nothing else changed), two consecutive occurrences were exactly 60 minutes 1 second apart. Other times it's been anywhere from ~90 seconds to ~50 minutes, so I don't think it's on a fixed timer - feels more like it's reacting to some internal state/condition I can't see from the logs.
One thing that helped: explicitly pinning output_name to my primary display's device_id stopped it from occasionally grabbing my secondary monitor's much weaker integrated GPU when this happens, which was making the symptom a lot worse (resolution mismatch on recovery). It didn't stop the teardown itself though.
Expected Behavior
The encoder/capture pipeline shouldn't tear itself down and briefly fail mid-session without an external trigger (client disconnect, display topology change, config change). If this is an intentional periodic re-validation of some kind, it shouldn't cause NVENC session failures or brief display loss on a completely unchanged display configuration.
Additional Context
No response
Host Operating System
Windows
Operating System Version
10.0.26200
Architecture
amd64/x86_64
Package
Windows - msi installer (recommended)
GPU Type
NVIDIA
GPU Model
NVIDIA GeForce RTX 5070 Ti
GPU Driver/Mesa Version
32.0.16.1692
Capture Method
Desktop Duplication API (Windows)
Apps
Note: I'm using a custom cmd for "Desktop" (a hidden VBScript that does nothing but keep a real process alive) instead of the default empty-cmd placebo mode - that's an unrelated workaround for a different issue (Sunshine's proc::running() treating a cmd-less Desktop app as always "running" via a placebo flag, which breaks if terminate() ever fires). Mentioning it so the odd-looking app entry doesn't cause confusion - this bug reproduces independent of that.
{
"env": {},
"apps": [
{
"name": "Desktop",
"cmd": "wscript.exe //B \"C:\\Program Files\\Sunshine\\scripts\\keepalive.vbs\"",
"auto-detach": false,
"image-path": "desktop.png"
},
{
"name": "Steam Big Picture",
"cmd": "steam://open/bigpicture",
"prep-cmd": [{"do": "", "undo": "steam://close/bigpicture"}],
"auto-detach": true,
"wait-all": true,
"image-path": "steam.png"
}
]
}Log output
See readme.md and sunshine_server.log and moonlight_client.log in the gist url below.
Online logs
https://gist.github.com/miahmartin/6e456fd14da7c3f5f76cc3bbbf8b69e7
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
None
Describe the Bug
While actively streaming (no client disconnect, no config change, no app switch), Sunshine periodically logs Starting async encoder teardown on its own, with nothing preceding it that would explain the trigger. Right after, I get:
Warning: Previous active display [\.\DISPLAY1] is no longer present
Error: NvEnc: NvEncOpenEncodeSessionEx() failed: NV_ENC_ERR_NO_ENCODE_DEVICE
repeated dozens to hundreds of times over a few seconds. It sometimes also briefly mentions my secondary monitor ([\.\DISPLAY5]) even though that's not the active capture target. The session usually recovers on its own within a few seconds (correctly re-acquiring the right GPU), but sometimes drops the client entirely and I have to reconnect.
On the Moonlight client side, the log shows this is a server-initiated termination, not a network issue:
SDL Info (0): Server notified termination reason: 0x80030023
SDL Error (0): Connection terminated: 0
I traced 0x80030023 into src/stream.cpp - it's sent as a "graceful termination" reason when the main server loop's proc::proc.running() == 0 check trips.
Setup: RTX 5070 Ti, two monitors (primary 4K/144Hz HDR TV via output_name pinned to its device_id, secondary 4K/240Hz monitor), Windows 11 Pro, LAN-only streaming.
Before reporting, I spent a while ruling out anything on my end that could explain it:
Screensaver and display sleep timeout - both confirmed disabled
A machine-inactivity lock policy - not configured
Scheduled tasks on a matching interval - none found
Windows/NVIDIA driver crash or TDR - Event Viewer (System + Application) is completely silent at the exact failure timestamps, down to the second
Parsec (installed but not running) - ruled out
Second monitor being the trigger - tested by switching Windows to single-display mode and restarting Sunshine fresh; the identical teardown still happened, and the log still referenced the secondary display even though Windows wasn't using it
An active RDP session stealing the interactive session - this turned out to be a real, separate issue on my end (fixed by disconnecting RDP before connecting), but this specific teardown still happens with RDP fully disconnected and the console session properly active
Under a clean isolated test (one connection, nothing else changed), two consecutive occurrences were exactly 60 minutes 1 second apart. Other times it's been anywhere from ~90 seconds to ~50 minutes, so I don't think it's on a fixed timer - feels more like it's reacting to some internal state/condition I can't see from the logs.
One thing that helped: explicitly pinning output_name to my primary display's device_id stopped it from occasionally grabbing my secondary monitor's much weaker integrated GPU when this happens, which was making the symptom a lot worse (resolution mismatch on recovery). It didn't stop the teardown itself though.
Expected Behavior
The encoder/capture pipeline shouldn't tear itself down and briefly fail mid-session without an external trigger (client disconnect, display topology change, config change). If this is an intentional periodic re-validation of some kind, it shouldn't cause NVENC session failures or brief display loss on a completely unchanged display configuration.
Additional Context
No response
Host Operating System
Windows
Operating System Version
10.0.26200
Architecture
amd64/x86_64
Package
Windows - msi installer (recommended)
GPU Type
NVIDIA
GPU Model
NVIDIA GeForce RTX 5070 Ti
GPU Driver/Mesa Version
32.0.16.1692
Capture Method
Desktop Duplication API (Windows)
Apps
Log output
See readme.md and sunshine_server.log and moonlight_client.log in the gist url below.Online logs
https://gist.github.com/miahmartin/6e456fd14da7c3f5f76cc3bbbf8b69e7