Periodic frame drop (~1 frame every ~2 s) on Android client at 2560x1600 despite clean host/network stats
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- cpp
- Lĩnh vực
- backend, performance
Hướng nghiên cứu
Start by examining the attached Sunshine log and the frame pacing, encoding, and packet pacing paths; the report does not identify a specific source file or test. Compare the client’s incoming and rendering rates with the host’s frame timing to locate where the roughly 0.49 FPS gap is introduced. Done means identifying a reproducible cause and confirming that rendering keeps pace without periodic hitches.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Is there an existing issue for this?
- I have searched the existing issues
Is your issue described in the documentation?
- I have read the documentation
Is your issue present in the latest beta/pre-release?
None
Describe the Bug
Streaming to a Samsung Galaxy Tab S9 FE+ (Moonlight Android, HEVC, 2560x1600) shows a short hitch/stutter every ~2 seconds. Once host-side problems were fixed (below), the Moonlight stats overlay is clean everywhere except one line: the client renders ~0.49 fewer frames per second than it receives.
Typical overlay (Moonlight 60 FPS / Balanced / 100 Mbps, game capped at 30 FPS with vsync):
Video stream: 2560x1600 30.00 FPS
Decoder: c2.exynos.hevc.decoder
Incoming frame rate from network: 30.00 FPS
Rendering frame rate: 29.51 FPS
Frames dropped by your network connection: 0.00%
Average network latency: 2 ms (variance: 0 ms)
Host processing latency min/max/average: 5.1/7.6/6.1 ms
Average decoding time: 11.08 ms
The "incoming minus rendering" gap is ~0.49 FPS in every configuration I tried:
| Config | Incoming | Rendering | Gap |
|---|---|---|---|
| Stream 60 FPS, Balanced, game ~24-29 FPS | 29.36 / 23.90 | 28.87 / 23.41 | 0.49 / 0.49 |
| Stream 30 FPS, Smoothest video, 30 Hz host display | 30.02 | 29.54 | 0.48 |
| Stream 60 FPS, Balanced, 60 Hz host display | 30.00 | 29.51 | 0.49 |
That's about one dropped frame every ~2 s, which matches how often the hitch is visible. The gap stays the same at different content frame rates (24 vs 30 FPS), so it looks like a fixed-period event rather than a clock-rate mismatch.
Things that did NOT fix it:
- Tablet Motion smoothness Adaptive (90 Hz) vs Standard (60 Hz)
- Frame pacing: Balanced, Smoothest video, Lowest latency
- Stream 30 vs 60 FPS; host virtual display 30 vs 60 Hz
- Apollo 0.4.6 + Artemis 20.2.6 instead of Sunshine + Moonlight (same symptom)
- 50 Hz ping from host to tablet while idle: median 2 ms, no periodic spikes
Host-side problems I found and fixed along the way (in case they're relevant):
- With HAGS on, realtime NVENC priority + VRAM ~90% gave
NvEnc: frame N encode wait timeoutfreezes (matches #1031). Settingnvenc_realtime_hags = disabledstopped those, but then the stream fell to ~20 FPS with 75-100 ms host latency whenever the game pinned the GPU at 100%. Turning HAGS off in Windows (Sunshine back to realtime priority) fixed it: 30 FPS, ~6 ms host latency. - The host Ethernet links at only 100 Mbps, so a 100 Mbps bitrate at a 30 FPS stream saturated it. Now kept at ~55 Mbps on the wire (60 FPS stream, 30 FPS content).
Main question: is this ~2 s periodic client-side drop a known issue with Exynos decoders / Samsung tablets, or is there a host-side setting (frame pacing, minimum_fps_target, packet pacing) that would avoid it? If it belongs in moonlight-android instead, please say so and I'll move it.
Expected Behavior
Rendering frame rate equals incoming frame rate (30.00 / 30.00), with no periodic hitches, given 0% network loss and stable host latency.
Additional Context
- Client: Samsung Galaxy Tab S9 FE+ (Exynos 1380, 12.4" 2560x1600 90 Hz LCD), Moonlight Android (latest from Play Store), 5 GHz Wi-Fi (channel 149), decoder
c2.exynos.hevc.decoder - Host is a hybrid laptop: internal panel on Intel iGPU, HDMI and the virtual display on NVIDIA
- Virtual display: MikeTheTech Virtual Display Driver 25.7.23, pinned to the RTX 4050, 2560x1600 @ 30/60/90/120 Hz
- Game: Crimson Desert, capped at 30 FPS (NVIDIA app Max Frame Rate) with vsync on; GPU ~85%
- Controller: DualSense over Bluetooth on the host
Host Operating System
Windows
Operating System Version
Windows 11 Home 10.0.26200
Architecture
amd64/x86_64
Sunshine commit or version
2026.914.233613 (commit 63d35f702ee9e362e43263742981836ec0710384)
Package
Windows - installer (recommended)
GPU Type
NVIDIA
GPU Model
NVIDIA GeForce RTX 4050 Laptop GPU (6 GB) + Intel UHD Graphics (i5-13420H), HP Victus 15-fa1xxx
GPU Driver/Mesa Version
32.0.16.1742 (617.42)
Capture Method
Desktop Duplication API (default)
Config
adapter_name = NVIDIA GeForce RTX 4050 Laptop GPU
output_name = {9acddf6d-43cc-576e-9aff-0c5fc80b4cc8}
dd_configuration_option = ensure_only_display
dd_resolution_option = auto
dd_refresh_rate_option = auto
dd_hdr_option = auto
encoder = nvenc
nvenc_preset = 1
nvenc_twopass = quarter_res
nvenc_realtime_hags = disabled
(HAGS is now off in Windows, so Sunshine logs "Using realtime GPU priority".)
Apps
Desktop; Crimson Desert via steam://rungameid/3321460 (detached)
Relevant log output
[2026-10-19 00:25:20.520]: Info: Active GPU has HAGS disabled
[2026-10-19 00:25:20.520]: Info: Using realtime GPU priority
[2026-10-19 00:28:34.674]: Info: Display refresh rate [60Hz]
[2026-10-19 00:28:34.674]: Info: Requested frame rate [60/1 exactly 60 fps]
[2026-10-19 00:28:55.450]: Error: NvEnc: frame 1113 encode wait timeout <- only during game load
[2026-10-19 00:30:27.213]: Error: NvEnc: frame 4012 encode wait timeout <- none after this; stutter continued
[2026-10-19 00:35:30.579]: Info: CLIENT DISCONNECTED
Full log attached: sunshine.log
Expected Behavior
No response
Additional Context
No response
Host Operating System
Windows
Operating System Version
Windows 11 OS Build 26200.9711
Architecture
amd64/x86_64
Package
Windows - exe installer
GPU Type
NVIDIA
GPU Model
RTX 4050 MOBILE GPU
GPU Driver/Mesa Version
32.0.16.1742 (617.42)
Capture Method
Desktop Duplication API (Windows)
Apps
Log output
please see the attached log file for the full logs
Online logs
No response
- Ngôn ngữ chính
- C++
- Star
- 43k
- Fork
- 2.4k
- Merge trung bình
- 1 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 105
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của LizardByte/Sunshine
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
LizardByte/Sunshine#6051 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
PIN pairing fails with "Missing CSRF token" - web UI never fetches/attaches the tokenCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
LizardByte/Sunshine#5467 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 18/100
LizardByte/Sunshine#6072 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
LizardByte/Sunshine#6063 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
LizardByte/Sunshine#6048 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của LizardByte/Sunshine
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
pocoproject/poco#5664 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
charmplusplus/charm#4210 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
cp-algorithms/cp-algorithms#1748 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày