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

Immediately seeking while content is loading causes player to stall. #136

Closed
sanbornhilland opened this issue Jul 23, 2015 · 3 comments
Closed
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@sanbornhilland
Copy link
Contributor

  1. In the sample app, set playbackStartTime to 25 (somewhere mid video)
  2. Load content
  3. While content starts loading the progress indicator will move to 25. Immediately seek back to a previous position by clicking on the bar.
  4. Content will continue to buffer from 25 instead of playing from the seeked location. Playback won't begin from the seeked position even after toggling play/pause. Playback will only start if you seek back into the buffered range.
@tdrews tdrews added the type: bug Something isn't working correctly label Jul 23, 2015
@tdrews tdrews self-assigned this Jul 24, 2015
@tdrews
Copy link
Contributor

tdrews commented Jul 24, 2015

Yep, I see the problem: we aren't handling seek events until the initial buffering is done. This is a tricky one, but I have a fix in mind.

@dougdoe
Copy link

dougdoe commented Jul 29, 2015

@tdrews Is it possible to plan to include your [potential] fix in v1.5.0?

@tdrews tdrews added this to the v1.5.0 milestone Jul 29, 2015
@tdrews
Copy link
Contributor

tdrews commented Jul 29, 2015

A fix for this issue is nearly ready and will be included in v1.5.0.

@tdrews tdrews closed this as completed in 263ea99 Aug 3, 2015
tdrews pushed a commit that referenced this issue Aug 4, 2015
* Instead of intercepting specific 'seeking' events to forego stream
  resync, record the particular seeks using a member variable, which is
  less error prone.
* Don't rely on 'playing' events for stream resync after pause/play:
  'playing' events aren't reliable; instead, just check if we need to
  clamp the playhead when we update the seek range.
* Don't fire seeking events when starting the video at t=0, or when
  there is no timestamp correction.

Closes #132
Closes #136

Change-Id: I350ee6e9966af9f44d3e8bda4dc8297271e41855
@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: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

5 participants