Change default timeout network requests

[shineyjames123]

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

What version of Shaka Player are you using?:
2.5.0-beta
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?:
custom app

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

What browser and OS are you using?:
Chrome browser in Android

What are the manifest and license server URIs?:

What did you do?
Initiate media playback of Widevine DRM content

What did you expect to happen?
Playback should continue

What actually happened?
Playback stalled after 20 minutes into playback.

Shaka player configuration:

                streaming: {
                    bufferingGoal: 180,
                    rebufferingGoal: 12,
                    failureCallback: function(error) {
                        if (this.shaka.isLive()) this.shaka.retryStreaming();
                        if (this.paused) this.play();
                    },
                    retryParameters: {
                        timeout: 0, // timeout in ms, after which we abort; 0 means never
                        maxAttempts: 128, // the maximum number of requests before we fail
                        baseDelay: 1000, // the base delay in ms between retries
                        backoffFactor: 4, // the multiplicative backoff factor between retries
                        fuzzFactor: 0.5, // the fuzz factor to apply to each retry delay
                    }
                }
            });

[joeyparrish]

Hi @shineyjames123! It looks like you skipped a question in the form:

What are the manifest and license server URIs?:
NOTE:
You can send the URIs to shaka-player-issues@google.com instead,
but please use GitHub and the template for the rest.
A copy of the manifest text or an attached manifest will not be
enough to reproduce your issue, and we will ask you to send a
URI instead. You can copy the URI of the demo app to send us the
exact asset, licence server, and settings you have selected there.

Without this information, we can't reproduce or fix your issue. Thanks!

[joeyparrish]

Actually, I think I may see the issue in your configuration:

    timeout: 0, // timeout in ms, after which we abort; 0 means never

With a timeout of 0, a pending request will never be aborted and retried. Try changing this value.

[shineyjames123]

Thank you. Setting a timeout of 10000ms did help the player to recover from the "pending" state.

[joeyparrish]

I'm happy to help.

It occurs to me that we should probably set a default of something other than 0. Since I have never seen a segment size greater than 10s, we should probably default the timeout parameter to 30s. That is loose enough to allow people on very slow connections (1/3 the necessary bandwidth) to pause and buffer content that they can't play otherwise.

Even better would be stall detection. I'll file a separate issue about that.

[joeyparrish]

Changing the default timeout is easy, but we will need to call this out in upgrade docs and release notes for v2.5, so that nobody is surprised by the new behavior and everyone can configure the timeout back to 0 if they wish.

Proper stall detection has been filed as #1582.