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.