403 errors are ignored

[Ross-cz]

• What version of Shaka Player are you using?
  HEAD
• Are you using the demo app or your own custom app?
  b
  • If custom app, can you reproduce the issue using our demo app?
    n
• What did you do?

1. setup proxy
2. play content
3. during play, change proxy to return 403 on any response

• What did you expect to happen?
  There should be no download retries and severity non-recoverable.

• What actually happened?
  Retries occurred and severity was overriden to recoverable inside method handleNetworkError_.

[joeyparrish]

This should have been fixed in #620 such that there were no retries.

I'm fairly sure the severity should be "recoverable", though. In the case of a license request failure, we don't know it's fatal. If there were multiple requests that covered the same keys (which can happen with some content), the failure of an initial license request would not be fatal. In the case of a failed renewal, a later renewal could still extend the license before the keys expire. Because of these things, I'm not sure there's any way for us to confidently label such a failure as "fatal".

[joeyparrish]

We will look into the retry issue. Thanks for the report!

[Ross-cz]

Hi Joey,

thank you for detail logic explanation. I agree with you.

I just want to add that my issue was with segment request (m4s). :-) There were some unit tests, but it seems the error leaks from HttpPlugin to other layer untested (StreamingEngine - handleNetworkError_).

[joeyparrish]

Cherry-picked to v2.1.3.

[Ross-cz]

Hi, last change is too generic and doesn't support real world scenarios, when you want to have robust solution:

1. service can return 404, when it is being deployed using simple strategy, e.g. no failover or backup secondary service. I would like to have retry support for this.
2. 403 is just forbidden and 401 means challenge required - both are different and specifc. 401 means stupid configuration or missing cookie. 403 means stupid configuration or provided things expired.
3. regres VOD timeout and http error is critical too without retry.
4. handleNetworkError_ was used even for subtitles, now it is not needed anymore.

As for the infinity - this works in case of playing buffered data, but after that can you show me user, who is looking 2 mins into rotating wheel? We are fighting with every 10ms latency.. There should be really something more helpfull on the API side - more real world.
I would like to have ability to retry based on my own logic even critical network errors. This would cover all scenarios:

• stupid backend deployments especially 3rd party
• let user control, e.g. if he just closed his laptop and left video paused on some browser tab..
  I will be able to expand logic like this:
• for stupid servers I want to add user ability to report / retry using button.
• let user know, his session expired, so he needs to relogin / hit play again / buy again, because rent expired, etc.

Or if you are lazy, reload whole player at that position.. This doesn't help to server stats..

[TheModMaker]

We allow specifying retry parameters in a RetryParameters[1] object. You can specify this in the player configurations .manifest.retryParameters, .drm.retryParameters, and .streaming.retryParameters. This allows you to set the retry delay and the number of times to retry. This is separate from the given change. So if your server gives a 404, we will retry using that configuration. For example:

player.configure({
  streaming: {
    retryParameters: {
      maxAttempts: 20
    }
  }
});

Also, we still raise the error event when we handle network errors. So if we get a 401 error, you can listen to the error event and signal to the user that they need to reauthenticate.

We don't allow restarting retries after we have stopped. With the given change, we no longer retry forever for VOD, so a 403 error for VOD will stop playback. We could add a configuration to allow for infinite retries for VOD or add a call to start retrying again.