Wrong currentWindowIndex onPlayerError #5407
Comments
That's not exactly intended behaviour and for load errors specifically we should report the loading source window index. Note that the non-fatal onLoadError callbacks already have the correct window index. However, the fatal onPlayerError always gets assigned to the currently playing window index. As we can't switch to the next window if there is a load error, you still see the previous window index in onPlayerError as the "playing" one. |
|
Probably wasn't clear from my previous comment:
|
ExoPlaybackExceptions of type SOURCE are always associated with the loading period and thus we can use the event time for the loading period in onPlayerError. Renderer and unexpected exceptions are still associated with the currently playing period. Issue:#5407 PiperOrigin-RevId: 230216253
ExoPlaybackExceptions of type SOURCE are always associated with the loading period and thus we can use the event time for the loading period in onPlayerError. Renderer and unexpected exceptions are still associated with the currently playing period. Issue:#5407 PiperOrigin-RevId: 230216253
|
This behavior will lead to:
|
|
Fixing it in the way you describe would require some changes in how we progress internally through the playlist. Right now, we don't change the playing source to the next item until the next source is fully prepared. I agree that this not ideal, but it requires moving around some code in our core player. And a lot of care not to break things in the process. :) I'll re-open as an enhancement, but also mark it as low priority for now for the reason given above. |
Creating a period in MaskingMediaSource may result in delayed event reporting depending on when the actual period gets created. To avoid event reporting inaccuracies, report the mediaPeriodCreated and mediaPeriodReleased events directly. Issue:#5407 PiperOrigin-RevId: 259737170
We keep track of the last publicly known playing period to report it as part of events happening after the period has been released. In cases where a period briefly becomes the playing one and is released immediately afterwards, we currently don't save it as the "last known playing one". Improve that by saving an explicit reference. Issue:#5407 PiperOrigin-RevId: 259737218
|
We fixed this issue with the two commits below. |
This solves various issues around event association for buffering and
error throwing around period discontinuities.
The main changes are:
- Logic around being "ready" at the end of a period no longer checks if the
next period is prepared.
- Advancing the playing period no longer checks if the next one is prepared.
- Prepare errors are always thrown for the playing period.
This changes the semantics and assumptions about the "playing" period:
1. The playing period can no longer assumed to be prepared.
2. We no longer have a case where the queue is non-empty and the playing or
reading periods are unassigned (=null).
Most other code changes ensure that these changed assumptions are handled.
Issue:#5407
PiperOrigin-RevId: 263776304
The error is closely related to the playback state IDLE and should be updated in sync with the state to prevent unexpected event ordering and/or keeping the error after re-preparation. Issue:#5407 PiperOrigin-RevId: 265014630
Issue description & Reproduction steps
When using
ConcatenatingMediaSourceto play a playlist of media, let say I'm playing at positioni, and positioni + 1failed to load. Then withinonPlayerErrorcallback, I expectcurrentWindowIndexshould returni + 1but actually it returni. Is it intended behavior?Version of ExoPlayer being used
2.9.3The text was updated successfully, but these errors were encountered: