Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

IndexOutOfBoundsException: SimpleExoPlayer.getDuration() #3362

Closed
Khang-NT opened this issue Oct 17, 2017 · 6 comments
Closed

IndexOutOfBoundsException: SimpleExoPlayer.getDuration() #3362

Khang-NT opened this issue Oct 17, 2017 · 6 comments
Labels
bug

Comments

@Khang-NT
Copy link
Contributor

Issue description, Reproduction steps

I have no idea why and how does it happen, just receive some crash logs from my crash reporting service (affected at lest 30 users, 20 different kind of devices).
I post here to find if someone have same issue or has solution for it.

Link to test content

N/A

Version of ExoPlayer being used

r2.5.3

Device(s) and version(s) of Android being used

Variety device and version.

A full bug report captured from the device

Crash log:

java.lang.IndexOutOfBoundsException
	at com.google.android.exoplayer2.Timeline$1.getWindow(Timeline.java:522)
	at com.google.android.exoplayer2.Timeline.getWindow$28c22ef2(Timeline.java:618)
	at com.google.android.exoplayer2.Timeline.getWindow(Timeline.java:605)
	at com.google.android.exoplayer2.ExoPlayerImpl.getDuration(ExoPlayerImpl.java:313)
	at com.google.android.exoplayer2.SimpleExoPlayer.getDuration(SimpleExoPlayer.java:749)
@tonihei
Copy link
Collaborator

tonihei commented Oct 17, 2017

Can you give us some more details about the media sources you use and the point in time when this exception occurs (e.g. does it happen after a seek, or in which method do you call player.getDuration())?

@ojw28
Copy link
Contributor

ojw28 commented Oct 17, 2017

Also, how do you call prepare on the player? Are you using the one argument version, or the three argument version? If you're using the one argument version, that should be fine. If you're using the three argument version, what are you setting the arguments to? Thanks!

@Khang-NT
Copy link
Contributor Author

I didn't experience this crash on my device, so I don't know what really happen before crash.
The app is an music player, which can stream YouTube DASH audio, HLS live video, and local music on user phone. No clue to know which source user was playing.

I use HlsMediaSource for HLS video, ExtractorMediaSource for the rest, compose with ConcatenatingMediaSource and LoopingMediaSource as the only one argument to call prepare .

This error didn't happen on previous ExoPlayer version that I used: r2.4.3

@Khang-NT
Copy link
Contributor Author

It happens when I call getDuration on the event Player.EventListener.onTimelineChanged

@tonihei
Copy link
Collaborator

tonihei commented Oct 17, 2017

Thanks for the additional info. We have some ideas what might be going wrong here and are currently looking into this. We'll let you know as soon as we published a fix.

ojw28 added a commit that referenced this issue Oct 27, 2017
@ojw28
Pass prepareAcks in SourceInfo
3285851 
This makes it a bit more obvious what's going on during
preparation. In particular, it makes it clear that
MSG_SOURCE_INFO_REFRESHED arrives before MSG_TRACKS_CHANGED.

Issue: #3362

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173392080
@tonihei tonihei mentioned this issue Nov 1, 2017
Closed
ojw28 added a commit that referenced this issue Nov 1, 2017
@ojw28
Fix masking step 1
f150856 
1. Move Timeline/Manifest into PlaybackInfo
2. Don't update externally visible Timeline/Manifest during preparation
3. Ignore MSG_POSITION_DISCONTINUITY during preparation
4. Correctly set masking variables at start of preparation, and use them

Once this change goes in, PlaybackInfo will contain timeline, manifest
and position, which should always be self-consistent with one another.
The next step would then be to move a bunch of logic in ExoPlayerImpl
that derives state from timeline and position into PlaybackInfo, and
split that into its own top level class that can be easily tested to make
sure it never IndexOutOfBounds.

I think we could also replace the masking variables and instead just assign
a new PlaybackInfo to the playbackInfo variable whenever we're doing
something that requires masking. This should be possible because we no
longer update playbackInfo whenever we have pending acks. It would
require allowing PlaybackInfo to mask the window position internally when
the timeline is empty, but I think this is ok, and again is something we
could test pretty easily.

Issue: #3362

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

ojw28 commented Nov 1, 2017

Should be fixed in dev-v2.

@ojw28 ojw28 closed this as completed Nov 1, 2017
@google google locked and limited conversation to collaborators Mar 7, 2018
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ojw28 @Khang-NT @tonihei