fragLoadPolicy is not followed if level has 2+ gaps fragments in a row #6682
Comments
zalishchuk
added
Bug
Needs Triage
github-project-automation
bot
moved this to Top priorities
in HLS.js Release Planning and Backlog
robwalch
added
GAP segments
So you want to run through all retries for FRAG_LOAD_ERROR until fatal then mark the fragment as a gap and restart loading? While you can call startLoad after a fatal error, fatal means fatal. You blew it. You should not use that player any more. I would suggest configuring HLS.js with a much higher retry count than the default of 6, and then in your application add a gap after the number of retries you want before treating it as a gap (something reasonable like 3). |
Have you tried running the app against v1.6.0-beta.2 or latest dev? |
|
@robwalch I apologize for being a bit out of the loop since this issue happened a while ago, but I still consider it a backlog item for myself. I've done some testing with Test Cases:Note When a fragment is checked, it means it’s available. If unchecked, though, it indicates that the fragment isn’t currently accessible due to a 500 Server Error. 1. Unavailable Adjacent Fragments
The result here is that fragment
2. Unavailable Every Other Fragment
In this case, HLS.js will apply retry policies to any unavailable fragments, which perfectly aligns with my goal. A certain variable, likely the Level Fragment Errors count, appears to get reset only after a successful fragment load.
My Hls.js Config: {
fragLoadPolicy: {
default: {
maxTimeToFirstByteMs: 10000,
maxLoadTimeMs: 120000,
timeoutRetry: {
maxNumRetry: 4,
retryDelayMs: 0,
maxRetryDelayMs: 0,
},
errorRetry: {
maxNumRetry: 3,
retryDelayMs: 1000,
maxRetryDelayMs: 8000,
},
},
},
}Would it be possible to apply the same approach to the nearby fragments? This would completely address my question, and the best part is that there’s no need for any custom code! Everything is running smoothly now, and HLS.js handles seamlessly skipping over any failed fragments. I still find myself grappling with the issue of how HLS.js tends to panic and overlook retry policies when searching for the next fragment after fragment error. |
Level error counts are there so that an alternate will be selected rather than retrying all fragments multiple times for the entire playlist. I suppose if you restart loading after a fatal error, then that count should be reset so that retries honor the retry count again. |
What version of Hls.js are you using?
v1.5.15
What browser (including version) are you using?
Chrome 128.0.6613.114 (Official Build), (arm64)
What OS (including version) are you using?
macOS Sonoma 14.6.1
Test stream
Provided in demo GitHub repository
Configuration
Additional player setup steps
I simplified the demo, but the thing I am trying to achieve here is to make all failed fragments "skippable", so I am trying to set them as a GAP fragment with this code:
I want to make Hls.js follow
fragLoadPolicyfor all requests it does to load fragments, so this code can work properly.Checklist
Steps to reproduce
Expected behaviour
Fragment requests after gap fragments should follow
fragLoadPolicyand make retries, then after all retries are used must pop with fatalFRAG_LOAD_ERRORWhat actually happened?
Fragment requests after gap fragments are not following
fragLoadPolicyand are not making any retries, soFRAG_LOAD_ERRORnever popsConsole output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: