-
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
IMA not playing all Ads from a midroll #7477
Comments
Thanks for the report. Filed [Internal: b/159042225] to ask the IMA SDK team to take a look and advise whether this is working as intended, and if so what the cause is. |
Regarding the potential solution, I'd expect it to work as long as the final/correct ad count is known before the player buffers to the end of the last ad in the ad pod, but without understanding what's going on in more detail I'm not sure that is guaranteed. |
At the point of loading the first ad future ads in the pod may still be loading, and in general to total ad count is an estimate until the last ad in the pod loads. I think it's safe just to remove the requirement that the ad count doesn't change as it looks like we discard buffered media periods as required to support this in |
Ads can appear due to asynchronous ad tag requests completing after earlier ads in a pod have loaded, so remove the requirement that the ad count can't change. The MediaPeriodQueue should handling discarding buffered content if an ad appears before already buffered content, so I think this case is actually handled correctly by the core player already. Also remove the requirement that an ad URI can't change. This is a defensive measure for now, but it's likely that a later fix in the IMA SDK for an issue where loadAd is not called after preloading then seeking before a preloaded ad plays will result in loadAd being called more than once, and I think it's possible that the second call to loadAd may have a different URI. Because the ad URI should only change after an intermediate seek to another MediaPeriod, there shouldn't be any problems with buffered data not getting discarded. Issue: #7477 PiperOrigin-RevId: 316871371
Ads can appear due to asynchronous ad tag requests completing after earlier ads in a pod have loaded, so remove the requirement that the ad count can't change. The MediaPeriodQueue should handling discarding buffered content if an ad appears before already buffered content, so I think this case is actually handled correctly by the core player already. Also remove the requirement that an ad URI can't change. This is a defensive measure for now, but it's likely that a later fix in the IMA SDK for an issue where loadAd is not called after preloading then seeking before a preloaded ad plays will result in loadAd being called more than once, and I think it's possible that the second call to loadAd may have a different URI. Because the ad URI should only change after an intermediate seek to another MediaPeriod, there shouldn't be any problems with buffered data not getting discarded. Issue: #7477 PiperOrigin-RevId: 316871371
Fixed in the commits referenced above. This will be part of 2.11.6, which should be released today or tomorrow. |
Thanks, I can confirm this is working as intended. |
[REQUIRED] Issue description
The following IMA Ad Uri is producing an undesired behavior, in which not all Ads in the Midrolls are being played. After 2-3 Ads (out of 7 or 8) content is getting resumed.
It seems that the state hold by
AdPlaybackState
AdGroup.count
differs from whatAdPodInfo.getTotalAds()
is providing after the actual Ad sequence is loaded.[REQUIRED] Reproduction steps
Expected: All 7/8 Ads are played.
Actual: Only first 2/3 Ads are played and it continues with Content. (Depending on the Exo version)
[REQUIRED] Link to test content
https://pubads.g.doubleclick.net/gampad/ads?env=vp&gdfp_req=1&unviewed_position_start=1&output=vast&iu=/5374/TV2video/avod/programmer/underholdning/love-island-uk/sesong-5&sz=640x480&description_url=https://www.tv2.no/v/1463716&hl=no&cmsid=2510181&vid=1463716
[REQUIRED] A full bug report captured from the device
Notice the behavior/result is slightly different from 2.11.3 and 2.11.5
2.11.3 is logging some warning after the 3rd Ad is played and content playback continues
ImaAdsLoader: Unexpected ad count in LOADED, 7, expected 3
2.11.5 is logging the following exception after the 2nd Ad is played and content playback continues.
[REQUIRED] Version of ExoPlayer being used
2.11.3 & 2.11.5 (latest)
[REQUIRED] Device(s) and version(s) of Android being used
It doesn't seem to be affected by device / android version. All.
Potential solution
We have seen that if we allow to change
AdGroup.count
when the received one from the updated AdPod is greater than the one in theAdGroup
, it seems to work.In r2.11.5, on
ImaAdsLoader.loadAd
method we have included the mentioned condition.Above requires that AdGroupd.withAdCount copy method doesn't check for
count == C.LENGTH_UNSET
condition.It seems to be working fine for us so far, but I'm not sure if this is the proper solution. There are other places on
ImaAdsLoader
whereAdPlaybackState.withAdCount
is used.** Sorry this didn't come before 2.11.5 was released :)
The text was updated successfully, but these errors were encountered: