Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
After updating to the pre-release, the client does receive twice the frames per second, but the image redraws and then reverts completely to the previous background. I had to go back to the stable version, which only delivers half of the captured frames. The pre-release says this is fixed, but since the screen does not refresh correctly, it is unusable on my system.
Expected Behavior
I expected the pre-release to deliver both things at once: the full 60 fps that #5200 restores, and a picture that stays on screen. Instead the fix trades one problem for a worse one on my client. Going back to the pre-#5200 build gives me a correct picture again, but only half the frames.
Additional Context
Client log, one line per frame (3585/minute at 60 fps):
[h264 @ 0x...] number of reference frames (1+1) exceeds max
(1; probably corrupt input), discarding one
Host telemetry on the pre-#5200 build (VCPRateControlSession):
input_fps=60.00 enc_fps=60.00 tx_fps=30.00 idr_fps=30.00
bit_rate 18190023/10988000 enc_time=2.96 ms
So on the old build the encoder emits half the captured frames, all of them
IDR, and overshoots its bitrate target by 1.66x (18.19 Mbps used against an
11.0 Mbps target). Because every frame is intra-coded, an IDLE desktop costs
the same as full motion: 23.6 Mbps measured at the client, ~10 GB/hour.
It also costs client-side diagnostics: 99.3% of the Moonlight log is
"Network dropped 1 frame" (164691 of 165775 lines), which fills the 10 MB
log cap in about 100 minutes of streaming.
Reproduced twice on the same host, checking which binary was actually running
each time with the "txt" line of lsof -p .
There is no configuration workaround: the binary exposes only vt_coder,
vt_realtime and vt_software, and the reference-frame restriction is internal
(REF_FRAMES_RESTRICT), driven by what the client negotiates.
Host Operating System
macOS
Operating System Version
macOS 26.5.2 (build 25F84). Affected: sunshine-beta 2026.726.710 (post-#5200). Working: sunshine 2026.516.143833 (pre-#5200)
Architecture
arm64/aarch64
Package
macOS - Homebrew
GPU Type
Apple Silicon
GPU Model
Apple M4
GPU Driver/Mesa Version
n/a (VideoToolbox, macOS 26.5.2 build 25F84)
Capture Method
AVCaptureScreen (macOS)
Apps
Log output
Online logs
No response
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
After updating to the pre-release, the client does receive twice the frames per second, but the image redraws and then reverts completely to the previous background. I had to go back to the stable version, which only delivers half of the captured frames. The pre-release says this is fixed, but since the screen does not refresh correctly, it is unusable on my system.
Expected Behavior
I expected the pre-release to deliver both things at once: the full 60 fps that #5200 restores, and a picture that stays on screen. Instead the fix trades one problem for a worse one on my client. Going back to the pre-#5200 build gives me a correct picture again, but only half the frames.
Additional Context
Client log, one line per frame (3585/minute at 60 fps):
[h264 @ 0x...] number of reference frames (1+1) exceeds max
(1; probably corrupt input), discarding one
Host telemetry on the pre-#5200 build (VCPRateControlSession):
input_fps=60.00 enc_fps=60.00 tx_fps=30.00 idr_fps=30.00
bit_rate 18190023/10988000 enc_time=2.96 ms
So on the old build the encoder emits half the captured frames, all of them
IDR, and overshoots its bitrate target by 1.66x (18.19 Mbps used against an
11.0 Mbps target). Because every frame is intra-coded, an IDLE desktop costs
the same as full motion: 23.6 Mbps measured at the client, ~10 GB/hour.
It also costs client-side diagnostics: 99.3% of the Moonlight log is
"Network dropped 1 frame" (164691 of 165775 lines), which fills the 10 MB
log cap in about 100 minutes of streaming.
Reproduced twice on the same host, checking which binary was actually running
each time with the "txt" line of lsof -p .
There is no configuration workaround: the binary exposes only vt_coder,
vt_realtime and vt_software, and the reference-frame restriction is internal
(REF_FRAMES_RESTRICT), driven by what the client negotiates.
Host Operating System
macOS
Operating System Version
macOS 26.5.2 (build 25F84). Affected: sunshine-beta 2026.726.710 (post-#5200). Working: sunshine 2026.516.143833 (pre-#5200)
Architecture
arm64/aarch64
Package
macOS - Homebrew
GPU Type
Apple Silicon
GPU Model
Apple M4
GPU Driver/Mesa Version
n/a (VideoToolbox, macOS 26.5.2 build 25F84)
Capture Method
AVCaptureScreen (macOS)
Apps
Log output
Online logs
No response