You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cloud upload node already has logic to avoid this:
Snapshot manifests and playlists
Upload all segments, but no manifests or playlists
Upload snapshots of manifests and playlists
This is meant to make sure we never upload a manifest or playlist which refers to a segment that isn't fully available yet. It doesn't seem to work well enough, though.
It's possible that there's some additional latency between uploading a segment and it being available, and that manifest/playlist uploads might need to be delayed. But that would certainly be in conflict with future low-latency streaming work. It also makes me wonder why the playlists aren't subject to the same latency.
I haven't carefully measured the final segments of the playlists on upload by Streamer & download by Player, so it's possible I'm making some bad assumptions about this issue. A more detailed investigation is needed.
The text was updated successfully, but these errors were encountered:
joeyparrish
changed the title
Cloud upload race condition or latency issue?
Replace gsutil-based CloudNode with local authentication proxies and HTTP output support
Sep 8, 2021
Our Shaka Player History live stream is having an issue during playback in which we get HTTP 403 errors close to the live edge.
The cloud upload node already has logic to avoid this:
This is meant to make sure we never upload a manifest or playlist which refers to a segment that isn't fully available yet. It doesn't seem to work well enough, though.
It's possible that there's some additional latency between uploading a segment and it being available, and that manifest/playlist uploads might need to be delayed. But that would certainly be in conflict with future low-latency streaming work. It also makes me wonder why the playlists aren't subject to the same latency.
I haven't carefully measured the final segments of the playlists on upload by Streamer & download by Player, so it's possible I'm making some bad assumptions about this issue. A more detailed investigation is needed.
The text was updated successfully, but these errors were encountered: