HLS option

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.

Done, it generally has problems around the 7 minute mark. I don't see any visual clues when it plays.

I think I found out why this file has problems. All my OTA PBS stations (Dallas) are having signal transmission problems. I can see video glitches every few seconds, some worse than others. The only files that I have problems with came from PBS. I don't know why it plays without crashing when HLS is off, Anyway I don't see this as a real problem with the channels software,

HLS option is working quite well for me. Almost never see an unforced pause anymore. Nice option to add more time for the buffer storage. Although, I should probably be recording if I need more than an hour. Overall great job. This will be very nice for some of us that don't use Apple TVs at every location.

1 Like

I really appreciate you reporting this issue. With your recording I was able to identify a bug in our video index generation that didn't properly handle videos with certain signal issues.

Please update to this DVR beta build:

and then use Regenerate Video Index for any of the recordings you were having these problems on, and once that process has completed, you should be able to play those recordings with HLS without issue.

You shouldn't need to do this for any new recordings that happen after you do this DVR update.

2 Likes

Done, it works perfectly now. Thanks, I am using HLS all the time now.

2 Likes

What does this mean?

When you set the streaming setting to Original, it never is supposed to transcode., for OTA, the server does not even see the video stream (tuner sharing off). With TVE, the stream always goes through the server and out to clients. This is what I was told and understand how your software works.

HLS far as I understood, was only used when transcoding is needed, like to web browser. Not used in direct play to a client. So this forces HLS then?

This buffer setting pictured is under the Transcode section, thus only is applicable to remote streaming or web browser playback. You mention this in your statement, however, the 3rd condition, when you enable the debug option? what do you mean, where is that? in the client app? I do not see any option on my Apple TV. (edit: i was not using the test flight version, now i see 4 options under debug.) Can you explain what 'Use HLS Streaming when Efficient" does compared to the others?

Enabling this now results on full moving the live tv pause buffer to the server? Is that what this HLS streaming setting does? If so , that is not really made clear that is what this feature does.

For some servers, like a Pi, having constant read/write to the storage drive could significantly lower performance overall. But for more powerful devices, I would think would surpass the client device in performance perhaps.

I have no low performance/low storage client devices anymore to play around with this feature though.

Please read this thread fully first. I know you haven't based on the speed of your posts. The thread explains it fully. This is an ongoing project and is not being communicated in the app in any good way for a good reason. The only people that even understand what it's for are the people that have participated in this thread.

This idea is in the testing phases right now, hence why it's hidden in debug settings.

See this reply at your original posts:

1 Like

I just tried this setting in the app, and it has micro stutters ever few secs. Very short micro pauses.
Even if i pause it for a few secs, then resume.
Also, it does not seem to be releasing/stopping a stream after i change channel, the old stream is still listed under activity on the server.

Is this expected behavior for one using the Pi4 as the server?

I also tried to delete my posts in other thread as they were off topic.