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

getCurrentPosition() returning incorrect value which is larger than video duration #2224

Closed
ashiagr opened this issue Dec 19, 2016 · 4 comments
Closed

getCurrentPosition() returning incorrect value which is larger than video duration #2224

ashiagr opened this issue Dec 19, 2016 · 4 comments
Labels
bug

Comments

@ashiagr
Copy link

ashiagr commented Dec 19, 2016 •
edited
Loading

Hi

I'm running ExoPlayer r2.1.0 on Nexus 5x with Android 7.0

When I play this HLS video , the playback position displayed is very large as if its some elapsed time from a clock. Here's a screenshot: http://imgur.com/VReQ5ws. Because of this the seek bar position is not updated as current position is larger than video duration.

The issue is reproducible in the Exoplayer release-v2 branch demo app for above video. Just replace any HLS video link inside media.exolist.json with above video link.

Any ideas on why this happens and how we can eliminate it?

Thanks!
@ojw28 ojw28 added the bug label Dec 19, 2016
@ojw28
Copy link
Contributor

ojw28 commented Dec 19, 2016

This happens for on-demand content that includes EXT-X-PROGRAM-DATE-TIME tags. The sample timestamps are (possibly correctly) grounded by program-date-time in this case, but the timeline still thinks the start of the media is at timestamp 0. Hence the huge numbers. We'll take a look.

ojw28 added a commit that referenced this issue Dec 19, 2016
@ojw28
Fix large timestamps for HLS playbacks
ab88821 
- If there's no program-date-time then this change is
  a no-op.
- If there is a program-date-time this change considers
  the period as having started at the epoch rather than
  at the start of the content. The window is then set
  to start at the start of the content. This is a little
  weird, but is required so that the period sample
  timestamps match the start of the period. Note that
  this also brings the handling of on-demand in line
  with how the live case is handled, meaning there wont
  be weird changes if a live stream changes into an
  on-demand one.

Issue: #2224

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142442719
@ojw28
Copy link
Contributor

ojw28 commented Dec 19, 2016

This is fixed on the dev-v2 branch. The fix is a little. . .strange, but hopefully it'll do the trick.

@ojw28 ojw28 closed this as completed Dec 19, 2016
@ashiagr
Copy link
Author

ashiagr commented Dec 19, 2016

Great! Thanks for a quick response. Will test it out.

ojw28 added a commit that referenced this issue Dec 20, 2016
@ojw28
Fix large timestamps for HLS playbacks
f3d1065 
- If there's no program-date-time then this change is
  a no-op.
- If there is a program-date-time this change considers
  the period as having started at the epoch rather than
  at the start of the content. The window is then set
  to start at the start of the content. This is a little
  weird, but is required so that the period sample
  timestamps match the start of the period. Note that
  this also brings the handling of on-demand in line
  with how the live case is handled, meaning there wont
  be weird changes if a live stream changes into an
  on-demand one.

Issue: #2224

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142442719
@manishvwynk
Copy link

I have take the fix for it but still facing the issue .

@google google locked and limited conversation to collaborators Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ashiagr @ojw28 @manishvwynk