ExoPlayer crash with IMAloader onTimelineChanged Assertions.checkArgument

[amjadmasri]

[REQUIRED] Issue description

Our app just recently released and we found in the Firebase Crashalytics an increasing number of crashes which I included below
we are using an HlsMediaSource for the content then adding the AdsMediaSourceand for the ads and
here is the code of how we are initializing the player:

ImaAdsLoader.Builder builder = new ImaAdsLoader.Builder(this);
 
imaAdsLoader=builder.setImaSdkSettings(ImaSdkFactory.getInstance().createImaSdkSettings()).buildForAdTag(Uri.parse(adVMAP));

DefaultDataSourceFactory defaultDataSourceFactory = new DefaultDataSourceFactory(this, Util.getUserAgent(this, getResources().getString(R.string.app_name)));

 MediaSource mediaSource = new 
 HlsMediaSource.Factory(defaultDataSourceFactory).createMediaSource(Uri.parse(episodeLink));

     AdsMediaSource adsMediaSource = new AdsMediaSource(mediaSource, defaultDataSourceFactory, imaAdsLoader, playerView.getOverlayFrameLayout());

     player.addListener(this);

     boolean haveStartPosition = startPosition != C.INDEX_UNSET;
     if (haveStartPosition) {
         player.seekTo(startPosition);
     }

     player.prepare(adsMediaSource,!haveStartPosition,false);
     player.setPlayWhenReady(true);

[REQUIRED] Reproduction steps

we couldn't reproduce the issue , we only see the crashes on the crashlytics console.

[REQUIRED] Link to test content

[REQUIRED] A full bug report captured from the device

Fatal Exception: java.lang.IllegalArgumentException
       at com.google.android.exoplayer2.util.Assertions.checkArgument(Assertions.java:39)
       at com.google.android.exoplayer2.ext.ima.ImaAdsLoader.onTimelineChanged(ImaAdsLoader.java:912)
       at com.google.android.exoplayer2.ExoPlayerImpl$PlaybackInfoUpdate.notifyListeners(ExoPlayerImpl.java:780)
       at com.google.android.exoplayer2.ExoPlayerImpl.updatePlaybackInfo(ExoPlayerImpl.java:717)
       at com.google.android.exoplayer2.ExoPlayerImpl.handlePlaybackInfo(ExoPlayerImpl.java:648)
       at com.google.android.exoplayer2.ExoPlayerImpl.handleEvent(ExoPlayerImpl.java:593)
       at com.google.android.exoplayer2.ExoPlayerImpl$1.handleMessage(ExoPlayerImpl.java:125)
       at android.os.Handler.dispatchMessage(Handler.java:105)
       at android.os.Looper.loop(Looper.java:156)
       at android.app.ActivityThread.main(ActivityThread.java:6577)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:986)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:876)

[REQUIRED] Version of ExoPlayer being used

2.9.4

[REQUIRED] Device(s) and version(s) of Android being used

Samsung galaxy S6
HTC Desire 820s
HUAWEI MediaPad T3 7

android 6, 7 and 8

[andrewlewis]

The failing assertion is Assertions.checkArgument(timeline.getPeriodCount() == 1);.

It looks like HlsMediaSource should always produce a single-period timeline so I wouldn't expect to see this error. However, I wonder if there's a case where the timeline can empty and this throws (there is a check for the timeline becoming empty due to resetting the player before this assertion, but maybe there is another case).

Could you confirm that you are always just playing an HlsMediaSource (and never a concatenation)?

[amjadmasri]

Thank you for replying
yes we are always playing HlsMediaSource

[ojw28]

@tonihei - Can you think of any way that this could happen (in 2.9.4, if not 2.10.0)?

My suspicion would be that there's some path somewhere that ends up calling onTimelineChanged with an empty timeline and a reason other than TIMELINE_CHANGE_REASON_RESET. I couldn't find one though. If we're unsure, perhaps we could have ImaAdsLoader.onTimelineChanged treat the empty timeline the same as TIMELINE_CHANGE_REASON_RESET?

[tonihei]

The problem seems to be caused by a Timeline update coming from the internal player with an empty Timeline, while ExoPlayerImpl has a non-empty Timeline.

The internal player sets the timeline in two places only: for updates coming from the MediaSource, or when resetting the internal state. The former can't possibly be an empty Timeline when coming from a HlsMediaSource. The latter is only called after calling prepare(..,resetState=true) or stop(reset=true).
However, in both cases, ExoPlayerImpl must already have an empty Timeline (sent with TIMELINE_CHANGE_REASON_RESET) and does not accept any other timeline until the respective command is handled. So I can't see any conceivably way in which this could happen.

@amjadmasri Do your logs contain any information on the circumstances of the error? For example app or player events happening before or at this time which would help to narrow down the cause?
Also, do you re-use your AdsMediaSource and/or your HlsMediaSource for different Player instances or in the same Player instance? Do you use Player.stop(..) at all? Do you use ExoPlayer from a different thread at any point?

@ojw28 Agree that we can make the check broader and ignore all empty timelines as a precaution.

[amjadmasri]

unfortunately we couldn't reproduce the bug, so we only have what Firebase crashalytics gives us.
we don't reuse the media sources.
I will try and give you as much information about our use case and code as possible.

we use the following code to pause and resume playback

     private void pausePlayer() {
        if(player!=null)
        player.setPlayWhenReady(false);
     }                                  
    private void startPlayer() {
        if(player!=null)
        player.setPlayWhenReady(true);
    }

pause is called on the onPause lifecycle
and start is called on the onResume lifecycle
we also show an interstitial ad so these methods gets called when the ad plays.

also the code snippet in the original question with the following code at the beginning is called to init the player

trackSelectionFactory = new AdaptiveTrackSelection.Factory();
        trackSelectorParameters = new DefaultTrackSelector.ParametersBuilder().build();

        trackSelector = new DefaultTrackSelector(trackSelectionFactory);
        trackSelector.setParameters(trackSelectorParameters);


        player = ExoPlayerFactory.newSimpleInstance(this, trackSelector);
        playerView.setPlayer(player);

on the onStart Lifecycle
and on onPlayerError if the exception type is ExoPlaybackException.TYPE_SOURCE to retry playing the content.

we don't call the Player.stop()
and we don't have any other threads.

also we have been getting reports of another bug on the Firebase Console that is related to the Timeline being null
we have forward and rewind buttons that seek the player forward 10 seconds or backwards 10 seconds and sometimes when they are clicked this crash happens

Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'com.google.android.exoplayer2.Timeline$Period com.google.android.exoplayer2.Timeline.getPeriod(int, com.google.android.exoplayer2.Timeline$Period)' on a null object reference
       at com.google.android.exoplayer2.ext.ima.ImaAdsLoader.onPositionDiscontinuity(ImaAdsLoader.java:976)
       at com.google.android.exoplayer2.ExoPlayerImpl.seekTo(ExoPlayerImpl.java:337)
       at com.google.android.exoplayer2.SimpleExoPlayer.seekTo(SimpleExoPlayer.java:935)
       at com.google.android.exoplayer2.BasePlayer.seekTo(BasePlayer.java:42)
      

[tonihei]

Thanks for all the information, I'll have a look again to see if I can find a potential source for the problem.

The other stack trace is definitely a bug, because a seek could always happen before we get the first timeline update.

[tonihei]

I still can't see a concrete reason why the original problem may have occurred, but I believe the problem may be fixed in 2.10 because we added more robustness to our listener notification system (e.g. always ensure correct order, never send updates after a listener has been removed).

The commit above also works around the problem should it still occur for some reason, so I think we can close this issue (as soon as the second problem is also fixed)