Steam client version (build number or date): stable 1782861641, and beta (steamdeck_publicbeta) 1784588115 — bug reproduces on both channels (see differential-diagnosis table)
Opted into Steam client beta?: Tested both ways — see channel column in the table below
Have you checked for system updates?: Yes — client tested on current SteamOS 3.8.24 (build 20260716.2)
GPU: AMD, client device (VCN hardware video-decode engine is the component this bug is isolated to)
Streaming role: client (receiving/decoding). Host device: SteamOS 3.8.24, AMD RX 9070 XT / RDNA4, same local network (not internet-relayed)
Game: Horizon Forbidden West (Steam), Remote Play (not Remote Play Together)
Please describe your issue in as much detail as possible
Expected: While the network stream is healthy and audio is playing normally, the video should decode and display continuously.
Actual: Intermittently, the picture freezes (shows a static/stale frame, sometimes accompanied by the client's "bad signal"-style overlay) for 2-13 seconds, then recovers on its own once an input event (controller/mouse) is sent — no reconnect occurs. We instrumented both the host and client with our own telemetry agent and found the precise signature:
The client's hardware video-decode engine (VCN) busy percentage drops to exactly 0% for the duration of the freeze — it is not "decoding slowly," it stops entirely.
Audio continues uninterrupted the entire time — audio latency stays flat (~10.67 ms in our exemplar) with no underruns/xruns recorded, confirming the audio decode path is unaffected and this is isolated to video.
The network path stays fully healthy throughout: host outbound throughput and client inbound throughput both remain in the normal ~155-215 Mbit/s streaming range for the entire freeze — there is no bitrate collapse, no packet loss (NIC error/drop counters stay 0 on both boxes). This is the opposite network signature from the sibling bug we're filing separately (#TODO-cross-link: host-side present-stall, where throughput does collapse but the client keeps decoding non-zero data) — these are two different failure modes that happen to both be input-recoverable.
Critically, host-side telemetry cannot see this bug at all — host GPU/graphics-engine busy % stays normal throughout every decoder-stall event we captured. The only signal that discriminates it is the client's own VCN engine counter. A monitoring approach that only looks at the host (which is the common case, since the host is usually the "server") will completely miss this failure class.
We isolated this signature as part of the same three-round A/B investigation used for the sibling present-stall issue; see the differential table below for what we ruled out.
Steps for reproducing this issue
Client: connect to a Steam Remote Play session streaming a demanding 3D game from a host on the same local network (we used Horizon Forbidden West).
Play normally for 30-90 minutes. Sample host outbound / client inbound network throughput, plus the client's video-decode-engine busy % if you have access to a VCN/UVD utilization counter (we used our own telemetry agent for this — see "Evidence" below; standard OS-level GPU tools that report only the graphics/compute engine will not show this, you need the video engine specifically).
Watch for the client's video-decode busy % dropping to exactly 0% for ≥2 seconds while host TX / client RX both stay in their normal healthy range and audio keeps playing without interruption.
Confirm recovery: sending any controller/mouse input during or shortly after the stall restores decoding without a reconnect.
Frequency
This was the more frequent of the two freeze classes we found: 10 confirmed decoder-stall episodes across two rounds totaling ~103 minutes of monitored gameplay — 8 events in a 60-minute round (2 lasting 13s, 6 shorter "micro" stalls of ~2-6s) and 2 more in a 43-minute round (4s, 2s), plus one borderline host-side sag noted separately. Durations ranged 2-13 seconds.
Differential diagnosis — what we ruled out and how
Round
Host Steam channel
Client Steam channel
Gameplay duration
Decoder-stall count
Notes
2
stable (1782861641)
beta (1784588115)
60 min
8 (2×13s + 6 micro, 2-6s)
Highest event density observed — used as the primary evidence set below
3
stable
stable
~43 min
2 (4s, 2s) + 1 borderline host-side sag
Confirms this is not beta-client-exclusive — reproduces on stable/stable too
We did not run a dedicated OS-image A/B for this specific bug (that A/B targeted the host present-stall class, which has a network-layer signature the pre-OTA image could be tested against). However, since both rounds above ran on the same current SteamOS 3.8.24 image on both boxes and the bug is clearly video-decode-engine-local (VCN busy literally hitting 0 with a fully healthy network path around it), we consider a network/OS/kernel root cause already weak for this class — the fault surface is the decode pipeline between the received stream data and the VCN hardware queue, most plausibly in the client-side Steam streaming/decode client itself. NIC error/drop counters were logged at 1 Hz on both boxes for the full duration of every round and stayed at 0/0/0/0 throughout, including through every decoder-stall — ruling out packet loss as a cause.
Conclusion: the video decode path stalls independently of a healthy network and independently of audio decode, and reproduces on both Steam client channels. Because host-side GPU/graphics-engine telemetry sees nothing wrong during these events, we believe this has likely been under-reported or misattributed to network issues in existing bug reports (see "Related" below) — it requires client-side video-engine-specific telemetry to distinguish from a network stall, which most users and most built-in diagnostics don't have visibility into.
Evidence
Captured with our own open-source Remote Play/telemetry monitoring agent (RigSignal) running at 1 Hz on the client for full session duration, sampling the client's video-decode-engine busy percentage — a metric not exposed by standard box-level GPU monitoring (which typically reports only the graphics/compute engine and does not see this failure). Network throughput and host GPU busy were cross-checked against an independent companion shell-script monitor and agreed within normal sub-second sampling jitter.
decoder-stall-exemplar.png
— event r2-01, 2026-07-21T09:23:48Z UTC, a clean 13-second stall: client video-busy % drops from ~70% to exactly 0.0% for the full 13 seconds while host TX and client RX both stay in the 150-210 Mbit/s range the entire time (fully healthy, no coverage gaps in this event's data), then video-busy jumps back to ~29% and recovers to normal within 1-2 more seconds after an input event.
Raw per-event CSVs (±60s @ 1Hz, timestamp / video-busy% / host-TX-Mbit/s / client-RX-Mbit/s), full coverage (121/121 points) for all of these: event-r2-01 through event-r2-08 (Round 2, the primary evidence set) and event-r3-09, event-r3-10 (Round 3, corroborating stable/stable).
Audio corroboration: rigsignal.audio.latency_ms on the client was queried for the exemplar window and stayed flat at 10.67 ms with zero xruns through the entire video-busy-0% stretch — not included as a CSV column in the attached files (out of scope for the two headline metrics) but available on request from the same source data.
Full 3-round matrix and combined conclusions: ../EXPERIMENT-MATRIX.md.
No IP addresses, credentials, or private URLs appear in any of the evidence files; host identifiers are limited to generic role names (gamingpc, streamclient).
What we can provide on request
The client-side rigsignal.audio.latency_ms series for any of the 12 events, to independently corroborate "audio continues" beyond the one exemplar cited above.
Longer continuous 1 Hz ground-truth logs (network + host GPU busy) spanning entire sessions, not just ±60s windows around flagged events.
Steam client logs from either box on request (not attached by default — happy to generate via the standard tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs if that would help triage).
Related (searched, not duplicates)
We searched open and closed issues before filing and found nothing describing this specific signature (video-decode-engine busy hitting exactly 0% with a simultaneously healthy network and continuing audio, isolated via telemetry rather than user perception). Closest related-but-different reports: #11877 (a single game freezing at connection time, not a mid-session recoverable video-only stall), #9498 and #8424 (general Remote Play stutter reports without decode-engine telemetry to confirm this is the same failure mode), #8929 (different hardware-decode-method issue, Desktop vs Game Mode, not a mid-session stall). Happy to be pointed at a better match if a maintainer knows of one.
Sibling issue
This is one of two distinct freeze classes we isolated in the same investigation; see companion issue #13425 (host-side present-stall — outbound throughput collapses to ~20-40 Mbit/s while the client keeps decoding non-zero video data, opposite signature from this bug, also OS-A/B-exonerated). They are almost certainly different bugs but came out of the same test session, so cross-referencing here in case they share a root cause deeper in the streaming stack.
Your system information
1782861641, and beta (steamdeck_publicbeta)1784588115— bug reproduces on both channels (see differential-diagnosis table)20260716.2)Please describe your issue in as much detail as possible
Expected: While the network stream is healthy and audio is playing normally, the video should decode and display continuously.
Actual: Intermittently, the picture freezes (shows a static/stale frame, sometimes accompanied by the client's "bad signal"-style overlay) for 2-13 seconds, then recovers on its own once an input event (controller/mouse) is sent — no reconnect occurs. We instrumented both the host and client with our own telemetry agent and found the precise signature:
We isolated this signature as part of the same three-round A/B investigation used for the sibling present-stall issue; see the differential table below for what we ruled out.
Steps for reproducing this issue
Frequency
This was the more frequent of the two freeze classes we found: 10 confirmed decoder-stall episodes across two rounds totaling ~103 minutes of monitored gameplay — 8 events in a 60-minute round (2 lasting 13s, 6 shorter "micro" stalls of ~2-6s) and 2 more in a 43-minute round (4s, 2s), plus one borderline host-side sag noted separately. Durations ranged 2-13 seconds.
Differential diagnosis — what we ruled out and how
1782861641)1784588115)We did not run a dedicated OS-image A/B for this specific bug (that A/B targeted the host present-stall class, which has a network-layer signature the pre-OTA image could be tested against). However, since both rounds above ran on the same current SteamOS 3.8.24 image on both boxes and the bug is clearly video-decode-engine-local (VCN busy literally hitting 0 with a fully healthy network path around it), we consider a network/OS/kernel root cause already weak for this class — the fault surface is the decode pipeline between the received stream data and the VCN hardware queue, most plausibly in the client-side Steam streaming/decode client itself. NIC error/drop counters were logged at 1 Hz on both boxes for the full duration of every round and stayed at 0/0/0/0 throughout, including through every decoder-stall — ruling out packet loss as a cause.
Conclusion: the video decode path stalls independently of a healthy network and independently of audio decode, and reproduces on both Steam client channels. Because host-side GPU/graphics-engine telemetry sees nothing wrong during these events, we believe this has likely been under-reported or misattributed to network issues in existing bug reports (see "Related" below) — it requires client-side video-engine-specific telemetry to distinguish from a network stall, which most users and most built-in diagnostics don't have visibility into.
Evidence
Captured with our own open-source Remote Play/telemetry monitoring agent (RigSignal) running at 1 Hz on the client for full session duration, sampling the client's video-decode-engine busy percentage — a metric not exposed by standard box-level GPU monitoring (which typically reports only the graphics/compute engine and does not see this failure). Network throughput and host GPU busy were cross-checked against an independent companion shell-script monitor and agreed within normal sub-second sampling jitter.
decoder-stall-exemplar.png— event
r2-01, 2026-07-21T09:23:48Z UTC, a clean 13-second stall: client video-busy % drops from ~70% to exactly 0.0% for the full 13 seconds while host TX and client RX both stay in the 150-210 Mbit/s range the entire time (fully healthy, no coverage gaps in this event's data), then video-busy jumps back to ~29% and recovers to normal within 1-2 more seconds after an input event.event-r2-01throughevent-r2-08(Round 2, the primary evidence set) andevent-r3-09,event-r3-10(Round 3, corroborating stable/stable).rigsignal.audio.latency_mson the client was queried for the exemplar window and stayed flat at 10.67 ms with zero xruns through the entire video-busy-0% stretch — not included as a CSV column in the attached files (out of scope for the two headline metrics) but available on request from the same source data.../EXPERIMENT-MATRIX.md.No IP addresses, credentials, or private URLs appear in any of the evidence files; host identifiers are limited to generic role names (
gamingpc,streamclient).What we can provide on request
rigsignal.audio.latency_msseries for any of the 12 events, to independently corroborate "audio continues" beyond the one exemplar cited above.tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logsif that would help triage).Related (searched, not duplicates)
We searched open and closed issues before filing and found nothing describing this specific signature (video-decode-engine busy hitting exactly 0% with a simultaneously healthy network and continuing audio, isolated via telemetry rather than user perception). Closest related-but-different reports: #11877 (a single game freezing at connection time, not a mid-session recoverable video-only stall), #9498 and #8424 (general Remote Play stutter reports without decode-engine telemetry to confirm this is the same failure mode), #8929 (different hardware-decode-method issue, Desktop vs Game Mode, not a mid-session stall). Happy to be pointed at a better match if a maintainer knows of one.
Sibling issue
This is one of two distinct freeze classes we isolated in the same investigation; see companion issue #13425 (host-side present-stall — outbound throughput collapses to ~20-40 Mbit/s while the client keeps decoding non-zero video data, opposite signature from this bug, also OS-A/B-exonerated). They are almost certainly different bugs but came out of the same test session, so cross-referencing here in case they share a root cause deeper in the streaming stack.