-
Notifications
You must be signed in to change notification settings - Fork 6k
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
SinglePeriodTimeline.getPeriod assertion fails when manipulating playlist #4871
Comments
I think that's a duplicate of #4634 and should no longer occur on the dev-v2 branch (and the upcoming 2.9.0 release). |
If it can help, we'd just like to point out that this happens at the time when adding the third batch. It does not happen if we do not perform that step. And it does not happen if previously we don't move tracks around.
Thanks for quick reply, BTW |
Yes, thanks for the reproduction steps. The issue was produced by changing the indices in the playlist before some events were reported which still had the old index. That totally messed up the event tracking. We prevented the whole issue from happening by switching to unique ids which are independent of the index in the playlist. |
Tried adding dev-v2-r2.9.0 locally to the project, and exception is gone. 💯 We also experienced a similar situation with following stacktrace:
Is that the same root cause, or should we open a new issue? ( |
Could be, but also maybe not. :) Do I understand it correctly that you are using a ConcatenatingMediaSource with a LoopingMediaSource of a ExtractorMediaSource? |
In that mentioned scenario, we are using a ConcatenatingMediaSource. At some point, after playlist manipulation (add/ remove/ move), we add a LoopingMediaSource. That one is built out of a regular, single MediaSource, which in turn is created through the following snippet: final RawResourceDataSource rawResourceDataSource = new RawResourceDataSource(context);
DataSource.Factory dataSourceFactory = new DataSource.Factory() {
@Override
public DataSource createDataSource() {
return rawResourceDataSource;
}
};
ExtractorMediaSource.Factory mediaSourceFactory = new ExtractorMediaSource.Factory(dataSourceFactory);
DataSpec dataSpec = new DataSpec(RawResourceDataSource.buildRawResourceUri(resourceId));
try {
rawResourceDataSource.open(dataSpec);
} catch (RawResourceDataSource.RawResourceDataSourceException e) {
e.printStackTrace();
return null;
}
MediaSource source = mediaSourceFactory.createMediaSource(rawResourceDataSource.getUri()); The loop does use an infinite loop count. |
Thanks! It seems that may still be a problem. I think this is what's happening:
Note that this is the combination of three unlikely events: 1. a doSomeWork message which sneaks in between the playlist and the timeline update, 2. a fully buffered media period exactly in this moment, 3. a situation where the player attempts to re-buffer the last period in the timeline (that's why it happens for the LoopingMediaSource). We changed the code for 2.9.0 but the problem still exists. You will most likely receive a null pointer exception now. |
Thanks for explanation, although now we got a little bit lost. Q1: With respect to the error being described in detail at the top (IndexOutOfBoundsException from SinglePeriodTimeline.getPeriod), it seems to me that 2.9.0 would solve that. Is that right? Q2: With respect to the other error scenario I mentioned afterwards (IllegalArgumentException from ExtractorMediaSource.createPeriod), is your explanation here above related to that? If so, maybe we better create a dedicated issue for that, so not to mix up things. |
Yes, sorry. The issue reported at the top is fixed in 2.9.0. |
If a source is removed from the playlist, the player may still call createPeriod for a period of the removed source as long as the new timeline hasn't been handled by the player. These events are stale and can be ignored by using a dummy media source. The stale media period will be released when the player handles the updated timeline. Issue:#4871 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214787090
If a source is removed from the playlist, the player may still call createPeriod for a period of the removed source as long as the new timeline hasn't been handled by the player. These events are stale and can be ignored by using a dummy media source. The stale media period will be released when the player handles the updated timeline. Issue:#4871 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214787090
Before filing an issue:
found at https://google.github.io/ExoPlayer/.
reproduce the issue in the ExoPlayer demo app.
specific questions. If you're asking a general Android development question,
please do so on Stack Overflow.
When reporting a bug:
Issue description
We are manipulating a playlist of local MP4 files through
ConcatenatingMediaSource
. When we perform a particular sequence of actions on the list, we incur systematically into anIndexOutOfBoundsException
whenSinglePeriodTimeline.getPeriod
checks index.We've a sample project showing the issue. To the purpose of explanation, consider tracks named as C, D, E, F, G. Every action waits for enough time to let the previous one completed.
The sequence of actions is:
There are other cases when another assertion fails, when we create a loop source after some playlist manipulation, but those are out of the current scope and we're not able yet to reproduce it systematically.
Reproduction steps
Build and run (on emulator or device) the project that will be sent by email. A few seconds after video F starts playing, app will crash with following:
We tried several constructors signatures for
ConcatenatingMediaSource
(atomic or not, different ShuffleOrder) with no luck.Link to test content
Please wait for link by email.
Version of ExoPlayer being used
'com.google.android.exoplayer:exoplayer-core:2.8.2'
'com.google.android.exoplayer:exoplayer-dash:2.8.2'
'com.google.android.exoplayer:exoplayer-ui:2.8.2'
Device(s) and version(s) of Android being used
Emulator, both Nexus 5 API 25 and Nexus 5X API 28.
A full bug report captured from the device
See bugreport-NYC-2018-09-26-13-19-45.zip here attached. There's also a logcat, just in case.
bugreport-NYC-2018-09-26-13-19-45.zip
logcat-2018-09-26-13-19-45.txt
Question is: are we doing something wrong? How to avoid this? Thanks!
The text was updated successfully, but these errors were encountered: