EvaluateMediaItemTransition throwing unhandled exception during player initialization

[soldierinwhite]

We are receiving crash reports in around .5% of users, but the behaviour seems to be unpredictable and we have only been able to reproduce the issue once during player initialization.

Here is the crash report:

Fatal Exception: java.lang.IllegalStateException
       at com.google.android.exoplayer2.ExoPlayerImpl.evaluateMediaItemTransitionReason(ExoPlayerImpl.java:1004)
       at com.google.android.exoplayer2.ExoPlayerImpl.updatePlaybackInfo(ExoPlayerImpl.java:940)
       at com.google.android.exoplayer2.ExoPlayerImpl.handlePlaybackInfo(ExoPlayerImpl.java:918)
       at com.google.android.exoplayer2.ExoPlayerImpl.lambda$new$0(ExoPlayerImpl.java:162)
       at com.google.android.exoplayer2.-$$Lambda$ExoPlayerImpl$c3953g1V6xPbTIQ95lEUPxO10qU.run(-.java:4)
       at android.os.Handler.handleCallback(Handler.java:873)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loop(Looper.java:214)
       at android.app.ActivityThread.main(ActivityThread.java:7156)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:494)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:975)`

It seems like the playbackInfoUpdateListener is initialized without any input from the client app, and the postionDiscontinuityReason does not seem like the client app has any control over. In which scenario is this possible?

Exoplayer version: 2.12.2 Android version: 4-11 Android device: So far Samsung 66%, Lenovo 17% and Huawei 17%, but we suspect it relates to any device, app with new version of exoplayer has only been live a few days.

[mik0git]

Grüezi @marcbaechinger / Hi everyone

We are seeing the same issue poisoning our Google play console stats since end of January. Android version : 7-11 Android device split : Widespread of Vendors like top devices from Huawei and Samsung , no particular SoC affected. We are using the Bitmovin player SDK. What about you @soldierinwhite ?

java.lang.IllegalStateException: at com.google.android.exoplayer2.ExoPlayerImpl.evaluateMediaItemTransitionReason (ExoPlayerImpl.java:1008) at com.google.android.exoplayer2.ExoPlayerImpl.updatePlaybackInfo (ExoPlayerImpl.java:944) at com.google.android.exoplayer2.ExoPlayerImpl.handlePlaybackInfo (ExoPlayerImpl.java:922) at com.google.android.exoplayer2.ExoPlayerImpl.lambda$null$0$ExoPlayerImpl (ExoPlayerImpl.java:162) at com.google.android.exoplayer2.-$$Lambda$ExoPlayerImpl$NHwZyjpPwXD8cWW2qk-JZjwrfEQ.run (Unknown Source:4) at android.os.Handler.handleCallback (Handler.java:808) at android.os.Handler.dispatchMessage (Handler.java:101) at android.os.Looper.loop (Looper.java:166) at android.app.ActivityThread.main (ActivityThread.java:7529) at java.lang.reflect.Method.invoke (Native Method) at com.android.internal.os.Zygote$MethodAndArgsCaller.run (Zygote.java:245) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:921)

How can we help with this issue ?

[marcbaechinger]

Thanks for confirming you are seeing the same issue. I assume you don't have more information than the stack trace as you are seeing this on Play only? Would be great to be able to repro this.

The stack trace tells that the current windowUid has changed without being caused by an position discontinuity or a timeline change. As the assertion on line 1008/1006 tells, It's a bit unclear how this can happen.

Do you interact with the player from the main thread only, or does your app have any other threads started that call methods of the player? Is the app starting other threads at all besides the main thread?

[souissihaythem]

I got the same issue:

java.lang.IllegalStateException: at com.google.android.exoplayer2.ExoPlayerImpl.evaluateMediaItemTransitionReason (ExoPlayerImpl.java:1008) at com.google.android.exoplayer2.ExoPlayerImpl.updatePlaybackInfo (ExoPlayerImpl.java:944) at com.google.android.exoplayer2.ExoPlayerImpl.handlePlaybackInfo (ExoPlayerImpl.java:922) at com.google.android.exoplayer2.ExoPlayerImpl.lambda$null$0$ExoPlayerImpl (ExoPlayerImpl.java:162) at com.google.android.exoplayer2.-$$Lambda$ExoPlayerImpl$NHwZyjpPwXD8cWW2qk-JZjwrfEQ.run (Unknown Source:4) at android.os.Handler.handleCallback (Handler.java:888) at android.os.Handler.dispatchMessage (Handler.java:100) at android.os.Looper.loop (Looper.java:213) at android.app.ActivityThread.main (ActivityThread.java:8178) at java.lang.reflect.Method.invoke (Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:513) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1101)

And this did happen more than 500 times in my application in Googleplay. Can you please share with us how we can fix it? or if you delivered a version that fix the problem?

[marcbaechinger]

Any way to reproduce the problem is highly appreciated. So if you know when this happens like when preparing the player with media sources the first time, when stop/release is called or similar.

Are you using multiple threads in your application? Did you ever see a warning Player is accessed on the wrong thread in your logs?

I was also wondering whether you are using a playlist with multiple items or a ConcatenatingMediaSource to further rule out in what situation that happens.

[mik0git]

Thanks @marcbaechinger, we don't have duplication scenario yet, WIP. We will investigate your suggestions about Multiple Theads and will report back by end of the week.

[anthonylawson]

We were seeing this very crash in our apps and we did find a few locations where the ExoPlayer was being accessed on the wrong thread. Fixing those issues resolved this crash from occurring.

[mik0git]

We were seeing this very crash in our apps and we did find a few locations where the ExoPlayer was being accessed on the wrong thread. Fixing those issues resolved this crash from occurring.

Thanks for your feedback @anthonylawson , very helpful.

[google-oss-bot]

Hey @soldierinwhite. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[mik0git]

Thanks to @anthonylawson and @marcbaechinger recommandations we managed to arrange a cleaner Thread management in our code, we also downgraded our version of Bitmovin library. So everything looks good from 7-days KPI post roll-out.

[marcbaechinger]

@soldierinwhite Please let me know whether this solves the issue for you as well.

[soldierinwhite]

@marcbaechinger We are actually doing a rollback of exoplayer version as a hotfix right now, since upgrading the library was directly related to the crash happening, but good to know what the underlying issue is. We are rewriting our exoplayer integration from top to bottom right now in another branch so will keep this in mind.

Will check our logs for "Player is accessed on the wrong thread"

Any reason why this was not an issue on older versions of exoplayer, but is so now?

[marcbaechinger]

Any reason why this was not an issue on older versions of exoplayer, but is so now?

I don't know. Generally, if the player is accessed on multiple threads it can cause issues in some cases like a race condition. That's not deterministic. If it was you would see this problem more often than 0.5% of your users.

What is the version you are rolling back to? onMediaItemTransitioned was introduced with 2.12.0. So if you were using an older version, the reason is that this code did not exist then.

[soldierinwhite]

What is the version you are rolling back to? onMediaItemTransitioned was introduced with 2.12.0. So if you were using an older version, the reason is that this code did not exist then.

We are going back to 2.10.6, which was the last version we had before it crashed. But that's great info, now we can do a proper fix while the hotfix takes care of user needs for the time being.