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

Questions about segment fetch behaviour which may return 404 #1133

Closed
chrisfillmore opened this issue Nov 16, 2017 · 4 comments
Closed

Questions about segment fetch behaviour which may return 404 #1133

chrisfillmore opened this issue Nov 16, 2017 · 4 comments
Labels
status: archived Archived and locked; will not be updated type: question A question from the community

Comments

@chrisfillmore
Copy link
Contributor

I've been asked by our content infrastructure team to provide some insight on Shaka's behaviour when fetching segments for a live stream. They tell me that they're seeing an unusual number of requests which return 404, under the following circumstances:

  1. Content is being requested by the client that is in the future (content does not exist on the origin server yet)
  2. Content is being requested by the client that is in the past and outside of the availability window (this is why I was asking about Refactor to derive live edge from list of segments #999)
  3. Content is being requested that is in between two valid segments (content that does not align with segment boundaries defined in the manifest)

At the moment I don't have a reproducible test case, or network logs showing the requests. As our investigation progresses I may be able to provide this. I'm hoping you can provide some insight into whether Shaka could or would make any of the above requests for segments.

We're also following up with ExoPlayer, since the issue is seen with DASH content generally. Let me know if I can provide any more information. Thanks!

@TheModMaker
Copy link
Contributor

  1. Content is being requested by the client that is in the future (content does not exist on the origin server yet)

Some DASH manifests can specify all future segments, so we don't have to wait for a manifest update to know the times and URLs for the media segments. This means that we could request a segment before the server generated it. This can happen if there are clock sync problems or if the server is slowing down.

This shouldn't cause a problem since we will wait a few seconds and retry the request.

  1. Content is being requested by the client that is in the past and outside of the availability window (this is why I was asking about Refactor to derive live edge from list of segments #999)

This can be caused by encoder drift or clock sync issues where we choose an incorrect start time. Those may be fixed by #999.

  1. Content is being requested that is in between two valid segments (content that does not align with segment boundaries defined in the manifest)

This is definitely a bug, I don't even know how this could happen. If you have a repro, please file a bug for this.

@TheModMaker TheModMaker added type: question A question from the community and removed needs triage labels Nov 20, 2017
@chrisfillmore
Copy link
Contributor Author

Thanks for the info. Regarding (3), we have an open ticket internally which alleges that you can reproduce the problem in VOD (or perhaps restarted live content) by doing a lot of scrubbing. The ticket was filed by one of our client architects who believes this is the cause of cache misses at the CDN. I've never reproduced this myself.

@joeyparrish
Copy link
Member

@chrisfillmore, have we answered your question? Is there anything else we can do for you on this?

@joeyparrish joeyparrish added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Dec 11, 2017
@chrisfillmore
Copy link
Contributor Author

Thanks @joeyparrish, I think I have the answers I need. I'll reopen if I have to follow up again.

@joeyparrish joeyparrish removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Dec 12, 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 type: question A question from the community
Projects
None yet
Development

No branches or pull requests

5 participants