Channels Reusing Stream for Multiple Viewers

Channels DVR Server
#22

I could be wrong, but the way I’m interpreting this note is that we can only toggle Tuner Sharing on or off with HDHomeRun channels, and that any other stream from other channels, such as the ones you’re piping in via Dispatchharr, will always use Tuner Sharing, no matter what.

:bulb: Tuner Sharing only affects local HDHomeRun streams. Streaming away-from-home, or from DVR-powered sources (such as TV Everywhere or Custom Channels) will always stream through your DVR and use the tuner sharing buffer

(emphasis mine)

Just brainstorming here, but have you tried enabling "Direct stream URLs" in Dispatcharr?

And I'm curious, what is your broadband's upstream speed?

#23

Direct

Direct will uses a constant TCP connection to directly stream your video from Channels DVR Server to your device. This is the fastest way to stream video, but it requires a constant connection to your DVR Server. If you lose your connection, you’ll lose your video.

Direct is what is used by default when you are at home and using Original Quality.

I use a baremetal tailscale server for remote access so my phone thinks it's 'home'
your earlier activity screenshot showed your iphone using remux so it's using the 'internet streaming' which can also be set to original.
I travel all over the country side daily and even when I dip through a valley driving and my cell drops, the video does resume it's self unless the connection was gone too long, all you have to do is press play. I've never needed transcoding on my android stuff.

Stream

Stream uses HTTP Live Streaming(HLS) which uses many HTTP requests and local caching to stream videos.

Stream is what is used by default when you are away from home and using any quality selection or have chosen a quality other than Original while at home.

Protip: Use Stream while at home to place the buffer on the server if your streaming device’s storage is preventing you from pausing for a long enough time.

Deep Dive

There are many cases you may choose one over the other. Here is a deeper explanation of each.

Direct

Direct uses MPEG-TS over a single TCP connection. This has the benefit of having the lowest latency for tuning and lowest overhead for your DVR and network. The downside is that it is susceptible to experiencing issues if there is high latency (which is why we do not use this for Away From Home streaming).

this explains why tuner sharing is a thing for hdhr (channels has a client that only connects to them, without a cdvr server)

When watching live from a HDHomeRun, a connection is made directly from the app to the HDHomeRun, bypassing the DVR entirely. If two apps are watching the same channel at the same time, it will use two tuner slots on the HDHomeRun.

When watching live from TVE, a connection is made to the DVR because all TVE streams are served by the DVR. The client stores the entire Live TV buffer locally.

if any clients are using stream you will have delays on live feeds. (the following reference to "LiveTv" not transcoding does not apply to many custom sources)

Stream

When watching Live TV from any source, it will be processed and served from the DVR (but it will not be transcoded). Because each HLS segment is 1 second and the additional processing that must happen, tuning into Live TV can take 1-3 seconds to load (which is generally higher and less consistent than Direct).

This is also putting small additional CPU and disk IO load on the DVR, which generally is not a problem, but can cause issues if the DVR or disk is overloaded.

The server stores the entire Live TV buffer and the client will store as much of it as it can handle with the available disk space.

also more on tuner sharing

Tuner Sharing

Tuner Sharing is a feature that modifies the behavior of Direct to cause live TV streams going to the HDHomeRun to go through the DVR, allowing for multiple apps watching the same channel to only use a single tuner on the HDHomeRun.

This setting does not change the behavior of watching TVE streams.

The DVR buffer holds a small number of seconds of data so it is still the responsibility of the client to store the entire Live TV buffer locally. This doubles the amount of network traffic and can lead to flaky problems if the DVR is overloaded or the network is at its limit (from being over WiFi or other such issues).

What should you use?

If you’re not having any problems, use the default settings. Direct streaming without Tuner Sharing will give you the most reliable experience in the most situations.

If you find that your streaming device does not have enough storage to get a very long buffer when pausing, use Stream with Original Quality to have the server handle the buffering, giving you more time to pause.

default are there for most use cases, custom sources can mean custom settings

If you have particular reasons to change the settings, please use these settings to make your experience better.

#24

This is weird and shouldn't be the case. Can you recreate this issue and when you do, submit diagnostics from both clients and let us know?

#25

I submitted logs from both Apple TV clients and from my CDVR server.

CDVR Server: b4a8104b-cc82-4880-b8a9-b1c55edfd3b3
Apple TVs: no codes were presented

#26

@eric anything stand out in the logs?

#27

If you pause for a second and resume does the choppy session start behaving properly?

#28

I will give this a try tomorrow when I'm home and let you know. Thanks for your response!

#29

Yes.

#30

Is the thing that you're feeding through Dispatcharr providing HLS or MPEG-TS?

#31

MPEG-TS into CDVR.

#32

What format is the input to Dispatcharr?

#33

Also MPEG.TS.

#34

@eric Emby does the same thing, too. It appears it has to do with the stream being duplicated when a second viewer tunes in instead of opened an additional connection to the source.

#35

Anything in the debug log that can help point to the issue, @eric?

#36

@J0E Have you tried plugging the stream directly into Channels without going through Dispatcharr?

The issue appears to be that the MPEG-TS stream you're connecting to does not send data at a consistent rate (which is the general expectation we have of MPEG-TS streams). When the first client connects, it receives a 10s buffer immediately, and eventually drifts up to having sent 30s worth of video ahead of what can be played back at realtime (this stream is sending more than the amount of data that can be watched in real time).

When the second client connects, we do not have that 10s of buffer, and so the uneven streaming of the server causes the hiccups.

So, yes, this is a misbehaving server, and it interacts poorly with our infrastructure (Tuner Sharing).

If your streaming source had been HLS, we would have been able to provide each client with their own buffer at client start (due to how our HLS shares buffers), but we don't currently have that capability for MPEG-TS sources at this time.

1 Like
#37

@eric thanks for the detailed explanation! I have not plugged my stream directly into Channels as I route it through Dispatcharr as a proxy. Let me take back your explanation to the Dispatcharr team and see what they say.

#38

@eric it looks like the Dispatcharr developers are looking to implement hls in the future. In the meantime, is there any way to force separate upstream stream requests per viewer?

#39

This thread highlights an interesting problem that exists at the infrastructure layer: what happens when multiple viewers request the same live stream?

Channels DVR has done a great job building a polished Live TV and DVR experience. The complexity starts when the upstream source is not a traditional tuner, but an IPTV/M3U-based provider where stream sessions, connection limits, buffering behavior, and provider-side handling all come into play.

From the backend infrastructure side, stream sharing is not as simple as opening another player window.

There is a lot of logic involved:

  • Should multiple viewers share one upstream connection?
  • Should each viewer get an independent session?
  • How do you handle providers that behave differently when a stream has multiple consumers?
  • How do you prevent one unstable shared stream from impacting every connected client?

This is where a dedicated stream orchestration layer becomes valuable.

A DVR platform's job is to manage the viewing experience: guide data, recordings, scheduling, playback, and the user interface. The job of managing raw stream health and upstream behavior is closer to what a headend system does.

The infrastructure layer I have been working on approaches this problem differently:

  • Stream Session Management — Instead of relying on the client or DVR to react after a stream problem appears, the backend manages stream sessions proactively and understands how many consumers are attached to each feed.

  • Intelligent Stream Pooling — Shared streams can be useful when they work correctly, but the system should be able to decide when sharing is beneficial and when separate upstream sessions are required.

  • Provider-Aware Recovery — Different IPTV sources behave differently. Some handle multiple consumers well, others introduce buffering, throttling, or instability. The orchestration layer can adapt to those behaviors.

The DVR receives a stable, predictable source. The complexity stays behind the scenes instead of being pushed into the playback client.

The larger point is that reliable IPTV delivery starts before the stream ever reaches the DVR. A media application can provide an excellent viewing experience, but enterprise-level reliability requires a dedicated layer responsible for stream lifecycle, health monitoring, and orchestration.

This is the type of infrastructure I have been quietly building. The goal is not to replace platforms like Channels DVR, but to solve the difficult backend problems that sit underneath them.

#40

This is the third time you've posted this comment: once in an Emby thread I commented on, once in an Emby thread I upvoted, and now in this Channels DVR thread that I started. I'm not sure what your intent is here, but nothing you posted answered my question.

#41

I understand your question, and you’re right that the immediate issue is why the same upstream MPEG-TS session is being reused instead of creating separate connections.

The reason I’ve been focusing on the infrastructure layer is because this behavior is exactly where the complexity starts. With traditional tuners, the rules are simple: a tuner is either available or not. With IPTV sources, there are additional decisions involved: should a stream be shared, should each viewer get its own session, how should buffering be handled, and what happens when the upstream source doesn’t behave like a proper tuner?

In your case, Channels is seeing one MPEG-TS source coming in through Dispatcharr and handling it according to the assumptions it has for that type of input. The challenge is that IPTV sources don’t always behave like HDHomeRun tuners, and the same sharing behavior can have different results depending on the upstream source.

This is the exact gap I’ve been working on. The goal is not to replace Channels or Dispatcharr, but to put a layer in between that understands these stream behaviors and can make those decisions before the DVR ever sees the feed.

So the short answer is: yes, the immediate fix would be the ability to force independent upstream sessions. The larger solution is having a layer that can intelligently decide when sharing is safe and when it is not.