Why you closed my disscusion`? (Live TV error: Exception: Failed to tune channel)

[GhostInductee]

Can you tell me why you closed my discussion? Don't you think it's a bit unfair not to even tell me why, or just leave me hanging like that? That doesn't reflect well on developers.

[edde746]

I misread your message, what error does it show now? Could you send a new log?

[edde746]

Setup

• Tuner: FRITZ!Box 6690 Cable at 192.168.178.1 (SAT>IP server, 4 DVB-C tuners)
• Server: Plex on QNAP NAS (/share/CE_CACHEDEV1_DATA/.qpkg/PlexMediaServer/)
• Channel: triplet://1:1079:11110 on 450 MHz DVB-C, 256QAM, SR 6900

What's happening (repeating cycle)

Every attempt follows the same failing pattern:

1. Tuning succeeds -- SAT>IP RTSP session is established, PAT/PMT tables are found, stream starts.

2. H.264 decode fails immediately -- The transcoder (ffmpeg) hits a wall of errors:

   [h264] non-existing PPS 0 referenced
   [h264] decode_slice_header error
   [h264] no frame!
   

   This repeats in a tight loop -- the decoder never finds a valid keyframe/PPS to begin decoding.

3. Plex kills the transcoder after ~6-25 seconds:

   Plex Transcoder exit code is -9 (signal: Killed)
   

4. HTTP connection drops -- The tuner service sees Connection reset by peer or End of file, tears down the stream, and Plex retries.

Root cause

The DVB-C stream from the FRITZ!Box SAT>IP server is delivering corrupt/incomplete H.264 data. The signal stats tell the story:

Time	Signal	Quality	Lock
08:20	43	0	0
11:03	43	0	0
14:36	43	0	0
14:40	43	0	0
14:41	43	0	0
14:41 (retry)	52	100	1

6 out of 7 attempts show quality=0, lock=0 -- the tuner isn't properly locking onto the signal. Enough data leaks through to find PAT/PMT tables, but the actual video payload is garbage. Even the one "good lock" attempt (52/100/1) still resulted in the transcoder being killed.

Likely causes (in order of probability)

1. Poor cable signal on that frequency -- 450 MHz may have a weak/noisy signal on your cable connection. Check if other channels on different frequencies work. The signal level of 43 is borderline.

2. FRITZ!Box SAT>IP firmware issue -- The FRITZ!Box's SAT>IP implementation is known to be basic. Try updating the FRITZ!Box firmware to the latest version.

3. Cable signal path issue -- Bad splitter, loose coax connector, or damaged cable can cause exactly this symptom (PAT/PMT work but video is corrupted).

4. Tuner contention on the FRITZ!Box -- If the FRITZ!Box is also using tuners for its own features (like streaming to FRITZ!App TV or recording), fewer tuners are available and they may conflict.

Recommended fixes

• Check your cable signal: Log into your FRITZ!Box admin (fritz.box) and check the cable signal levels under Internet > DSL/Cable Information. Look at the SNR and signal levels for the downstream frequencies around 450 MHz.
• Try a different channel to see if the issue is frequency-specific.
• Restart the FRITZ!Box to reset tuner state.
• Update FRITZ!Box firmware (Fritz!OS).
• Check physical cable connections -- tighten all coax connectors, remove any unnecessary splitters.
• If the issue persists, consider a dedicated DVB-C SAT>IP server (like a Digital Devices Octopus NET) instead of relying on the FRITZ!Box's built-in SAT>IP.

Written by Claude

[GhostInductee]

Okay, I forgot to mention something crucial.

I don't have these problems with Plex Desktop. All streaming works there.

[GhostInductee]

I asked ChatGPT about it, and here's an excerpt:

The problem is, I can watch all these channels without any issues on the Plex Desktop and in the browser via Plex Media Server. But not on Plezy. I've also informed the developer about this.

That's a very important point 💡 If it works perfectly on the Plex Desktop and in the browser, the "signal is fundamentally broken" theory falls apart. I'll quickly check what Plezy actually is and whether it has any known quirks with live TV/SAT>IP.

Thought for 1 minute 19 seconds

Yes — then the diagnosis changes significantly.

If the same channel works perfectly on the Plex Desktop and in the browser, your DVB-C signal isn't the main problem. Then it's very likely due to Plezy itself or the way Plezy handles Plex Live TV/the transcoding decision. This also explains why Plezy is a separate Plex client and uses mpv/libmpv as its playback engine, meaning it doesn't use the same playback path as the official Plex clients.

The first thing you should do is:

Update Plezy to the latest version.

The Plezy repository lists version 1.25.1 from March 9, 2026, as the current version, and the releases from the last few weeks include several playback fixes.

While playing in Plezy, open the Plex dashboard and check the session.

The important question is:

Is Plezy using Direct Play / Direct Stream / Transcode?

If Plezy is transcoding, but Plex Desktop/Browser isn't, then you've almost found the culprit: Plezy is apparently requesting a different format or playback mode. This wouldn't be a cable issue, but rather a client/compatibility problem.

Same channel

Same PMS

Plex Desktop/Browser: works

Plezy: fails

Plus a screenshot of the Plex dashboard showing the playback decision in Plezy.

This is much more significant than just the ffmpeg errors.

If Plezy has options like Hardware Decode / Tunneled Playback / Audio Passthrough: try switching them.

In the current Plezy releases, you can see that they are actively fixing and changing things in this area, for example, regarding tunneling, codec/playback stability, and mpv-related issues.

The crucial point is:

You shouldn't start by tinkering with your FRITZ!Box, cable, or frequency.

Your next sensible step is to update Plezy and monitor the Plex dashboard during the failed startup. This will tell you within a few minutes whether Plezy is triggering a problematic transcode path.

It's also worth noting that Plezy is still visibly under development when it comes to live TV: There was a thread about live TV support as recently as the end of 2025, and even in February 2026, there were still open live TV-related bugs where something works in the official Plex client but not in Plezy.

If you'd like, I'll tell you next exactly where in the Plex dashboard you can see whether Plezy is transcoding or direct playing.

<img width="2081" height="1353" alt="Screenshot 2026-03-09 155730" src="https://github.com/user-attachments/assets/06cf09a0-14f0-4e21-8819-0a68398bac79" />

[edde746]

For Live TV we do use the transcode endpoint, with the same profile as the Plex Desktop client. I'm not sure why it's failing and debugging/fixing the issue when I can't reproduce it is very slow, time consuming and annoying. Not much I can do.

[GhostInductee]

Thanks — I pulled another PMS log bundle and compared the two test runs as closely as I could.

What I can confirm from this log set:

1. I can clearly identify the successful official Plex Desktop playback around 16:07.
   PMS shows:

   • tuner start at 16:07:44
   • transponder tuning to 546000 / 256QAM / SR 6900
   • Signal stats: 43, 0, 0
   • PAT/PMT found, stream started
   • then the initial Live TV session immediately logs repeated H.264 errors:
     • non-existing PPS 0 referenced
     • decode_slice_header error
     • no frame!

   Despite that, the official client still continues with:

   • /video/:/transcode/universal/decision
   • directPlay=0
   • directStream=1
   • TranscodeUniversalRequest: using profile Plex Desktop
   • then /video/:/transcode/universal/start

   The official client request is:

   • X-Plex-Product => Plex for Windows
   • X-Plex-Client-Profile-Name => Plex Desktop
   • start request uses User-Agent => libmpv

   So the official client is able to start playback even though the source side is already noisy / imperfect.

2. Plezy is definitely present in the same log bundle, around 16:06:51.
   I can see requests like:

   • X-Plex-Product => Plezy
   • X-Plex-Version => 1.25.1
   • X-Plex-Platform => Flutter
   • X-Plex-Client-Profile-Name => Generic

   But in this specific PMS log bundle I do NOT see a matching Plezy Live TV playback request for the failing attempt:

   • no visible /video/:/transcode/universal/decision
   • no visible /video/:/transcode/universal/start
   • no clearly attributable Plezy playback session for that failed run

So at least from this bundle, I can’t honestly say “Plezy sends the same playback request and PMS responds differently”.
What I can say is:

• the official Plex Desktop path is visible and succeeds
• Plezy is visible as a client in the logs
• but the actual failing Plezy playback request is not clearly present in this ZIP

That means one of two things:

• either the failing Plezy playback attempt was not captured in this exported log set / the timestamp I gave was slightly off
• or Plezy is failing before it even reaches the actual playback/transcode request on the PMS side

I think the most useful next step would be one of these:

A) I re-run a tighter test and provide:

• exact timestamps to the second
• Plezy launch attempt
• successful Plex Desktop launch immediately after
• PMS logs + Plezy debug logs

or

B) if possible, add extra Plezy-side logging specifically for Live TV startup:

• selected channel / ratingKey / item key
• whether it decides to call universal decision/start
• final request URL / params sent
• playback backend selection
• any failure before the PMS playback request is made

Because right now, the strongest result from this comparison is actually:
the successful official client playback is present in PMS, but the failing Plezy playback request is not clearly visible in the same bundle.
That seems important in itself.

I’m attaching the PMS logs and will also provide Plezy debug logs.
The successful Plex Desktop playback is visible in PMS, but the failed Plezy Live TV playback request is not clearly visible in this bundle, which may suggest the failure happens before the actual playback/transcode request reaches PMS.

Plezy start: approx. 16:05

Plex Desktop: approx. 16:07

Plezy Log-ID i0e99
Plex Media Server Logs_2026-03-09_16-08-06.zip