HLS option

A few notes about your post:

This doesn't really have a bearing on this issue, as all your clients seem to be wireless. Bandwidth doesn't seem to at issue, merely latency.

The quality of the streams is the same as the source. The only difference is that the server is taking the transport streams (TS) it uses internally, and remuxing those to HLS; the content doesn't change, only the parcel within which you receive it.

I am glad you found a solution that works for you.

I made some more changes to buffering behavior in APK v2022.07.27.0042

Thank you for testing this experimental feature. It gives us more confidence its working correctly which will help us make it available in the regular app sooner.

The problem with the client cache still exists, as it isn't filled with enough data before the player starts. Now I can force a pause to allow the cache to fill eliminating the problem, but I would prefer that it be handled with software. I thought someone might think the reason the cache wasn't filled was because of a poor network connection to the server. I realize you are extremely knowledgeable about the Channels software, but others may be interested in my results.

1 Like

Upgraded to your latest. Still getting pauses. The video starts playing when the cache only has 1 sec of video data which doesn't seem to be enough. I get fluctuations of about 1 sec in the cache total while the video is playing.

It is supposed to wait for 2s of data with that build. Something must not be working.

Okay please try new beta

Installed new beta, works perfectly now. I have tested it on my Firestick, Chromecast, and Phone. I will do more testing on my other devices. I do get almost 5 sec of latency before the live stream starts, except on TVE channels it is only 3 seconds at most. But that is what I was expecting so it is acceptable to me.

2 Likes

Results of further testing: No unforced pauses now occur with OTA live streaming. I started 6 OTA live streams, 2 OTA browser transcoded streams, and recorded 4 TVE live streams all at the same time. Everything looked good.

Now a little not so good. The cache works differently for TVE live streams. The cache fluctuations are much greater, and I often get at least one pause during the first 15 seconds. One pause doesn't really bother me, but it does seem to happen quite often only on TVE live streams.

New beta tweaks the buffers to be slightly smaller. It should pause for less time on TVE now.

I'm guessing you're seeing pauses on TVE channels that are being tuner shared, and are either recording or being watched already? If so that is a known issue.

1 Like

We've added a setting in the latest DVR beta to change the server buffer size from the default of 1 hour up to 4 hours.

Questions:

  1. Does the server Live Buffer restart on a channel change, or does it keep channel changes in the buffer.
  2. So there is ALWAYS a buffer going and using up to 1-4 hours of space on the DVR hard drive, like any cable DVR also does.
  3. If we turn off the HLS option will that clear/release any buffer space on the Server DVR.
    Have not tried yet, but good to know it is now available.
    .
    Good job on this to the Developers, Thanks.

Updated and it may be running slightly better. I don't see much difference. I do see the problem of getting all this work. The tuners for OTA streams produce consistent data, so you can send out fairly consistent 1 sec interval streams from the server. The TVE streams being received by the server are not consistent and can very between different channels. They produce large packets of data at 2 to 4 second intervals. Noticed the delay from the very first packet to the second packet seems to always be very large which often causes a client video pause at about 4 sec. At any rate, it is working good enough for more testing.

1 Like

One thing to remember is that the buffer is not shared each client has it's own buffer on the server ... You will see an FFMPEG remux for each client even watching the same channel.

Each client has a buffer, Good point.

1 Like

Maybe something like this ...

Client 1 tunes channel
Client 2 tunes same Channel shares buffer.... option to watch from beginning of buffer or current time.
Client 1 disconnects.
Client 2 still using the buffer not deleted.
Client 2 disconnects buffer is deleted.

image

Yes, the buffer restarts on channel change.

This buffer is only in use when using the HLS protocol (which is used when streaming remotely, when transcoding, or when the new debug setting is enabled). The buffer has previously been locked at 1 hour. This change makes it a setting that can be made longer.

Each time a client stops watching a channel, the buffer space is cleaned up.

We're continuing to think about what we can do to make this better, but it is a current limitation of the way we share streams between clients.

That is correct. The buffers are not shared because each client is its own Transcoder Session, which is how we currently ensure that only one encode is happening per viewing client (to limit the amount of CPU utilization that any single client does).

We will continue to evaluate how we can evolve this as time goes on.

1 Like

I am back testing some recordings, and I found another file that crashes the player only when HLS is enabled.
Here is something I found on the server while the same file is playing at basically the same section and the only difference is HLS on or off.

HLS on, excessive amount of data being sent to client, averaging over 200 Mbps:

HLS off, normal amount of data being sent to client, averaging about 3 Mbps.

Can you describe what you mean by "crashes"? Can you submit diagnostics from the app after you experience this issue?

This is normal that you will see more network usage with HLS: HLS will cache more data locally more quickly to fill up the app's local disk cache (which can speed up seeking). With HLS off, there is no local disk cache.

1 Like

The video stops playing and after a few seconds the player screen goes away and I am back to the recording selection screen.
I will submit diagnostics shortly.

@Michael_Birk his is very interesting bug.

Could you upload the file at: TV\America's Test Kitchen From Cook's Illustrated\America's Test Kitchen From Cook's Illustrated S18E25 2018-06-23 Elegant Desserts 2022-07-27-1430.mpg to:

I'd like to inspect the file and see why it is having problems.