Temporarily ban tracks after streaming errors

Have you read the FAQ and checked for duplicate open issues?: Yes

What version of Shaka Player are you using?: 2.4.3

Can you reproduce the issue with our latest release version?: Yes

Can you reproduce the issue with the latest code from master?: Yes

Are you using the demo app or your own custom app?: Tried on both

If custom app, can you reproduce the issue using our demo app?: Yes

What browser and OS are you using?: Chrome 68

What are the manifest and license server URIs?: Unable to share, but we can use any on the demo app to test this

What did you do? Simulated 1001, 1002 and 1003 errors by proxying and overwriting stream responses with 401s

What did you expect to happen? Similar to the native video players, example Safari’s player, I expected Shaka player to attempt to use all available tracks before giving up and erroring out unrecoverably

What actually happened? I feel like Shaka player errors out too easily. I am aware that the current streaming failure callback retries indefinitely for Live and not at all for VOD, however, it doesn’t retry with other tracks.

For example, if there is something wrong with a track with of a particular bitrate, then the player should attempt with the next most appropriate bitrate. This should be the case for both Live and VOD.

Suggestions I tried overriding the failure callback to manually selectVariantTrack and then retryStreaming. This works to switch and retry but even if the manually selected bitrate works fine, the ABR kicks in and tries again with the original failed bitrate (assuming that was the most appropriate one). Disabling the ABR doesn’t make sense since the ABR could still potentially have 6-7 tracks to play with besides the failed one. Instead the ABR should remove tracks that have retried and failed a certain number of times (can be defined in the streaming or abr configuration) and only if it has tried and failed all the different tracks should it then throw some sort of unrecoverable error so that the player can surface up an error message to the user.

Please 😃 This is something I need quite urgently, if it is something that needs time, in the meantime can we add something to the abr configuration to ignore tracks with certain bitrates? So that when a bitrate fails consistently, we can update the configuration to tell the abr to ignore it for that session. (Atm we only have the option to set a max and min bitrate)

Thanks again for everything Shaka has helped us with!

[joeyparrish]

Okay, that sounds reasonable. It will go onto the backlog for now, since our current milestones are very full. I will also change the issue name to reflect the plan. Thanks!

[KarlGallagher]

@joeyparrish The Google ExoPlayer for Android implements similar behaviour. In the event of a 404 error it will retry on the same fragment for a fixed retry count. Once retries are exhausted it will move down to the next bitrate and so on. ExoPlayer temporarily blacklists any representation that causes a the max retries to be exceeded (excluding the lowest bitrate representation), to avoid the ABR trying to select bitrates that are currently experiencing errors.