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

[jonzey231 39]

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 39]

Example configuration page.

[pdclark 11]

Up!

[Luke 42105]

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

[jonzey231 39]

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 1]

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.