A new approach to making IPTV behave more like traditional tuners

[PowerCC 13]

I've been quietly experimenting with something over the past several months that I think may interest a lot of Emby Premiere users.

The goal is simple: make IPTV behave more like a reliable tuner.

Many of us have run into the same challenges:

• Random stream drops.
• Channels that work perfectly one day and fail the next.
• Shared upstream streams causing conflicts between multiple viewers or recordings.
• Long recovery times when something silently breaks.
• Having to manually restart, refresh, or intervene when live TV should just work.

Most IPTV tools do an excellent job organizing the pieces — playlists, guides, channel mapping, and metadata. The challenge starts after playback begins.

What happens when the live stream itself becomes unreliable?

I've been exploring a concept that adds a reliability layer between the IPTV source and the client. The idea is not to replace existing IPTV management workflows, but to make the delivery pipeline more resilient.

A few things I've been testing:

• Detecting stalled streams automatically.
• Recovering failed sessions without affecting other channels.
• Keeping individual streams isolated so one failure doesn't cascade.
• Improving channel startup behavior.
• Handling unstable upstream behavior without requiring constant babysitting.
• Using available hardware acceleration where it makes sense.

One area I've been particularly interested in is the "silent failure" problem.

A stream can look connected, but no longer actually be delivering usable data. The client doesn't always know whether the provider failed, the encoder stalled, or the connection simply stopped moving.

The concept I'm testing looks more like this:

Live stream active
↓
Upstream stops delivering data
↓
Pipeline detects the stall
↓
Failed session is isolated
↓
Stream is rebuilt automatically
↓
Service returns

A real-world example from testing:

15:17:47 Sports channel — upstream paused
15:18:33 No data detected — recovery initiated
15:18:37 Rebuilding stream pipeline
15:18:46 Upstream stream restored
15:18:48 Playback pipeline healthy again

During 3 days of continuous uptime across 42 recording sessions, here is exactly how the code managed upstream turbulence:

• 11 Drops: The system intercepted and recovered from 11 hard disconnects (outages lasting over 50 seconds). To prevent Emby from throwing an error and failing a recording during the rebuild, the code keeps the pipeline alive—seamlessly transitioning from the live feed to an FFmpeg-generated "Service Outage" slate to guarantee a continuous, healthy stream.
• 1 Stall: The source went dead (zero bytes for over 50 seconds) but bounced back moments later. Rather than prematurely dropping the axe on the FFmpeg session, the pipeline simply held the pipe open.

Because this pipe never closes—whether delivering the active broadcast or the recovery slate—Emby receives a flawless, unbroken stream, completely blind to the upstream chaos. This is exactly the real-world scenario this solution was built for. 

The interesting challenge isn't detecting that something failed — it's recovering quickly enough that the viewer experience remains uninterrupted.

I’m keeping the code private for now to focus on final stress testing and refinements, but the performance data has been incredibly promising. My ultimate goal is to bridge the gap between fragile, high-maintenance internet streams and the rock-solid reliability of a traditional hardware tuner. I look forward to sharing more with you all as soon as it's ready for public release.

Edited 50 minutes ago by PowerCC