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.
@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.