Seems to give my Pi5 Bookworm setup a segfault as soon as it connects with lots of:

I don't see Pyrowave on my host PC's Steam so I don't think i'm using that.

Originally posted by QQ Bee:

Seems to give my Pi5 Bookworm setup a segfault as soon as it connects with lots of:

avcodec_send_packet() returned -1094995529 ffmpeg error: get_buffer() failed ffmpeg error: decode_slice_header error ffmpeg error: get_buffer() failed ffmpeg error: decode_slice_header error ffmpeg error: get_buffer() failed ffmpeg error: decode_slice_header error ffmpeg error: get_buffer() failed ffmpeg error: decode_slice_header error ffmpeg error: no frame! avcodec_send_packet() returned -1094995529 Segmentation fault (core dumped)

This is fixed for the next update, thanks!

i am running up to date trixie on a pi 4 and always get a segmentation fault as soon as the stream starts, but no real other errors that i can see. the last version worked.
is there a way to downgrade that doesnt involve blocking some steam servers and jumping through a lot of hoops?

On raspberry pi 3 (Trixie 13.2), it is the same. After update today, in steam and menus of Witcher 3 is ok, but just as I load the savegame it crushes after 1-2 seconds with segmentation fault. Before update there was no problems.

After playing with some settings, hardware decoding in remote play settings is a cause of problem. Unfortunately, without that there are terrible artifacts and problem with network even though I am using wired connection.

I'm also getting the same problem and also found that turning off hardware decoding prevented the crashes.

Below is what Claude wanted me to share about my setup

---

Steam Link 1.4.2.321 on Raspberry Pi 3 Model B — segfault on stream start
with hardware decoding enabled

Setup:
- Raspberry Pi 3 Model B
- Raspberry Pi OS Lite 64-bit (Trixie), console environment, no desktop
- Steam Link 1.4.2.321 (beta channel)
- Wired 100Mbit Ethernet, network test shows ~90 Mbps
- Host: Windows PC, hardware encoding enabled, NVFBC off

Symptom:
Steam Link launches and connects fine. On selecting a host, I see the host
UI for roughly a second, then the app exits to the console. Exit code is
139 (SIGSEGV).

Isolation:
Setting Hardware Decoding to Disabled stops the crash completely. Streaming
is unusably slow at that point, as expected, but it is stable and survives
reboots. Turning Hardware Decoding back on reproduces the crash every time.
This is the only variable that changes the outcome.

Already ruled out:
- vcgencmd get_throttled returns 0x0 (no undervoltage, no throttling, none
since boot)
- gpu_mem raised from 76M to 128M, no change
- HEVC, AV1 and PyroWave all show "Not available" on the client, so this is
H.264 only
- Resolution Limit 1280x720, Framerate Limit 60 FPS (both set explicitly,
not automatic)
- Crashes in both Big Picture and Desktop launch modes — Desktop crashes
sooner
- dmesg shows no OOM kill, no CMA allocation failure, nothing after the
controller connecting
- Deleted ~/.local/share/SteamLink and let it redownload; .version and
version.txt match
- Low Latency Networking toggled both ways, no change
- Removed a video=HDMI-A-1:margin_* kernel parameter I had set for overscan,
no change

Log detail:
The decoder initializes normally and reports:

mpeg info: Using device /dev/video10
mpeg info: driver 'bcm2835-codec' on card 'bcm2835-codec-decode'
mpeg info: requesting formats: output=H264/none capture=YU12/none
Raspberry Pi hardware decoding on console
mpeg verbose: Decode running

The log then ends at k_EStreamControlSetCursorImage with no error message.

One thing that may be relevant: shortly before the crash, the video rect
oscillates repeatedly between two geometries:

video rect: 1920x1080 at 0,0
video rect: 1920x1000 at 0,0
video rect: 1920x1080 at 0,0

Possible connection to recent builds:
1.4.0.318 changed automatic display resolution matching, and 1.4.1.320 fixed
an H.264 streaming crash introduced in the previous build. Given that this is
an H.264 hardware decode crash with unusual display geometry behavior
immediately preceding it, I wonder whether the Pi 3 hits a related path that
the 1.4.1.320 fix did not cover.

Happy to supply full logs or test a build.

I also get the crash with this version, usually within one second.

raspberry pi 3B +, debian 13, no desktop environment.

Downgrading to steamlink-rpi-trixie-arm64-1.3.32.316 and it works like a charm.

Originally posted by Khoernchen:

is there a way to downgrade that doesnt involve blocking some steam servers and jumping through a lot of hoops?

Yes, wiith this guide : https://steamcommunity.com/app/353380/discussions/6/2791622420174747105/

This is fixed in the latest beta!