Indicate fatal errors

[Ross-cz]

We aim to display a filtered group of errors to the user - only those fatal ones describing the reason for his/her inability to start or continue watching the content. We tried to utilize the error codes provided by Shaka, however, we realized that with the way the error events are currently handled, we wouldn't be able to achieve that perfectly.

1. For example, should some network disruption occur, Shaka throws a network error caused by, say, an unavailable segment at that moment, but it might recover the stream later, because it is still trying to access the segment not adhering to the amount of retries from the player configuration after which the error message itself is triggered.
   Nevertheless, in our scenario the error would be already displayed to the user, although the playback continues once the stream recovers, because there is still enough data in the buffer, so no actual problem occurs from user's standpoint.
2. Taking the situation from the above point as an example, there is no difference in error severity, possibly recoverable and non-fatal errors are on the same level as for example a malformed mpd manifest.

We would like to have better control over error processing, what approach should we take to display the errors at the very moment the user is affected, e.g. the exact moment the playback stalls? What means are there to handle HTTP status codes directly so that we can for instance influence the number of these status code-based errors possibly displayed to the user during a given time period?
Could all the errors themselves propagate an additional severity flag and possibly adapt the severity value depending on the situation with regards to the state of the playback?
Could we have error recover methods available? E.g. recover from not downloaded segment, new DRM key available, subtitles available with a different url.

[joeyparrish]

Let me see if I understand you correctly. Some errors are non-fatal, such as HTTP errors, while some are fatal, such as a malformed manifest. You'd like to know which ones are fatal and which ones aren't, so you can avoid showing the user errors they don't care about. Is that accurate? Did I miss anything important?

[Ross-cz]

Thank you for your comment Joey.

Yes, but this is only part of the issue. Let's apply that on the shaka
player UX. When user loses temporary connection, or traffic is bad, he
get's immediate error during playback. When I change the settings for error
repeat, e.g. to unlimited, the user just get rotating wheel, but it should
not rotate for ages. In cases, when there are bufferred data available
during playback I would expect to get non-fatal error flag and in case of
buffer miss fatal error flag. Error code could be same.

Is it possible to use easily current shaka API / MediaElement API for fatal
tracking? How to recover from error states (after depleted retries)? Could
we have separated TextTrack retries settings?

I'm sorry for unclear description.

-ross

On Thu, Nov 10, 2016 at 12:18 AM, Joey Parrish [email protected]
wrote:

Let me see if I understand you correctly. Some errors are non-fatal, such
as HTTP errors, while some are fatal, such as a malformed manifest. You'd
like to know which ones are fatal and which ones aren't, so you can avoid
showing the user errors they don't care about. Is that accurate? Did I miss
anything important?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#564 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA64wku_ntZKAsOWcqinL4xvQt6LdZsQks5q8lTFgaJpZM4KcCxG
.

[yairans]

I agree. It's very important to know which error is fatal and which isn't.

[sanbornhilland]

I did not realize this was open when I opened #598. #598 duplicates this issue but this is a much better explanation of what we are looking for so that issue can be closed if you want.

[joeyparrish]

I've renamed the issue to "indicate fatal errors". I think it's very reasonable to add this to shaka.util.Error in our next release.