Hello, I have been having issues with remote play for a while, unfortunately it seems to not be solvable for me at the moment;

Steam Remote Play host hangs after first stream on KDE Plasma 6.6 Wayland (PipeWire/ScreenCast session not released)

Your system information

• Host OS: Bazzite Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
  Digest: sha256:b923f92d5a5b59eb992e269383eba2744601052da9d3d1595f76e79aa6ce2df0
  Version: 44.20260608 (2026-06-08T19:16:10Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
  Digest: sha256:b923f92d5a5b59eb992e269383eba2744601052da9d3d1595f76e79aa6ce2df0
  Version: 44.20260608 (2026-06-08T19:16:10Z)

• Host desktop: KDE Plasma 6.6.5, Wayland session (XDG_SESSION_TYPE=wayland); no X11 session available on this image

• Host GPU: AMD Radeon RX 6750 XT (RDNA2 / Navi 22), Mesa VAAPI

• Host CPU: AMD Ryzen 9 5950X (no iGPU)

• **Steam (host):Steam Beta Branch: Steam Beta Update
  Steam Version: 1782257239
  Steam Client Build Date: Wed, Jun 24, 2026 01:13 UTC -08:00
  Steam Web Build Date: Tue, Jun 23, 2026 21:29 UTC -08:00
  Steam API Version: SteamClient023

• Client: 6.16.12-valve24-1-neptune-616-gc748040e4712 OSbuild 20260620.1

• Streaming client version (from log): 1781911235 (below)

Please describe your issue in as much detail as possible

Acting as a Steam Remote Play host on Wayland (KDE Plasma 6.6.5), screen capture only works for a single stream session per Steam launch. The first stream after starting Steam works correctly. Once that session ends, every subsequent stream attempt causes the Steam client on the host to hang (become unresponsive), and the client (Steam Deck) cannot connect. The only recovery is to fully kill and relaunch Steam, after which exactly one stream works again before the issue repeats.

Diagnosis from streaming_log.txt:

• On Wayland, video capture requires the PipeWire / xdg-desktop-portal ScreenCast path. Without launching Steam with -pipewire, capture fails outright with Unable to capture video: k_ECaptureFailedReasonPipewireRequired.
• With -pipewire, the first capture succeeds, but the PipeWire / ScreenCast session is not released/torn down when the stream ends (note PipeWire: timed out waiting for metadata update to complete during deinitialization), so the second acquisition deadlocks the client.
• Audio and controller input continue to work on the failing attempts — only video capture is affected.

The June 10 Steam Beta changelog ("Improved Pipewire session logic on Linux. If persistent capture permissions are granted to Steam, there will only be an active Pipewire session when streaming or recording") appears intended to address this, but the fix cannot take effect because persistent capture permission cannot be granted to native Steam: it has no app_id, so it does not appear in KDE's Application Permissions page, and KDE's kde-authorized pre-authorization table only supports remote-desktop, not screencast.

Troubleshooting already performed (to save the developers time)

• Both host and client fully updated, on Steam Beta. Game Recording disabled on both.
• Host hardware vs software encoding: with hardware encoding on, Steam crashes and restarts on connect (AMD VAAPI); with software encoding, capture works once then hangs as described above.
• Launched with -pipewire and with -pipewire -pipewire-dmabuf — identical result (first stream works, subsequent attempts hang).
• Ran flatpak permission-set kde-authorized remote-desktop "" yes — this removed the portal "Share" prompt but did not fix the hang (the table covers input/remote-desktop, not screencast).
• Disabled screen locking, screen blanking, and session suspend on the host — no change.
• No X11 session available on Plasma 6.6 / this Bazzite image, so the portal cannot be bypassed.

Steps for reproducing this issue

1. Host: Bazzite, KDE Plasma 6.6.5, Wayland session, Steam Beta client.
2. Launch Steam with -pipewire (required for Wayland screen capture).
3. Approve the portal screen-share dialog (select monitor → Share).
4. From a Steam Deck (Steam Beta), connect via Remote Play and stream any game — works.
5. End the stream.
6. Without restarting Steam on the host, start a second stream from the Deck.

What happens

The host Steam client becomes unresponsive/hangs and the Steam Deck cannot connect (connection fails / black screen). Steam must be force-killed (pkill -9 steam) and relaunched to recover, after which exactly one more stream works before the failure recurs. (With host hardware encoding enabled, the failure instead presents as an immediate Steam crash-and-restart on connect.)

What should happen

When a stream ends, Steam Remote Play should release the PipeWire/ScreenCast capture session and cleanly re-acquire it for subsequent streams, allowing repeated connect/disconnect cycles without restarting Steam — ideally by holding a persistent capture permission as described in the June 10 Beta notes. A way to grant that persistent permission to native (non-Flatpak) Steam on KDE Wayland is also needed (it currently has no app_id and so cannot be authorized via KDE's Application Permissions or the kde-authorized screencast path).

Workaround

No working workaround within Steam Remote Play on this system (X11, which would bypass the portal, is unavailable on Plasma 6.6).

The reliable alternative is to stop using Steam Remote Play as the host and use Sunshine (host) + Moonlight (Steam Deck) instead. Sunshine installs as a Flatpak with a real app_id, so it can be granted a persistent capture permission via KDE's Application Permissions, and it captures through KWin Screencast / KMS rather than Steam's portal session — allowing unlimited repeated streams without hanging. It also uses the AMD VCN hardware encoder directly.

Relevant log excerpts (~/.local/share/Steam/logs/streaming_log.txt)

1. Capture/session setup on stream start (Wayland, PipeWire)

[2026-06-23 20:18:34][22.687330] GameScope focus changed to appID 0
[2026-06-23 20:18:34][22.687397] Window title set to Path of Exile 2
[2026-06-23 20:18:34][22.687467] PipeWire: Initializing streaming
[2026-06-23 20:18:34][22.693442] PipeWire: Loading null sink for streaming
[2026-06-23 20:18:34][22.693472] PipeWire: Setting default.configured.audio.sink to {"name":"steam-streaming-playback"}
[2026-06-23 20:18:34][22.693936] PipeWire: Detected stale default source, clearing (potentially lost default)
[2026-06-23 20:18:34][23.693601] PipeWire: timed out waiting for metadata update to complete
[2026-06-23 20:18:34][23.693601] Changing record window: 0x7800001 (125829121)
[2026-06-23 20:18:34][23.693615] SynchronizeClientState(): setting capture size 1920x1080
[2026-06-23 20:18:34][23.693677] SynchronizeClientState(): setting title to Path of Exile 2

2. Video capture failure (the core error)

[2026-06-23 20:18:51][40.078853] GameScope focus changed to appID 0
[2026-06-23 20:18:51][40.079099] Changing record window: 0x200000 (2097152)
[2026-06-23 20:19:05][53.721744] Unable to capture video: k_ECaptureFailedReasonPipewireRequired
[2026-06-23 20:19:05][53.721774] Steam needs to be restarted with -pipewire as a parameter in order to be able to capture video. Be certain to select any monitors you wish to share and click 'Share' in the dialog that appears when Steam starts.
[2026-06-23 20:19:05][53.772161] CLIENT: Got control packet k_EStreamControlCaptureFailed

3. Session teardown — PipeWire deinit times out (session not cleanly released)

[2026-06-23 20:19:22][71.014555] Encoding complete
[2026-06-23 20:19:22][71.033951] PulseAudio: Context connection terminated
[2026-06-23 20:19:22][71.038276] PipeWire: Unloading null sink
[2026-06-23 20:19:22][71.038322] PipeWire: Setting default.configured.audio.sink to (null)
[2026-06-23 20:19:22][72.038440] PipeWire: timed out waiting for metadata update to complete
[2026-06-23 20:19:22][72.038477] PipeWire: Deinitializing streaming
[2026-06-23 20:20:14] Client version: 1781911235
[2026-06-23 20:20:14][5.163911] Desktop state changed: desktop: { pos: 0, 0 size: 1920,1080 } primary: { pos: 0, 0 size: 1920,1080 }

Note: full streaming_log.txt available on request; the excerpts above are the relevant portions around capture init, the capture failure, and session teardown.

used AI to clean it up a bit.