I'm having a bug which I think is related to prerolls/IMA, and I was able to reproduce it in the demo app.
It happens when I play a video that has a preroll, wait for the preroll to end, minimize the app by pressing the home button and then return to the app. The playback won't resume, as the player will get stuck in buffering forever.
The last exo related logs after I re-foreground the app are:
I/ExoPlayerImpl: Init 6418ba5 [ExoPlayerLib/2.11.5] [generic_x86, Android SDK built for x86, Google, 25]
D/EventLogger: seekStarted [eventTime=0.00, mediaPos=0.00, window=0]
D/EventLogger: positionDiscontinuity [eventTime=0.00, mediaPos=9.99, window=0, SEEK]
D/EventLogger: state [eventTime=0.00, mediaPos=9.99, window=0, true, BUFFERING]
D/IMASDK: Sending js message: adsManager [appForegrounding]
D/IMASDK: Sending js message: adsManager [appForegrounding]
D/IMASDK: Sending js message: adsManager [appForegrounding]
D/EventLogger: surfaceSize [eventTime=0.01, mediaPos=9.99, window=0, 1080, 607]
D/EGL_emulation: eglMakeCurrent: 0x9f385a80: ver 3 0 (tinfo 0x9f3834e0)
D/IMASDK: Sending js message: adsLoader [requestAds]
D/IMASDK: Received js message: adsLoader [adsLoaded]
In the Exoplayer demo app, go to the "IMA sample ad tags" section and pick an option that has a preroll (for example: "VMAP pre-roll").
Wait for the preroll to finish, and then press the home button to minimize the app.
Reopen the app.
Player will get stuck in the buffering state forever.
This started happening in version 2.11.5.
I am using Android Emulators API 25, and a Samsung Galaxy S20. I can reproduce the issue everytime.
Thanks for reporting this. In the recent IMA SDK API changes VideoAdPlayer now has a release method that collides with ImaAdsLoader's release method, which means that when ads complete we treat the ImaAdsLoader as having been released.
@andrewlewis I know it's soon to ask, but are you able to tell if this is something that could be easily fixed, and maybe a possible ETA on when could we be seeing a release with this fix?
Just asking because we're waiting for the IMA update for months, and now that we got it this bug came with it... so it would be nice if I had any details I could share with my bosses.
I think we will do a small release to pick up 5a88e0bc1d37b8cd16f993ae51ebe17fa9358ab9 and pending fixes for this issue, #7492 and #7477. It should happen soon assuming nothing major comes up in review, but we can't commit to a specific date. I know this upgrade has taken a while and thank you for your patience so far!
Fixed in the commits referenced above. This will be part of 2.11.6, which should be released today or tomorrow.
I updated to 2.11.6 but I cannot compile my app because this method in ImaAdsLoader don't exist anymore: public void addCallback(VideoAdPlayerCallback videoAdPlayerCallback).
I scanned through the source code but I'm failing to see where I'm supposed to register my VideoAdPlayerCallback. I specifically use the onPlay and onError callbacks.
Can you point me to what should I do to receive these callbacks?
Do you think it should be fine if I replaced these callbacks with the usage of AdEvent.AdEventListener's onAdEvent(AdEvent) checking if the AdEvent's type is CONTENT_PAUSE_REQUESTED or AD_BREAK_FETCH_ERROR (for replacing VideoAdPlayerCallback's onPlay and onError, respectively)?
I moved those into an inner class which isn't visible (it wasn't really intentional to expose VideoAdPlayer in the first place, but this move was specifically to avoid the release method clashing).
Using AdEventListener may work too for CONTENT_PAUSE_REQUESTED (although I don't think you'll see that multiple times for ads in a pod), but AD_BREAK_FETCH_ERROR only notifies empty ad tags rather than actual ad playback errors.
Are you able to use the player event listener to detect the cases you need? There is some sample code to know what ad is playing based on position discontinuities in #6249. For the error case you can look for errors reported via onPlayerError (and, if needed, ad prepare errors reported via load errors with C.DATA_TYPE_AD).
Most helpful comment
I think we will do a small release to pick up 5a88e0bc1d37b8cd16f993ae51ebe17fa9358ab9 and pending fixes for this issue, #7492 and #7477. It should happen soon assuming nothing major comes up in review, but we can't commit to a specific date. I know this upgrade has taken a while and thank you for your patience so far!