Skip to content

Do not treat HTTP status 0 frag load errors as gaps #7464

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Aug 14, 2025
Merged

Do not treat HTTP status 0 frag load errors as gaps #7464

merged 1 commit into from
Aug 14, 2025

Conversation

robwalch
Copy link
Collaborator

This PR will...

Do not treat HTTP status 0 frag load errors as gaps

Why is this Pull Request needed?

Last frag load retry should be fatal with http status 0 (offline/CORs/unknown).

Are there any points in the code the reviewer needs to double check?

Resolves issues:

Fixes #7410

Checklist

  • changes have been done against master branch, and PR does not conflict
  • new unit / functional tests have been added (whenever applicable)
  • API or design changes are documented in API.md

@robwalch robwalch added this to the 1.6.10 milestone Aug 14, 2025
@robwalch robwalch merged commit b829dd3 into master Aug 14, 2025
16 checks passed
@robwalch robwalch deleted the bugfix/offline-cors-no-alt-gap-skipping branch August 14, 2025 16:59
@Frenzie
Copy link
Contributor

Frenzie commented Aug 19, 2025

This change seems to result in some unfortunate behavior. It results in an immediate fatal error in case of an intermittent failure (like mobile on the train, but it could occur for a great many reasons), skipping the normal logic where it tries the next segment and by and large merrily proceeds with playback. I think status 0 should be treated identically to 40x or 50x.

I'm not convinced the HTTP status 0 should be treated any differently than regular 404 at all, but if we assume it should, it shouldn't do it immediately on the first failure.

The intended behavior can probably be achieved better with navigator.onLine and the offline and online events.
https://developer.mozilla.org/en-US/docs/Web/API/Window/offline_event
https://developer.mozilla.org/en-US/docs/Web/API/Window/online_event

@Frenzie
Copy link
Contributor

Frenzie commented Aug 19, 2025

The simplest way to reproduce a more or less generic network error is probably to block a specific .ts file in the network tab.

@robwalch
Copy link
Collaborator Author

robwalch commented Aug 19, 2025 •
edited
Loading

@Frenzie, please file a new issue, using "Reference in new issue" from the menu ("...") on the above comment (#7464 (comment)).

@Frenzie Frenzie mentioned this pull request Aug 20, 2025
Closed
robwalch added a commit that referenced this pull request Aug 21, 2025
@robwalch
Defer segment requests until "online" event after network error with …
9656354 
…"offline" state

Fixes #7471
Only treat no alternal segment request failures as gaps in live playlists
Follow up to #7464, #7410
@robwalch robwalch mentioned this pull request Aug 21, 2025
Merged
3 tasks
robwalch added a commit that referenced this pull request Aug 22, 2025
@robwalch
Defer segment requests when network connection is lost (#7476)
b2d7391 
* Wait to retry fragment request when `navigator.onLine` is false
(uses polling for Firefox where "online" event never fires)
Fixes #7471
* Only treat no-alternate segment request failures as gaps in live playlists (#7464, #7410)
* Retry once per seeking out of current fragment range (even when offline)
* Do not exhaust retries in tick loop while seeking
* Only schedule immediate tick on seeking when buffer is empty and state is idle (#7472)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
1.6.10
Development

Successfully merging this pull request may close these issues.

Downloads all playlist segments when offline
2 participants
@robwalch @Frenzie