Steam Link

Steam Link

k_ECaptureFailedReasonUnknown sent 30 sec after session start
After updating to the Steam Link app beta (for the --autoconnect flag), I noticed that while just sitting in the Big Picture UI, after about 30 seconds, I would get a "Video capture failed" error with seemingly no adverse effect on the connection. I can close out of the message and continue my session. Checking the streaming log shows a
k_ECaptureFailedReasonUnknown
error with seemingly nothing relevant around it. While looking for any other relevant logs, I noticed that console_log.txt was getting filled with
src/steamUI/gamestream/desktopcapturepipewire.cpp (1191) : spaBuffer->n_datas == 1
messages until the streaming was stopped. Is there a log file that has more info that I'm missing?

For context, I'm running:
  • Ubuntu 25.10 with KDE under Wayland
  • Steam Beta 1778548034 with the -pipewire flag
  • Steam Link for Raspberry Pi Beta 1.3.27.305, though the error control code gets transmitted regardless of what Steam Link device I use

EDIT: got a bit overzealous with code block formatting
Originally posted by Packetdancer:
Yeah, when it's a game that the overlay is able to grab control of the output surface for, we can switch from the desktop capture (which requires Pipewire on Wayland) to a game-specific capture, just encoding and sending the game's output surface.

So that doesn't surprise me. I don't like the dmabuf/mmap issue if you were running with -pipewire and not -pipewire-dmabuf -- demonstrably it works in the fallback, but it shouldn't *keep* trying the dmabuf method -- but that's a different thing entirely.

Anyway, I've changed the logic slightly and I *think* that should roll into the next Steam client beta, so the erroneous capture failure message should go away -- it should only happen if Pipewire is *truly* unable to capture something now. Though since I couldn't reproduce your issue here, let me know if it *doesn't* fix it for you when the next beta lands.
< >
Showing 1-7 of 7 comments
Wow, that assert message is awfully misleading, since it will be flagged if that state _isn't_ the case -- basically, if Pipewire is capturing more than one image plane.

That said, if it's still *working* despite that, I'll change the Pipewire failure check to not consider that situation a potential capture failure for the next beta. I would *definitely* be curious what your setup is to cause Pipewire to capture multiple image planes, though. Any weird overlays or such? (If I can repro the scenario, I'd like to add it to the stuff that we test.)
Not that I'm aware of. Your comment about multiple image planes made me recheck if the issue could have been my multi-monitor setup, but selecting one monitor instead of the full workspace not only did not resolve the issue, but also caused the streaming log to get flooded with
[2026-05-13 22:13:23][34.761687] CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented [2026-05-13 22:13:23][34.761722] CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted [2026-05-13 22:13:23][34.761736] CDesktopCapturePipeWire: Couldn't get image data
Here's something interesting: if I quickly launch a game after starting a session, the error never shows up. I assume it has something to do with this output in the streaming log:
[2026-05-13 22:43:35][233.338286] >>> Stopped desktop stream [2026-05-13 22:43:35][233.338335] Video capture state changed [2026-05-13 22:43:35][233.395648] >>> Switching video stream from Desktop_MovieStream to GameOverlay_MovieStream_202485 [2026-05-13 22:43:35][233.413524] >>> Capture method set to Game Vulkan NV12 + VAAPI HEVC
Exiting the game and waiting in Big Picture brings up the error after about 30 seconds.
The author of this thread has indicated that this post answers the original topic.
Yeah, when it's a game that the overlay is able to grab control of the output surface for, we can switch from the desktop capture (which requires Pipewire on Wayland) to a game-specific capture, just encoding and sending the game's output surface.

So that doesn't surprise me. I don't like the dmabuf/mmap issue if you were running with -pipewire and not -pipewire-dmabuf -- demonstrably it works in the fallback, but it shouldn't *keep* trying the dmabuf method -- but that's a different thing entirely.

Anyway, I've changed the logic slightly and I *think* that should roll into the next Steam client beta, so the erroneous capture failure message should go away -- it should only happen if Pipewire is *truly* unable to capture something now. Though since I couldn't reproduce your issue here, let me know if it *doesn't* fix it for you when the next beta lands.
Just wanted to report I was seeing the same thing. Looks like I'll need to switch to the beta version of Steam?

I'm only using a single monitor for my setup.

Bazzite 44.20260515 with KDE Wayland
Steam Version: 1778281814 with -pipewire flag
Steam Link for iPhone: 1.3.28.306


[2026-05-19 20:51:25][433.760075] CDesktopCapturePipeWire: PipeWire stream state changed to streaming [2026-05-19 20:51:25][433.792958] CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented [2026-05-19 20:51:25][433.792979] CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted [2026-05-19 20:51:25][433.792987] CDesktopCapturePipeWire: Couldn't get image data [2026-05-19 20:51:25][433.822182] CDesktopCapturePipeWire: PipeWire stream state changed to paused [2026-05-19 20:51:26][434.310684] CDesktopCapturePipeWire: PipeWire stream format changed (size: 1920x1080, format 8, stride 7680, size 8294400, dmabuf: 1) [2026-05-19 20:51:55][463.654891] Unable to capture video: k_ECaptureFailedReasonUnknown [\code]
Originally posted by Enlinks:
Just wanted to report I was seeing the same thing. Looks like I'll need to switch to the beta version of Steam?

Yes, please try the beta version of Steam and let us know if you are still seeing the issue.

Thanks!
Look like it’s working now!

Steam Beta Version: 1779479049

Thank you!
< >
Showing 1-7 of 7 comments
Per page: 1530 50