fix: Stop treating ffmpeg's HLS segment-end EOF as an upstream failure#55
Merged
sparkison merged 1 commit intoMay 5, 2026
Merged
Conversation
ffmpeg 8.1 (linuxserver/ffmpeg:latest as of May 2026) writes "Error reading HTTP response: End of file" to stderr at the end of every HLS segment fetch — the HTTP layer closes when the segment body is exhausted and -reconnect 1 silently reopens the connection for the next segment. ffmpeg 8.0.1 didn't surface this; 8.1 does, and it tripped the existing "end of file" entry in input_error_patterns, causing the proxy to fail over every ~10 seconds during normal playback of any HLS source. Drop the bare "end of file" string. Real upstream loss is still caught by: - the more specific input patterns (connection refused, server returned 4xx/5xx, error opening input, etc. — emitted when reconnect actually fails) - the low-bitrate / silence detectors in stream_manager.py, which trigger on actual data starvation regardless of stderr. Also: extract write/input pattern lists to module-level tuples so they can be referenced by tests and don't get rebuilt per stderr-reader call.
5 tasks
Member
|
Thank you! Good catch on this one 🙏 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
linuxserver/ffmpeg:latestrecently ticked from 8.0.1 to 8.1, and 8.1 surfaces a new stderr line on every HLS segment fetch end:[http @ 0x...] Error reading HTTP response: End of file. The HTTP layer just closes when the segment body is exhausted, and-reconnect 1 -reconnect_streamed 1silently reopens the connection for the next segment — i.e. it's normal traffic, not a failure.But the existing
input_error_patternsinpooled_stream_manager.pyhad a bare"end of file"entry, so this line started flippingstatus = "input_failed"once per HLS segment (~every 10 seconds), causing the streaming generator to trigger failover and the player to constantly reconnect. ffmpeg 8.0.1 didn't expose this log, which is why the issue only emerged with the latest base image.What changed
"end of file"from the input error patterns. Real upstream loss is still caught by:connection refused,server returned 4xx/5xx,error opening input,connection timed out,invalid data found, etc. — emitted when ffmpeg's reconnect actually fails)stream_manager.py, which trigger on actual data starvation regardless of stderr_FFMPEG_WRITE_ERROR_PATTERNS,_FFMPEG_INPUT_ERROR_PATTERNS) so they can be referenced from tests and don't get rebuilt per stderr-reader callTest plan
tests/test_failover.py::TestFFmpegErrorPatterns)[http @ ...] Error reading HTTP response: End of fileline on stderr does not flip status toinput_failedCompatibility
The patch is purely subtractive and has no public-API impact. Older ffmpeg versions that don't print this line are unaffected. The remaining patterns cover the same set of genuine input failures they always did.