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
evaluateMediaItemTransitionReason - IllegalStateException #10244
Comments
@marcbaechinger - Please take a look! |
Bump on this one still occurs and no idea what I can do about it. |
Yeah, not sure where this is coming from I'm afraid. We had a similar complaint in #8639 where it was resolved by reviewing the app and not calling the player from different threads. From your post I see you say you are doing this already? That's actually everything I can say with the information available as I'm also not able to repro this. How many percentage of your users are seeing this? Are all using the same app version and ExoPlayer 2.17.1 that see the crash? |
Yes every calls are on the mainthread ensured via couroutines. The only case I don't enforce is inside the listener callbacks but the player is initialized with
So from my understanding the mainLooper will be used for the listener callbacks no? Or I should ensure that the listener is applied on the wanted thread? The percentage is very small but that app is new and just starts so it's hard to properly calculate it. They are all using ExoPlayer 2.17.1. |
So even with adding the listener on the proper thread the issue still occurs. Can you please at least add a proper message to the exception for debug purpose? |
@marcbaechinger Bump on this one to be able to progress. Can you please tell me exactly what I should gather from evaluateMediaItemTransitionReason when reaching the issue so you may have necessary info to figure out the root cause? |
Interesting would be the values of the arguments of the method specifically Further the |
Thanks. For the moment I've only logged I'll try to add the others. As a test I also return And it leads to new crash that may help understand? (Those calls do happen on the proper mainthread)
Reading code it might be caused by #9889 (Well that PR may fix it not be the cause) as I do use a customshuffleorder in this app that have this issue and not in another app that does not have this issue. I'll improve the gathered logs to be sure that they are more useful, I'll soon release an update rebased on 2.18.1 to see (Waiting for a compose fix) |
Ok so was able to catch another error that confirm some issues with shuffle order. The stack trace is large due to the coroutines withContext without context switch to ensure the main thread access so only the last 5 lines are important. @marcbaechinger and ping @tonihei as he helped me build the customShuffle order. This error is mostly expected and possible due to
|
|
It's possible to reach this state when clearing playlist yes. |
A completely empty playlist shouldn't cause problems because |
No I no more use that. It's possible that this is a side effect then of my change Tolriq@e6156fd to try to identify the root cause of the first issue and not a cause then :( I hoped that the side crash would give enough clue, but I'm still pretty sure there's something wrong (or I do something wrong) with the customshuffle reason this only happens in this app. |
I can't explain how exactly, but this could potentially fix it because it ensures |
Thanks it's blocked by Play Store review team because of the new Android 13 form to fill let's hope they don't take 15 days. |
@tonihei Actually the last crash from Any other possible reason that I should try to log to analytics? The related code:
Edit1: Edit2: Actually this is something like that I'm able to repro now and the error is Exoplayer in shuffled mode with a playlist. So there's a state problem somewhere leading to that childCount not being 0 despite the stop and the clearplaylist. |
Ok so the app was published and the original issue is effectively fixed, allowing to figure out the real issue. Was triggered because of a well hidden launch in my code that trigged a small possible race between the update of the shuffle and the next addition to the playlist. Basically it sometimes reached @tonihei Don't know if this worth a check and a better error message to help to diagnose this kind of issues. If not then this issue can be closed. |
Did you reach this state purely by using |
It's my code that had the small race, but before 2.18.1 fix impossible to debug. 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 :) |
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. |
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:
Media
N/A
Bug Report
N/A
The text was updated successfully, but these errors were encountered: