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.
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.
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:
- Does the server Live Buffer restart on a channel change, or does it keep channel changes in the buffer.
- 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.
- 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.
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.
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.
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.
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.
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.