Skip to content

Conversation

@krseager
Copy link
Collaborator

This PR will allow for error-controller to defer handling of errors via HlsConfig.

Why is this Pull Request needed?

In certain cases, you may not want hls.js to raise a fatal when an error occurs OR you would like to handle an error manually. An example would be if WebVTT subtitles are in use and the player enters an adbreak (where no subtitle's exist) OR there is a CDN issue where WebVTT files are unavailable, the developer may want playback to continue rather than raising a fatal error.

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

Ensure that callback functions & documentation is clear.

Resolves issues:

N/A => I will create an issue depending on feedback to this draft PR.

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

const hls = this.hls;
// If the error is handled by onErrorHandler or is fatal, do not proceed with error recovery
if (hls.config.onErrorHandler?.(data) || data.fatal) {
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still won't stop propagation through other event listeners, nor should we attempt to make it. Adding resolved: true to data is how error handling signals that other components do not need to take any further action.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just updated the PR with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

2 participants