Feature Request: Configurable timeout and auto-reconnect settings for Live TV channels

[jonzey231 45]

I use Dispatcharr as an IPTV proxy that assigns multiple backup streams to each channel. When a stream experiences issues (buffering, stuttering, or complete failure), Dispatcharr automatically fails over to the next available stream in the sequence.

Current Issue: When Emby encounters a problem connecting to a Live TV channel, it tends stops the connection attempt entirely after a few seconds. Even though Dispatcharr switches to a backup stream on the backend, Emby has already stopped trying to connect and does not automatically retry.

Requested Solution: Add configurable settings for Live TV channels:

• Connection timeout duration (time to wait before considering a stream failed)
• Auto-reconnect behavior (automatically retry connection after timeout)
• Number of retry attempts

This would allow Emby to detect when a stream has failed and automatically reconnect, which would then pick up the backup stream that Dispatcharr has switched to.

Also, as a bonus, adding native Xtream Codes (XC) functionality would be greatly appreciated.

[jonzey231 45]

Example configuration page.

[pdclark 13]

Up!

[Luke 42709]

Hi, more options to control this are certainly possible. Thanks.

[jonzey231 45]

On 2/16/2026 at 12:58 AM, Luke said:

Hi, more options to control this are certainly possible. Thanks.

Thanks!
 

Also PM'd you for a TestFlight invite. 

[PowerCC 12]

I’d like to echo this feature request, as it addresses an important gap in Live TV recording. The core functionality for manual timers and reconnect/re-record already works, but without programid support in the REST API, those reconnects and re-records can’t operate fully seamlessly. In addition, there currently isn’t a way to configure timeout behavior or define maximum reconnect attempts, which limits reliability in real-world scenarios.

If the REST API could support programid for manual timers and allow configuration of timeout handling and reconnect limits, this would make the feature far more robust and predictable for everyone. Examples of existing approaches can certainly be shared if helpful—the goal is simply to make this work cleanly and natively within Emby for all users.

[nweishar 16]

I'll echo this request!

[thefloppydisk 2]

+1 on this request as well.

[flashls82 6]

+1 on this, too, and I would add that this retry functionality would be great to have on recordings that end before their scheduled end time, too (even if they are not reported as failed).

[AndreasRO 0]

+1!!!!

[PowerCC 12]

First off, the number of +1s on this thread proves that Live TV/m3u resilience is a massive pain point. Dropped streams, buffering, and failed reconnects completely ruin the "couch experience."

However, I want to chime in with some perspective from the backend infrastructure side—and share a glimpse of how this is ultimately solved.

I have massive respect for @Lukeand the Emby team. They are building a phenomenal, all-encompassing media server for a huge user base across countless devices. The reality is that building native, bulletproof IPTV stream orchestration (handling token expirations, 401 errors, rogue ffmpeg crashes, and upstream provider glitches) is incredibly complex. It honestly falls more into the realm of "Headend Appliance Infrastructure" than standard media server duties. I actually responded to this thread back in March offering the architecture for a dedicated streaming engine to handle this, but I completely understand and respect that adopting a third-party engine didn't fit their roadmap. They have a massive ecosystem to maintain, and keeping the core stable has to be their priority.

Because the problem still needed solving, I have been quietly building the solution at the infrastructure level.

To @jonzey231and everyone else in this thread: asking for a configurable timeout or an auto-reconnect loop in the Emby UI is ultimately just a band-aid. If your provider's stream drops or changes tokens, looping a reconnect on a dead URL from the client side is still going to fail or cause massive lag.

I am currently engineering a dedicated, standalone backend appliance that does exactly what this thread is asking for, and a whole lot more, by fixing the problem before it ever reaches Emby:

• Infrastructure-Level Orchestration: This engine sits between your provider and Emby, running a custom process monitor. If a stream jitters, drops, or errors out, the backend intercepts the failure, renegotiates with the provider, and recovers the feed seamlessly in the background.

• Zero Client Timeouts: Because the backend handles the connection resilience, Emby is fed a continuous, perfectly stable local stream. As far as Emby is concerned, the stream never went down. Emby doesn't need a timeout setting because it never loses the connection.

• True Headend Features: It handles localized circular buffering, instant JIT (Just-In-Time) catch-up of guide data, and active Tuner/Stream pooling.

Emby is an absolutely stellar front-end and library manager. But if you want enterprise-grade Live TV reliability, you shouldn't be relying on a media server to manage raw stream health. You handle stream orchestration at the backend.

I am keeping the project under wraps for now, but I am looking forward to sharing this solution with the community when the time is right.