Your system information

• Steam client version (build number or date): stable 1782861641, and beta (steamdeck_publicbeta) 1784588115 — bug reproduces on both channels (see differential-diagnosis table)
• Distribution: SteamOS (Steam Deck-style RAUC image), host device
• Opted into Steam client beta?: Tested both ways — see channel column in the table below
• Have you checked for system updates?: Yes — host tested on both SteamOS 3.8.24 (build 20260716.2, kernel 6.16.12-drmexec7-valve24.5) and the pre-OTA SteamOS 3.8.22 (build 20260703.2, kernel 6.16.12-drmexec7-valve24.3) via the inactive RAUC slot, specifically to rule out an OS regression
• GPU: AMD (RX 9070 XT / RDNA4, host); client GPU is the streaming target, not decode-relevant for this bug
• Streaming role: host (streaming source). Client device: SteamOS, same current build, on a TV, wired to the host over a 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: During a Remote Play session, the host's outbound stream bitrate should track the negotiated/target encode rate continuously while gameplay is active and the host GPU has headroom.

Actual: Intermittently, the host's outbound stream throughput (mirrored almost exactly by the client's inbound throughput — confirms the drop is host-side, not a client-side receive problem) collapses from a healthy ~150-215 Mbit/s baseline down to ~19-40 Mbit/s for 2-10 seconds, then recovers on its own once an input event (controller/mouse) is sent. During the collapse:

• The host GPU stays busy (66-100% in our samples) — it is still encoding, just not producing/sending full-rate output.
• The client's video decode engine (VCN) stays non-zero (~28-40% busy in our samples) throughout — the client is still decoding something, just thin/stale data. This is the key discriminator from the sibling bug we're filing separately (#TODO-cross-link: client-side decoder-stall issue, VCN busy hits exactly 0%) — that one shows the opposite network/decode split.
• NIC error and drop counters on both host and client stay at 0 for the entire session, including through every stall — this is not a link-layer/cable/driver-drop problem.
• The stall self-resolves on the next input event; no reconnect or session drop occurs.

We isolated this with a same-day, three-round, predeclared A/B experiment specifically to separate "is this an OS/driver regression" from "is this the Remote Play/streaming stack" — see the differential-diagnosis table below. Short version: we ruled out the SteamOS 3.8.24 OTA (kernel, Mesa, gamescope) entirely by reproducing the same stall pattern at the same rate on the host's pre-OTA image (3.8.22). The bug lives in something both images share — most likely the Steam client's Remote Play/encoder stack.

Steps for reproducing this issue

1. Host: start a Steam Remote Play session streaming a demanding 3D game (we used Horizon Forbidden West) to a client device on the same local network.
2. Play normally for 30-90 minutes. Have both host and client sample outbound/inbound network throughput and host GPU busy % at ≥1 Hz (we used a companion shell monitor plus our own telemetry agent, see "Evidence" below).
3. Watch for outbound throughput on the host dropping below ~40 Mbit/s for several seconds while host GPU busy stays ≥60% and NIC error/drop counters remain 0. In our sessions this recurred roughly every 8-20 minutes of active gameplay, in some cases clustering several events within a few minutes after a long quiet stretch (possibly scene/area-dependent — not confirmed).
4. Confirm recovery: sending any controller/mouse input during or shortly after the stall restores full throughput without a reconnect.

Frequency

Across three rounds totaling ~2h15m of monitored gameplay this session (plus a longer ~2h baseline the day before): 11 confirmed present-stall episodes (5 baseline + 4 + 0 + 2), rate varying by configuration (see table) — never zero except in one 60-minute round (see round 2 below), and not eliminated by any of the OS/channel combinations we tested.

Differential diagnosis — what we ruled out and how

Predeclared stopping rule for the OS test (round 1): 2 freeze-candidates on the pre-OTA image → OS image stack exonerated, stop early (we continued to 4 for extra confidence). 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 present-stall — this is not packet loss or a NIC/driver fault.

Conclusion: the bug is not in the SteamOS image (kernel, Mesa, gamescope all cleared by the OS A/B). It reproduces on both Steam client channels. The remaining shared surface between the tested configurations is the Steam client's Remote Play/streaming-encoder stack itself (and, more weakly, the specific game's interaction with the capture path — not excluded, but the signature was consistent across Horizon Forbidden West at multiple points and matches an independently-observed decoder-adjacent bug we're filing separately, suggesting a shared streaming-stack root cause rather than a per-game issue).

Note on host-channel effect (moderate confidence only): round 2's 60 minutes on host-stable were completely clean, versus a present-stall every ~8-20 min on host-beta in the baseline and round 1. But round 3 produced 2 episodes in 43 minutes on the same stable host, so the rate is variable (possibly scene/area-dependent) — we are not claiming "stable fixes it," only noting stable appeared to reduce the rate in this limited sample.

Evidence

We captured this with our own open-source Remote Play/telemetry monitoring agent (RigSignal) running at 1 Hz on both boxes for full session durations, cross-checked against an independent companion shell-script monitor (also 1 Hz, sampling network throughput and host GPU busy independently) — the two measurement paths agreed within normal sub-second sampling jitter (e.g. one cross-checked timestamp: 181.8 Mbit/s from our agent vs. 168.0 Mbit/s from the independent monitor, same second).

present-stall-exemplar.png

— event r3-12, 2026-07-21T11:14:02Z UTC, host TX/client RX visibly diving from ~180 Mbit/s to ~20-25 Mbit/s for ~7s while client video-decode busy % stays in the high-20s/low-30s the whole time, then both recover fully within ~5-6s of the dip ending. Caption note: the plotted CSV window is ±60s around the event; a second, unrelated drop appears in the tail of that window (offset ≈ +43s onward, network throughput trailing toward 0 and our video-busy field going empty for the last ~10 samples). That tail segment is a known collector/capture-boundary gap at the very end of our sampling window (documented in our evidence-pack README), not a second present-stall — please disregard anything past roughly offset +20s in the plot when evaluating this specific event. The reported episode is only the single dip centered at offset 0.

• Raw per-event CSVs (±60s @ 1Hz, timestamp / video-busy% / host-TX-Mbit/s / client-RX-Mbit/s): event-r3-11-present-stall-*.csv (a clean double-dip episode, 13:01:23 + 13:01:27 local, no capture gaps) and event-r3-12-present-stall-*.csv (single dip, see caption above for the tail artifact).
• Full OS A/B methodology, predeclared design, and raw 1 Hz ground-truth logs: ../AB-VERDICT.md (verdict doc) and the accompanying gamingpc-254-slotA-run.log / streamclient-162-slotA-run.log files.
• 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 4 individual present-stall events from the round-1 (pre-OTA image) run, with the same CSV format, if useful for cross-referencing against the OS A/B specifically.
• 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. Nothing matches this signature (network-telemetry-confirmed host-side bitrate collapse with GPU still busy, input-recoverable, reproduced across an OS A/B). Closest related-but-different reports: #11877 (single-game freeze at connection time, not a mid-session recoverable stall), #8424 and #9498 (general stutter reports without throughput/GPU telemetry to discriminate root cause), #5831 (2018-era, tied to window focus, not throughput collapse). 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 #13426 (client-side video decoder stall — VCN busy hits exactly 0% while the network stays fully healthy and audio keeps playing). They are almost certainly different bugs (opposite network/decode signature) but came out of the same test session, so cross-referencing here in case they share a root cause deeper in the streaming stack.