Live tv: disable stream sharing

[horstepipe 429]

In Jellyfin there is that option for m3u tuners.

As me and probably most people will use Dispatcharr now or soon, this is being done twice at the moment - by Dispatcharr and by Emby.

So if we can disable that in Emby we will hopefully get a slightly faster stream start.

BR

 

 

Edited December 26, 2025 by horstepipe

[horstepipe 429]

@softworkz

maybe this could be considered for tvnext?

[Luke 42718]

Hi, we could but it wouldn’t change that streams still run through your Emby server, if that’s what you’re getting at.

[horstepipe 429]

On 12/27/2025 at 9:24 PM, Luke said:

Hi, we could but it wouldn’t change that streams still run through your Emby server, if that’s what you’re getting at.

no, I am aware that this is a must for other reasons. I just want to reduce the playback start time.

[horstepipe 429]

Furthermore, this would eliminate a source of error/stream issues.

[Luke 42718]

4 hours ago, horstepipe said:

no, I am aware that this is a must for other reasons. I just want to reduce the playback start time.

As long as it's running through Emby Server, then disabling stream sharing will not reduce playback start time or eliminate a source of errors. The only difference would be in what happens when you try to open a second stream of the same channel.

[horstepipe 429]

On 12/29/2025 at 7:47 PM, Luke said:

As long as it's running through Emby Server, then disabling stream sharing will not reduce playback start time or eliminate a source of errors. The only difference would be in what happens when you try to open a second stream of the same channel.

So why does a stream stock/hang via Emby sometimes while it works well when watching via Dispatcharr directly at the same time?

Edited January 11 by horstepipe

[Luke 42718]

Hi, are you still having an issue with this?

[horstepipe 429]

personally I don't watch lots of live tv and my users only complain if it is really bad. 
If I see that again and can confirm that the problem disappears when watching from dispatcharr or source directly I will inform you and send you logs.

BR

Edited January 25 by horstepipe

[copyrunstart 4]

I just ran into an issue with this last night. I was watching a football game in 4K on my Apple TV. My son tuned into the same game on the same channel on his Apple TV, we are both on the local network, and his stream was very glitchy and somewhat slow motion. The two fixes I found were pausing his stream for 10 seconds and then hitting play, or going to the gear icon and selecting Playback Correction. This doesn’t happen with a 1080p channel. I agree, though, it would be nice to have the ability to disable this.

[jonzey231 45]

On 1/24/2026 at 6:09 PM, Luke said:

Hi, are you still having an issue with this?

I definitely have this issue. Dispatcharr --> Emby takes around 5-7 seconds to start playing, meanwhile Dispatcharr --> nearly any other IPTV app or VLC is an instant start-up.

[Shawneau 0]

On 24/01/2026 at 18:09, Luke said:

Hi, are you still having an issue with this?

@copyrunstartand I have strikingly similar experiences with this actually. Definitely an issue. Thanks for please looking at this one.

[wetz01 0]

Also having this issue when people start a stream that someone else is already watching. There will be stuttering for a while until it resolves itself unless the person pauses the stream and resumes as mentioned above. Would love a toggle to disable Emby restreaming and just let other applications like Dispatcharr handle it.

[copyrunstart 4]

@Lukename your favorite cofee or beer and I'll literally doordash it to you for looking into this.

[Renato Meneses 0]

The same thing happens here.

[kenconroy 0]

This would be huge. Please consider this.

[carloss66 0]

I am also experiencing this issue. 

[ramgoat 1]

4 hours ago, jonzey231 said:

I definitely have this issue. Dispatcharr --> Emby takes around 5-7 seconds to start playing, meanwhile Dispatcharr --> nearly any other IPTV app or VLC is an instant start-up.

+1

I and my users experience this consistently each time a channel is started, including when switching from channel to channel. 

Previewing the same stream directly in Dispatcharr takes under 2 seconds, usually less. 

[sbcrumb 2]

I am also experiencing this issue. 

[ExploitPanda 0]

+1
I am also experiencing this issue. Recently switched to dispatcharr and just like everyone else, it takes much longer to play on emby compared to other IPTV apps

[kicsrules 3]

i thought i was the only one experiencing this....  dispatcher --> emby takes wayy to long for the stream to start

[copyrunstart 4]

On 1/24/2026 at 5:09 PM, Luke said:

Hi, are you still having an issue with this?

@Lukeany word on if this will be possible? 

[nweishar 16]

Would love for this to be worked on!

[PowerCC 13]

Regarding the Dispatcharr architecture being discussed, I think this comes down to different design tradeoffs rather than one approach being inherently right or wrong.

In my own implementation (which is a separate upstream proxy and not related to either Emby or Dispatcharr), I took a different approach to stream orchestration. Rather than relying on a centralized dispatcher model, each tuner session manages its own lifecycle, state, and recovery logic. If an upstream stream stalls or an FFmpeg process becomes unhealthy, the impact is isolated to that individual session instead of affecting unrelated tuners.

Some of the design choices that have worked well for me include:

• Tuner-isolated session management — each stream operates independently, allowing failures to be contained rather than propagated.

• Fine-grained locking — synchronization is scoped only to the resources that require it, reducing contention and allowing unrelated sessions to continue operating.

• Asynchronous stream startup — stream initialization does not block the main control path. A watchdog monitors startup and recovery, allowing individual sessions to restart without impacting the rest of the system.

• Independent FFmpeg lifecycle management — each pipeline is monitored separately, allowing stalled or orphaned processes to be cleaned up and restarted without disrupting other active streams.

I also support stream sharing because it is an efficient use of resources when multiple clients are watching the same channel. The tradeoff is that shared pipelines and buffers need to be managed carefully. In my setup, I limit retained live stream buffer duration (with Emby's Live TV buffer capped at 1 hour) to balance the benefits of sharing against the cost of maintaining long-lived shared state.

Another point that often comes up is startup time. In my case, a new stream typically takes around 5–6 seconds to become available, and that is intentional. The proxy does not immediately expose an unvalidated stream; it first establishes the upstream connection, verifies the FFmpeg pipeline, confirms that data is flowing correctly, and builds enough buffer to provide a stable output.

Could that startup time be reduced? Probably. However, for a backend proxy, I consider a few extra seconds of initialization a reasonable tradeoff if it results in fewer playback interruptions, better recovery behavior, and a more reliable stream once playback begins.

I also think it is important to compare systems with similar goals. Applications like VLC or TiviMate are optimized for fast channel changes and direct playback. A backend proxy has different responsibilities: it needs to provide a stable, recoverable stream that can support media servers, recordings, multiple clients, and long-running sessions.

None of this is meant as criticism of Dispatcharr. Different projects make different architectural choices based on their goals and constraints. I simply chose a model focused on tuner isolation, independent recovery, and stable stream delivery, and it has worked well for my use case.