-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stream.hls: Add warning when segments expire from playlist before being queued #5603
Comments
Streamlink should log error messages on failed segment requests/resposes:
HLS streams always continue despite segment errors, because it can be recovered from in most cases, even though it's a stream discontinuity. While this is bad for recording streams, it at least keeps live streams alive, which is the intention here and the main purpose of Streamlink. Recording is always an afterthought. Streamlink does only stop when the buffer timeout triggers ( So if your connection came back before the stream timeout triggered, it should've logged error messages due to failed segment requests or failed playlist reloads. This of course depends on the timeout value you've set for individual HTTP requests ( Did you change any HTTP options or the log output level? Btw, annotated stream discontinuities get logged. |
My options were
and here's the relevant log section:
So all the queued segments actually completed fine eventually (within the timeout period), there was just a period where the playlist request hung (due to my internet going out), and during that period obviously the playlist segments keep getting appended and removed, so when the request finally went through, a lot of segments were "missed". It's those "missed" segments that I'm requesting a warning about, similar to the ffmpeg one. For example, for this case, streamlink did a playlist refresh and saw a maximum segment number of |
We can add such a warning, similar to the warning of the annotated discontinuities. |
Checklist
Description
Today my internet briefly went out while using streamlink to record an HLS stream, but came back up about a minute later. When it came back, it started downloading segments again, but I was surprised to see in the log that it simply skipped from segment 143 to 174 without any kind of log message indicating any issue. I had actually thought that streamlink output a warning when things like that occurred, but I realize now I was probably thinking of ffmpeg.
ffmpeg has a warning for when this situation occurs here:
https://github.com/FFmpeg/FFmpeg/blob/c06d3d24047206f9c11bfc5849544b960e5d68eb/libavformat/hls.c#L1518-L1523
It would be nice if streamlink could output a similar warning if it encounters non-consecutive sequence numbers. This wouldn't just be useful for internet issues but also potentially as an indicator that the
--hls-playlist-reload-time
needs to be set. I have occasionally encountered misbehaving HLS producers with wildly incorrectEXT-X-TARGETDURATION
values causing segments to expire between playlist refreshes, but wouldn't necessarily have noticed any issue if I was just looking at the current log output.The text was updated successfully, but these errors were encountered: