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 15 hours ago by PowerCC

[flashls82 7]

We need all the development energy we can get on this, I don't think anybody has exactly cracked it yet. Do you imagine this working alongside something like Dispatcharr or as an alternative? Dispatcharr is great overall around bundling together streams into channels and switching over automatically when things stall, but it's still not as robust as I want/as it needs to be to play nice with Emby consistently (mainly because Emby itself is coded to give up on streams and recordings way too easily).

[PowerCC 13]

Great question @flashls82I actually see this fitting in as both a perfect companion to Dispatcharr and a lightweight alternative to it.

Dispatcharr is great at the big-picture stuff, like managing multiple providers and failover routing. The problem is that Emby, Channels DVR, and Jellyfin (this isn't isolated to just Emby) still kill streams and ruin recordings during those tiny gaps when Dispatcharr is swapping sources. If you feed Dispatcharr’s output through my solution, it acts as a shock absorber. During a stream stall or source swap, it holds the pipe open and feeds the DVR an outage slate. Dispatcharr gets all the time it needs to switch, the client never detects a dead socket, and your recordings stay completely safe. (And if you don't need multi-provider routing at all, it works perfectly as a standalone, lightweight watchdog proxy).

On the technical side, the engine is built on a custom, hardware-accelerated stream orchestration layer. Processing feeds, generating slates, and managing the ring buffers for each virtual tuner—which run directly in RAM for maximum performance (highly preferred)—are all offloaded to the GPU (AMD AMF, Intel QuickSync, NVIDIA NVENC, and Apple VideoToolbox).

There is a software libx264 fallback and a direct -copy option for raw MPEG-TS passthrough for setups without hardware, but they run in a more limited capacity just to stitch the stream and the slate. GPU is the gold standard here. It stops your CPU from choking when running multiple recording sessions, and it transcodes everything into a standardized, highly compatible stream. Because of that, timeline seeking and scrubbing on your clients becomes smooth as butter.

[ebr 16492]

3 hours ago, PowerCC said:

the client never detects a dead socket, and your recordings stay completely safe

Hi.  What happens if the stream really did go down permanently?

[flashls82 7]

3 hours ago, PowerCC said:

There is a software libx264 fallback and a direct -copy option for raw MPEG-TS passthrough for setups without hardware, but they run in a more limited capacity just to stitch the stream and the slate. GPU is the gold standard here. It stops your CPU from choking when running multiple recording sessions, and it transcodes everything into a standardized, highly compatible stream. Because of that, timeline seeking and scrubbing on your clients becomes smooth as butter.

Sounds cool! Happy to help you beta test if/when you get to that point. 

[flashls82 7]

19 minutes ago, ebr said:

Hi.  What happens if the stream really did go down permanently?

I assume it would detect when a tool like Dispatcharr closes the connection vs. just failing over to a new stream (otherwise the recording would never end). 

I realize this has been covered in other threads, and that in theory some bigger rethink of live TV in Emby is coming someday, but in the meantime I really wish we could add some basic functionality to control the number of times Emby tries to reconnect a stream before it gives up, or to auto-resume a recording that ends before its scheduled time. 

[PowerCC 13]

58 minutes ago, ebr said:

Hi.  What happens if the stream really did go down permanently?

The core design is simple: the proxy guarantees Emby a continuous, valid MPEG-TS stream regardless of upstream state.

When the upstream stalls, the proxy does not propagate EOF or collapse the socket. Instead, it monitors configurable heartbeat and stall thresholds (check_interval, stall_detect_ticks, drop_forgive_secs, etc.). Once starvation is confirmed, it immediately replaces the missing input with a hardware-encoded SERVICE OUTAGE slate, keeping the transport stream valid and uninterrupted.

The session remains alive until the scheduled program actually ends (including padding). If the upstream recovers at any point—whether after 5, 20, or 45 minutes—the proxy flushes the slate, resynchronizes, and seamlessly rejoins the live broadcast. From Emby's perspective, playback is a single continuous .ts stream with an outage slate inserted during signal loss.

A graceful socket shutdown only occurs when the scheduled program ends, although configurable timeouts (such as drop_forgive_secs) allow deployments that prefer early session termination.

[ebr 16492]

Okay, so it'll be like old-school TV.  It just always broadcasting something even if its just "color bars".  Thx.

It might be fun to have a set of configurable slates like the old color bars or old-time "We're experiencing a problem, your program will resume shortly..." kind of things.

[PowerCC 13]

1 hour ago, flashls82 said:

Sounds cool! Happy to help you beta test if/when you get to that point. 

Before I do a broader release, I plan to roll this out to a small, selected group. But there's no community I'd rather introduce it to first than this one.

The project originally started as an Emby-specific watchdog, but I quickly realized I didn't need to depend on any media server API—or even HDHomeRun emulation—if I controlled the upstream stream itself. That insight completely changed the architecture and made the project platform-agnostic. (That said, it doesn't support Plex, since Plex relies on HDHomeRun integration, which I intentionally moved away from.)

[ebr 16492]

e.g.

[PowerCC 13]

1 minute ago, ebr said:

Okay, so it'll be like old-school TV.  It just always broadcasting something even if its just "color bars".  Thx.

It might be fun to have a set of configurable slates like the old color bars or old-time "We're experiencing a problem, your program will resume shortly..." kind of things.

We can absolutely bring back the classic 1980s color bars.

That said, keep in mind I also have a software fallback (libx264), so I'd prefer to keep it lightweight and just render the text, with the optional TranscodeProfile of your choice.

At launch, the goal is to support nearly every GPU and platform, so I'll definitely need your help testing across all of them.