Live TV: transcoding from the LiveStreamFiles relay produces ~1.5 'Packet corrupt'/s that no other reader of the same relay sees

Summary

When Jellyfin transcodes a Live TV stream from its own relay file (/LiveTv/LiveStreamFiles/…), ffmpeg logs ~1.5 Packet corrupt per second and visible decode artefacts. The same relay file read at the same moment by anything other than Jellyfin's transcoding ffmpeg — including a plain ffmpeg -c copy — is clean. So the corruption is introduced between the relay and Jellyfin's transcode consumer, not by the tuner, signal, or relay contents.

Environment

• Jellyfin 12.0.0 (lscr.io/linuxserver/jellyfin), TrueNAS SCALE, Ryzen 7 5825U / Vega 8 (VAAPI)
• HDHomeRun tuner, UK DVB-T2. Tuner reports signal 100%, quality ~77%, symbol quality 100 throughout.
• Channel: BBC ONE HD — H.264 1920x1080 interlaced (field_order=tt), ~15 Mbps.
• Client forces a transcode (bitrate cap below source), giving h264 (native) -> h264 (h264_vaapi) with bwdif deinterlace — i.e. the stock live-TV transcode command.

Reproduction / evidence

Four readers of the same channel within the same few minutes, 40 s each, counting Packet corrupt in the ffmpeg log:

Reader	Packet corrupt
Straight off the tuner (curl http://<hdhr>:5004/auto/v101)	0
Jellyfin's relay file, read with curl	0
Jellyfin's relay file, read live with a separate ffmpeg -c copy	0
Jellyfin's own transcode of that same relay	59–60

A real playback session showed the same thing: 45 corrupt packets and 32 concealment events in 26 s.

Things tried that made no difference:

• AllowStreamSharing: false on the tuner — still routed via /LiveTv/LiveStreamFiles/, still ~60 corrupt / 40 s.
• Full VAAPI (hw decode + deinterlace_vaapi + hw encode) — corrupt packets dropped (34 vs 59) but throughput fell to 0.56x, so not usable as a comparison.

Confirmation that it's the decode-in-Jellyfin path: putting TVHeadend in front of the tuner (it deinterlaces/encodes and hands Jellyfin progressive 1080p50 H.264+AAC, so Jellyfin does -c:v copy) gives 0 corrupt packets and 0 decode errors on the same channel, same hardware.

What I think is happening

Backpressure at the relay's write head. A -c copy reader keeps up trivially; a decode → deinterlace → encode pipeline consumes in bursts and appears to lose data from the relay file while it is being written. Only the transcoding consumer sees the loss, which would fit that.

Related

#17788 — the timestamp/DTS issue on the remux path of the same kind of stream. Separate symptom (that one is judder with -c copy; this one is corruption only under transcode), but they compound on interlaced DVB-T2 broadcast.

Happy to capture logs / run a specific test if it helps.