-
Notifications
You must be signed in to change notification settings - Fork 6k
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
NPE in ExtractorMediaSource, reproduced by quickly prepare and release the MediaSource #1914
Comments
If it's possible to provide an easy way to reproduce this as source (e.g. a patch for the demo app, or a link to some other open source demo app that reproduces the issue) that would be great. The only way I can see this happening is if the ExtractorMediaSource has been released whilst one of its child ExtractorMediaPeriods has not, and I can't see an obvious way that can happen. |
I have the same issue in my app. Sadly, i dont know how to reproduce it, as it only happens on my users systems, never on mine. I am calling prepareSource() and stop() maybe multiple times on an exo player instance inside of a ViewPager. |
Which versions of ExoPlayer are you seeing this with? Unless you've shipped your app extremely recently I'd expect you to be seeing a different stack trace (even if only by the line numbers). |
2.0.0 and 2.0.2. I skipped the 2.0.1 release. I am putting daily/every-second-day builds out there. |
Could you point me to your app in Play Store? I'd be interested in trying to reproduce. Thanks! |
Sadly, it is not in the play store - but you can find the repository here: https://github.com/mopsalarm/Pr0/tree/1.111.4 The ExoPlayer is wrapped here https://github.com/mopsalarm/Pr0/blob/1.111.4/app/src/main/java/com/pr0gramm/app/ui/views/viewer/video/ExoVideoPlayer.java |
@mopsalarm - I checked out master and switched the dependency back to vanilla ExoPlayer. Should that be sufficient to get the app into a state where it might reproduce the issue (albeit that reproducing might be difficult). Do you know in which fragment the issue occurs, and what browsing steps I'd need to take to get to that fragment in the app? If not, that might be something you could usefully log in future releases, if you fancy helping to chase this down. |
Actually, it reproduces relatively easily (e.g. within 5 minutes or so) if you unleash the monkey on your app, like:
(repeat until crash occurs). |
@ojw28 I notice that in |
playingPeriodHolder can be null in the case that the first period is still being prepared. We need to make sure we release the period that's being prepared in such cases, which is loadingPeriodHolder. Issue: #1914 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=135793472
nice 👍 |
In short, here is my stacktrace:
It happens when I have a list or video (RecyclerView), and scroll quickly through them (when a ViewHolder is attached to Window, it will prepare the Video with "playWhenReady = false").
Source code is from my library, so have no idea if it is OK to show it here. But let me know.
The text was updated successfully, but these errors were encountered: