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

Segment Requests are not being cancelled/aborted on custom retryParameters #922

Closed
worg opened this issue Jul 10, 2017 · 7 comments
Closed
Assignees
Labels
status: archived Archived and locked; will not be updated status: unable to reproduce Issue could not be reproduced by the team
Milestone

Comments

@worg
Copy link

worg commented Jul 10, 2017

Have you read the FAQ and checked for duplicate issues:

Yes
What version of Shaka Player are you using:

2.1.4

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

Can you reproduce the issue with the latest code from master:
Not tried

Are you using the demo app or your own custom app:
Works on demo app

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

What browser and OS are you using:
Firefox/Chrome

What are the manifest and license server URIs:
(you can send the URIs to [email protected] instead, but please use GitHub and the template for the rest)

What did you do?
use this config for streaming retry parameters:

retryParameters: {
      timeout: 1000,
      maxAttempts: 6,
      baseDelay: 500,
      backoffFactor: 2,
      fuzzFactor: 0.5,
    }

What did you expect to happen?
Segment requests that take longer than 1s should be cancelled/aborted and retried 'till maxAttempts
are met.

What actually happened?
Requests aren't cancelled [on non live content] and are retried, somehow this puts the player on loop

@vhuerta
Copy link

vhuerta commented Jul 27, 2017

+1

@msol
Copy link

msol commented Jul 27, 2017

@joeyparrish Hi Joey, can u help us? Please

@migvz
Copy link

migvz commented Jul 28, 2017

+1

@joeyparrish
Copy link
Member

Hi all, I am looking into this now. I believe this issue, #762, and #937 are all one and the same. I apologize for the delay.

@joeyparrish joeyparrish self-assigned this Aug 4, 2017
@joeyparrish joeyparrish added this to the v2.2.0 milestone Aug 8, 2017
@joeyparrish joeyparrish added status: unable to reproduce Issue could not be reproduced by the team and removed needs triage labels Aug 9, 2017
@joeyparrish
Copy link
Member

When I set the timeout low (for my fast connection, this is 100ms), I definitely see requests being canceled and retried. For VOD, this eventually leads to a timeout error and no more retries. For live, the player keeps trying based on the infiniteRetriesForLiveStreams configuration.

Is the issue that requests aren't being canceled? Or that we (based on player.isLive() and configuration) may continue to try streaming? You shouldn't see infinite retries for VOD.

How are you setting your retryParameters? The retryParameters config exists separately for streaming, manifest, and drm requests. This is the correct way to set it for streaming (segment requests):

// In your own app:
player.configure({
  streaming: {
    retryParameters: { timeout: 100 }
  }
});

// In the JS console of the demo, before clicking the Load button:
debugConfig = {
  streaming: {
    retryParameters: { timeout: 100 }
  }
};

This would result in an error log of Invalid config, unrecognized key .retryParameters:

player.configure({
  retryParameters: { timeout: 100 }
});

If you are using a compiled build, you are missing those error logs.

Does any of this help?

@joeyparrish
Copy link
Member

I've also tagged you all in #960, in which I've proposed a general solution to retry behavior. Separate from this timeout issue, your feedback on my proposal would be very welcome. Thanks!

@worg
Copy link
Author

worg commented Aug 9, 2017

Thanks @joeyparrish we'll be posting our feedback there!

@worg worg closed this as completed Aug 9, 2017
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated status: unable to reproduce Issue could not be reproduced by the team
Projects
None yet
Development

No branches or pull requests

7 participants