Thanks eric, will submit when it happens again.
Will submitting diagnostics from the dvr be enough, or would you also need the debug recording log?
You can try submitting the diagnostics and if it doesn't go back far enough, I may need the recording log.
1 Like
Happened 4 times on the same stream in the last 1.5 hrs
2022/08/26 14:08:51.574243 [ERR] Error during stream
2022/08/26 14:11:12.096309 [ERR] Error during stream
2022/08/26 14:25:41.435755 [ERR] Error during stream
2022/08/26 15:19:26.493769 [ERR] Error during stream
Logs have been submitted as 9a26d674-1def-4c81-9056-55ed08f01626
The recordings have gaps missing that correspond to the statistics highest PTS seen
29 to 78 second gaps.
highest_pts=500.011911 Jump in base apts from 499.79964 (8:19) to 530.62872 (8:50), delta=30.82908
highest_pts=592.838289 Jump in base apts from 592.62240 (9:52) to 670.93982 (11:10), delta=78.31743
highest_pts=1493.165400 Jump in base apts from 1492.97743 (24:52) to 1540.47118 (25:40), delta=47.49375
highest_pts=1136.014267 Jump in base apts from 1135.79964 (18:55) to 1165.49963 (19:25), delta=29.69998
It looks like the diagnostics didn't include it, so if you could upload it, it would help:
Uploaded both recordings debug recording logs under name chDVRuser
5096-recording.log and 5097-recording.log
Interesting. Starting at 2022-08-26T15:18:52.4696218-07:00 the refetches of the playlist were returning now new segments, and then at 2022-08-26T15:19:26.493500795-07:00 it finally jumped to the new set of segments at the higher playlist.
There's really nothing we could do here to compensate for a big gap in the playlist beyond what we're doing: fail and let the recorder retry.
Either this is an issue with hlstube caching a playlist instead of fetching from YouTube, or there's something in YouTube that is not sending more data.
Thanks for looking into it.
I've been using VLC to record from the same hlstube url and no problems with it.
I set VLC to both display and record to an mpeg-ts file at the same time. But that requires manually starting and stopping it.
Still working on the vlc commandline recording so I can automate it with tasks. Getting close but need to workaround the --run-time=3600 issue not recording for an hour.
I'm still going to try and keep using Channels DVR for the recordings since it records about 50% without issues so far in the week I've been trying it. At least until I can get the vlc commandline version working.
1 Like
What does that mean. the higher playlist?
According to the RFC:
Each segment in a Media Playlist has a unique integer Media Sequence Number. The Media Sequence Number of the first segment in the Media Playlist is either 0 or declared in the Playlist (Section 4.3.3.2). The Media Sequence Number of every other segment is equal to the Media Sequence Number of the segment that precedes it plus one.
Each Media Segment MUST carry the continuation of the encoded bitstream from the end of the segment with the previous Media Sequence Number, where values in a series such as timestamps and Continuity Counters MUST continue uninterrupted. The only exceptions are the first Media Segment ever to appear in a Media Playlist and Media Segments that are explicitly signaled as discontinuities (Section 4.3.2.3). Unmarked media discontinuities can trigger playback errors.
It means if we see a big jump in sequence numbers between the different times we pull the playlist, we don't have a good solution for what we should be doing.
I'm not sure what VLC does in this case, maybe it's silently skipping the missed video, but I'm not sure — that still isn't a good experience to have silent skips in the content.
Thanks for the RFC ref.
Yah, I don't know what VLC is doing, only that it works differently than Channels DVR.
I get dizzy looking at the debug level log output from VLC!
Just as dizzy as I get looking at detailed verbose help for vlc or ffmpeg commandline parameters!
I'll just keep using Channels DVR to get the 50% uninterrupted recordings until I figure out the vlc commandline issue (it worked for me years and versions ago). And meanwhile record the channel with VLC manually.
Channels DVR just recorded another one hour segment from the same source with no issues.
No, it somehow keeps it all contiguos, no gaps.
Im glad you said that because if Channels DVR were to cover up those gaps by rewriting timestamps, I would be pissed and let you know it. Give me the garbage you received so I know you received it instead of trying to cover it up to look good!
I can use your dvr log and the comskip log to find where interruptions are and decide if I want to keep the recording or not. I've had some recordings interrupted during commercials and kept them.
Haven't seen the error again since I reported it a week ago, but that was running v2022.08.24.2311
1 Like
I don't believe there's anything related to the DVR that would have changed the situation there — my best guess is you were running into some strange issues on the YouTube side that have cleared up.
1 Like
The only 'new' problem I've had recently....
Error during live stream for ch6089 WETV: Transcoder Reset: Playlist skipped to a higher sequence (1432630 -> 1432633)
Was recording a 'Binge-A-Thon' yesterday, and 3 recordings were Interrupted with this type of error. It doesn't seem to be targeted to any specific channel or source (Have seen it on both Philo and Pluto).
1 Like
See discussion of issue here
Yes, I saw that other thread on 'skipping to a higher sequence'. My only addition is that it seems to be a recent introduction and it's occurring across multiple sources.
What sources. TVE and Pluto?
Yes....TVE-Philo and Pluto....
Just got the same error on BBC America twice today. I thought it might be an issue with not having updated in almost 2 weeks so after I saw it the first time, I updated my raspberry pi doing a full upgrade, then updated the DVR to the latest pre-release and got it again. Is it an issue with the channel? Or is it a DVR issue?
1 Like
Figured it out.
Working on Windows.
--run-time=3600 records for an hour (3600 seconds) then vlc://quit closes VLC when it's done recording
"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --network-caching=1000 --sout="#duplicate{dst=display,dst=std{access=file,mux=ts,dst='V:\VLC\VLCrecording.ts'}}" "https://kister.net/mpl/yt2m3u8?w=@twit&r=720p" --run-time=3600 vlc://quit