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.

Sign up for GitHub

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

Jump to bottom

'seeked' event is being sent on playback start #132

Closed
victep opened this issue Jul 21, 2015 · 1 comment
Closed

'seeked' event is being sent on playback start #132

victep opened this issue Jul 21, 2015 · 1 comment
Labels
status: archived Archived and locked; will not be updated
Milestone
v1.5.0

Comments

@victep
Copy link

victep commented Jul 21, 2015

'seeked' event is being sent after 'timeupdate' event every time I start playback.

  1. Seek event should not be sent if position is 0.
  2. Seek event should be sent only if setPlaybackStartTime was set to >0 position
  3. Seek event should be sent BEFORE timeupdate event

Reproduced on version: 1.4.0

Thanks!
@tdrews
Copy link
Contributor

tdrews commented Jul 21, 2015

Thanks for the report. This is likely a side-effect of our "timestamp correction" mechanism. However, if the stream starts at 0 and the timestamp correction is 0 then we should be able to forego any initial seek. I'll take a look.

@tdrews tdrews self-assigned this Jul 21, 2015
@tdrews tdrews added this to the v1.5.0 milestone Jul 30, 2015
@tdrews tdrews closed this as completed in 263ea99 Aug 3, 2015
tdrews pushed a commit that referenced this issue Aug 4, 2015
Re-work seek handling during stream startup.
a82cef5 
* 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.
Assignees
No one assigned
Labels
status: archived Archived and locked; will not be updated
Projects
None yet
Milestone
v1.5.0
Development

No branches or pull requests
4 participants
@TheModMaker @tdrews @shaka-bot @victep