evaluateMediaItemTransitionReason - IllegalStateException

ExoPlayer Version

2.17.1

Devices that reproduce the issue

There does not seem to have specific devices from Play Console crashs. Android 12/11/9 - Samsung/OnPlus/…

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

No

Reproduction steps

Don’t know 😦

The crash is not reproducible here and seems rare, all calls are properly made on the same thread.

The crash does not give any useful information about the possible causes so I have no clue what to do next.

The stack trace also does not make sense since it seems it should only called for ads and I never queue or use ads in the app, it’s music files played. What could trigger this check to be true? Some users maybe playing transcoded media in strange formats, is there something I can do to avoid false classification as ads ?

Expected result

No crash, or something that we can catch.

Actual result

Crash with:

java.lang.IllegalStateException:
  at com.google.android.exoplayer2.ExoPlayerImpl.evaluateMediaItemTransitionReason (ExoPlayerImpl.java:2089)
  at com.google.android.exoplayer2.ExoPlayerImpl.updatePlaybackInfo (ExoPlayerImpl.java:1805)
  at com.google.android.exoplayer2.ExoPlayerImpl.handlePlaybackInfo (ExoPlayerImpl.java:1774)
  at com.google.android.exoplayer2.ExoPlayerImpl.lambda$new$1 (ExoPlayerImpl.java:306)
  at androidx.profileinstaller.ProfileInstallerInitializer$$InternalSyntheticLambda$1$0f795b3312dc1da540aed76dfe7be9153bc2dd822b10dd31dcd76fb9862960b5$0.run$bridge (ProfileInstallerInitializer.java:0)
  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:7073)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:965)

Media

N/A

Bug Report

N/A

[tonihei]

I think throwing the exception already solves this issue by failing-fast as soon as we detect something doesn’t match. It’s unfortunately never easy to detect the root cause of threading race conditions, so I don’t see what else we could provide in this case. I’ll close the issue under this assumption. If you have a concrete documentation proposal for something you would have liked to read when writing your custom code, please let us know and we can add this.

[Tolriq]

It’s my code that had the small race, but before 2.18.1 fix impossible to debug. And still hard to diagnose due to the complexity of timelines and everything in playlist and gapless.

So was hoping for some easy test that could be added on ExoPlayer side to help detecting such things if possible, if not then now I know a little more how to debug those 😃