@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?
1 Like
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...
2 Likes
My Client is Firestick 4K Max ... no stuttering at all... over WFI.
Watching ch8.1 from 10.0.0.42 (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.
You may notice the actual server buffer times are much larger than the server setting, depending on the resolution of the channel source. On my server TVE channels create a server buffer that is double the actual setting.
Just finished my test. The Streaming Directory with the Remux for an OTA HD Station (CBS) got to just under 13 gigs. After 4 hours, it started deleting the early .ts files and when I ended the stream the whole thing deleted instantly. Very clean and easy!
It did seem to be a few minutes short of 4 hours (maybe like 3-4 minutes), but based upon what @Michael_Birk said about smaller size streams of TVE being able to have double length, having a slightly oversized OTA stream be less would make sense. Assuming there might be some size-based calculation going on for average size. Anyone have a supersized ATSC 3.0 stream they could test with this?
The only bug I actually encountered was after the 4-hour mark. Once it started deleting the older .ts files, if I rewound past the new "beginning" it would loop around to the "live end". This did not happen during the initial four hours; if I went past it would just jump to the "beginning" as expected.
@maddox, @eric, submitted diagnostic logs from the TS4K+: 74b12d9d-86b3-4fbe-88b8-2059a46a9da1
Been using the beta HLS option for several weeks, mostly on my Firestick TV 4k Max device.
-
Observation: My server is not able to create 3600 files for the server buffer in one hour, depending on the source channel. When my server is setup for a one hour buffer, I actually get about a two hour buffer for most of my TVE channels. This is not a problem for me, but just didn't know if it was expected.
-
Problem: After the Firestick client buffer has filled in about 30 minutes and the server buffer is being utilized, I get a gap in the data right before the beginning of the client buffer. The client is not able to fill with server buffer data for anywhere from 1 to 15 minutes. I can see on the server that data is not being sent to the client during this gap. It happens almost every time when I sweep the timeline bar using the FireTV device, but I have never been able to duplicate it using a Google device. I have a small video showing the problem, but I don't see any way to attach it.
We aren't able to actually tell the underlying encoder the exact amount of buffer we want in time, only in number of segments. Because our estimation for the number of seconds-per-keyframe is not always accurate, it can cause situations like this. It doesn't feel to us like it's a big issue, but it's true it can be confusing.
Please upload it here: Dropbox - Submit files
Yes, not a problem for me. Just concerned my server may be having a performance issue, that may cause problems using HLS at some point.
I did send you my file showing the problem I am having. Hopefully it is not a FireTV OS issue that can not be easily resolved. I really like the HLS server buffer and I don't mind that it takes a couple of more seconds to start a live channel.
So to my question above, does that mean if a source has more data, like ATSC 3.0, will the time it can buffer be less than the setting by a noticeable amount?
It will always be more than or equal to your setting
That is very strange! The next time you reproduce this behavior could you submit diagnostics from the app and I can see what's going on in the logs?
Diagnostics sent at around 5:15. Reproduced problem on two Firesticks Max. Every time I watch a channel for more than the 30 minute client buffer, I can find a spot on the timeline bar where the server buffer doesn't send data to the client and it just skips that section. I can watch the data stream on the server and it does not send data during that 1 to 15 minute gap. This gap moves as the client buffer fills with new data.
@Michael_Birk It looks like you sent the diagnostics from the DVR. Could you send it from the app after it happens?
Please go to Settings -> Support -> Submit Diagnostic Logs from your device and let us know when it's been submitted.