HLS option

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.

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.


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


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.

@speedingcheetah I'll respond in more detail when I get a chance, but for the moment, could you please submit diagnostics from the client after you see these micro-stutters?

sure done. seems to be dropping frames at the start a bit.

If you hit Pause, wait for a second and then hit Play, does the issue resolve itself?

Ok. yes it seems to. but if i skip forward to be live, it stutters.

just updated server from 2022.08.04.1903 to 2022.08.07.1844.
Stuttering still happens.
The sever reports 1.04x or so transcode speed then drops as it get more ahead.
Starts at faster speeds, then drops to 1.01x after a time.
Speeds are near 2x when i load a SD channel, but the stuttering is worse.

I have noticed, that if i just the channel play, the stuttering stops after a minute or 2, but can not reproduce this result every time. Sometimes it stays stutter until i pause then resume.

Well, it is kind of their username...


My Client is Firestick 4K Max ... no stuttering at all... over WFI.

Watching ch8.1 from (Remux Running: 18s @ 1.18x (30.43fps)): strength=100% quality=100% symbol=100% rate=7Mb/sec

This sounds like an issue of the client not waiting for enough of a buffer before starting playback. We’ll tune this to make sure it doesn’t have that stuttering issue.

What sources are you viewing. OTA, Cable, TVE or M3U.

Most likely you will not see issues with MPEG2 video with Closed GOP's. OTA-ATSC 1.0 and Xfinity SD channels.
Most H.264 video use Open GOP's which will exhibit that unless buffered enough. Xfinity HD, TVE and most M3U channels.

@Michael_Birk, just wanted to send a quick thank you for all the testing through the rough patches you did! I just re-read the entire thread as I'm running my first 4-hour buffer test on my TS4K+. Everything is exactly as you have described it, so assuming all goes well, I see no reason not to turn this on on all my devices.