Skip to content
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

Add configuration option to define max count of skipped fragments before throwing an error #457

Closed
rwlodkowski opened this issue Dec 10, 2015 · 5 comments

Comments

@rwlodkowski
Copy link
Contributor

In the case when hls_fragmentloadskipaftermaxretry is true and the playlist is live or very long it's desirable to get an error after a specified amount of load errors on subsequent fragments in a row. This option will allow us to reload the playlist from another source or just log an error to the user.

Current behavior is like this:

// config
hls_fragmentloadmaxretry : 1,
hls_manifestloadmaxretry : 1,
hls_fragmentloadskipaftermaxretry: true

// logs
loading playlist -> OK
loading fragment 1 -> failed
loading fragment 1 -> failed
skip fragment 1
loading fragment 2 -> failed
loading fragment 2 -> failed
skip fragment 2
loading fragment 3 -> failed
loading fragment 3 -> failed
skip fragment 3
and so on to the infinity. 
It will never raise an error even when we reach the last fragment 
on the playlist (when it's VOD)

This is also related with #368.

This is illustration of behaviour I would like to get:

// config
hls_fragmentloadmaxretry : 1,
hls_manifestloadmaxretry : 1,
hls_fragmentloadskipaftermaxretry: true,
hls_maxskippedfragments: 3

// logs
loading playlist -> OK
loading fragment 1 -> failed
loading fragment 1 -> failed
skip fragment 1
loading fragment 2 -> failed
loading fragment 2 -> failed
skip fragment 2
loading fragment 3 -> failed
loading fragment 3 -> failed
skip fragment 3 -> skipped fragment limit reached
loading fragment 4 -> failed
loading fragment 4 -> failed
I/O ERROR raised

In case when the next fragment after skip is successfully loaded the skip counter is reset, so it's only applicable to the cases when the errors occur in a row.

@mangui
Copy link
Owner

mangui commented Dec 11, 2015

yes that could be interesting, PR welcome

@rwlodkowski
Copy link
Contributor Author

OK, will take a look at that.

Could you tell me where exactly is the logic for that? Any advices/warnings in this case?

@rwlodkowski
Copy link
Contributor Author

Thanks @mangui

@rwlodkowski
Copy link
Contributor Author

Closed by #461

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

No branches or pull requests

2 participants