IMA-extension only plays 1 pre-roll from VMAP file

[magnusvs]

Issue description

We're trying to implement IMA for our app with the Exoplayer IMA-extension.

Simple ads are working as expected but the extension does seem to have some trouble loading multiple pre-rolls and post-rolls.

Our VMAP contains 5 pre-rolls and 1 bumper before to play before the content. 3 of the pre-rolls are broken. Similarly there are 5 post-rolls where 3 are broken.
This ad tag url has been emailed to dev.exoplayer@gmail.com

We expect the player to play 2 pre-rolls and 1 bumper for before the video content and skip the pre-rolls that are broken. Post-rolls is expected to behave similarly.
This works as expected in Ima SDK advanced and simple example app. (https://github.com/googleads/googleads-ima-android)

However not in the Exoplayer ima-demo app and our implementation with the exoplayer where it only shows 1 pre-roll before content.

Any idea if there could be something wrong in the extension?

Reproduction steps

Switch out the ad_tag_url to our custom url provided in the email in the demo-ima app.

Link to test content

Sent by email

Version of ExoPlayer being used

Tested on v2.9.0 and the dev-v2 branch today.

Device(s) and version(s) of Android being used

Google pixel 2 XL

A full bug report captured from the device

Not provided

[andrewlewis]

This looks like another issue to do with handling empty ads: at least some of the ads in the preroll are empty, and our current behavior is to skip the whole ad group when this happens. Empty ad groups are difficult to handle in the IMA extension because we get very little information from the IMA SDK.

Is it possible to set up the ad serving so that the ad slots are not empty?

[magnusvs]

If I've understood everything correct, the vmap file is set up with a rule of max number of pre-rolls for example and the slots that are sold will be filled and the other ones will be empty. So I don't think it is possible to eliminate empty ads.
The implementation on iOS and web works fine so they seem to handle this in some other way than skipping the whole group.

Currently when the whole group is skipped and content is resumed we do not get the correct adEvents from the AdEventListener either. 'CONTENT_RESUME_REQUESTED' is received 1 min later than when the content starts playing which causes some trouble for us. Is this expected behaviour?

[andrewlewis]

The reason this is tricky is that our implementation preloads ads to avoid buffering when reaching an ad cue point, but when an ad is empty we get an event from IMA that doesn't tell us which particular ad index in which ad group fails to load.

I think the next step towards fixing this is to try replacing the code that marks the ad group as unplayable so it just marks the next ad as unplayable here like this:

-    for (int i = 0; i < adGroup.count; i++) {
-      if (adGroup.states[i] == AdPlaybackState.AD_STATE_UNAVAILABLE) {
-        if (DEBUG) {
-          Log.d(TAG, "Removing ad " + i + " in ad group " + adGroupIndex);
-        }
-        adPlaybackState = adPlaybackState.withAdLoadError(adGroupIndex, i);
+    int adIndexToPlay = adGroup.getFirstAdIndexToPlay();
+    if (adGroup.states[adIndexToPlay] == AdPlaybackState.AD_STATE_UNAVAILABLE) {
+      if (DEBUG) {
+        Log.d(TAG, "Removing ad " + adIndexToPlay + " in ad group " + adGroupIndex);
       }
+      adPlaybackState = adPlaybackState.withAdLoadError(adGroupIndex, adIndexToPlay);
     }

If you want to try to fix this yourself you could depend on ExoPlayer via sources (see instructions here) and patch that change in. I'm not sure whether we can distinguish individual ads failing to load from whole ad groups failing to load, so it will take more investigation to know whether this is a robust fix.

[magnusvs]

Thanks for the suggestion.
I've tried your solution and I think this leads to the pre-rolls and bumper is loaded and played correctly but then the player does not start the content. The last AdEvent is just an AD_PROGRESS.

I've also tried a similar approach:

for (int i = 0; i < adGroup.count; i++) {
      if (adGroup.states[i] == AdPlaybackState.AD_STATE_UNAVAILABLE) {
        if (DEBUG) {
          Log.d(TAG, "Removing ad " + i + " in ad group " + adGroupIndex);
        }
        adPlaybackState = adPlaybackState.withAdLoadError(adGroupIndex, i);
+        break;
      }
    }

This works sometimes, all pre-rolls and bumper is loaded and played. Post-rolls also works as expected. However it also sometimes fails and gets stuck either at the last working pre-roll or the bumper and never continues to content. I think it it's more likely to happen when using a slower connection.

I've been trying to wrap my head around all the stuff going on in ImaAdsLoader but haven't figured out why it sometimes freezes. Could this reseting affect getContentProgress() so the ImaSdk doesn't understand when the ads have been played?
Any ideas how to continue?

[andrewlewis]

This is proving difficult to diagnose as there is a current issue with late event delivery when using the IMA SDK which reliably reproduces only when using debug mode and causes the player to get stuck [internal issue: b/117991305].

Using the potential fix above, so far I haven't been able to get the IMA SDK to 'acknowledge' playback of the non-empty ad after the first ad in the preroll ad group: no overlay shows and it doesn't poll the ad progress, yet our interactions with the API seem to match those from a correct playback. However, I don't see ad playback getting stuck as you describe, unless I put the IMA SDK in debug mode.

Apart from that, I think the best options at the moment are removing the empty ads (e.g., using an optimized ad pod), or discarding the whole ad break when one ad fails to load (adsManager.discardAdBreak()).

[tonihei]

@andrewlewis The referenced internal bug is already fixed. Can this issue be closed?

[andrewlewis]

The internal reference in my previous comment relates to a bug with debug mode that was making this difficult to diagnose.

The IMA SDK team is actively working on improving preloading support which should address this once and for all. We don't yet have an ETA for that though I'm afraid. I am going to leave this open for now and will close it once we've verified that empty ad groups can be handled properly after those improvements are in.

[hvisser]

Any updates on this? We are running into this problem for bumper ad tags before our midroll that are not always filled, which is causing the entire midroll to be skipped. Maybe there's a specific workaround that we can apply? We'd rather not turn off the bumper since other platforms do serve this correctly.

[andrewlewis]

An upcoming IMA SDK version makes preloading (used by the ExoPlayer IMA extension) more robust, and based on my testing it will fix this issue. I can't give any guarantees about when this will be available I'm afraid (it is mostly out of our control), but I expect it will be during the next couple of months.

[RaiPubblicitaTech]

Hi, we had a similar issue with our app. The Ad Manager Publisher Support suggested the use of the "vpi=1" parameter within the Video Publisher Tag. In this case the VMAP response will be "monolithic", all the VAST tag are expanded in the VMAP response.
They suggested this as a temporary workaround waiting for a fix , but it doesn't work.

For example, using this tag; https://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/ad_rule_samples&ciu_szs=300x250&ad_rule=1&impl=s&gdfp_req=1&env=vp&output=vmap&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ar%3Dpremidpostpod&cmsid=496&vid=short_onecue&correlator=&vpi=1
the response will be something like:

<vmap:VMAP xmlns:vmap="http://www.iab.net/videosuite/vmap" version="1.0">
  <vmap:AdBreak timeOffset="start" breakType="linear" breakId="preroll">
    <vmap:AdSource id="preroll-ad-1" allowMultipleAds="false" followRedirects="true">
      <vmap:VASTAdData>
        <VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="vast.xsd" version="3.0">
          <Ad> .... </Ad>
        </VAST>
      </vmap:VASTAdData>
    </vmap:AdSource>
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="00:00:15.000" breakType="linear" breakId="midroll-1">
    <vmap:AdSource id="midroll-1-ad-1" allowMultipleAds="false" followRedirects="true">
      <vmap:VASTAdData>
        <VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="vast.xsd" version="3.0">
          <Ad>...</Ad>
        </VAST>
      </vmap:VASTAdData>
    </vmap:AdSource>
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="00:00:15.000" breakType="linear" breakId="midroll-1">
    <vmap:AdSource id="midroll-1-ad-2" allowMultipleAds="false" followRedirects="true">
      <vmap:VASTAdData>
        <VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="vast.xsd" version="3.0">
          <Ad>...</Ad>
        </VAST>
      </vmap:VASTAdData>
    </vmap:AdSource>
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="00:00:15.000" breakType="linear" breakId="midroll-1">
    <vmap:AdSource id="midroll-1-ad-3" allowMultipleAds="false" followRedirects="true">
      <vmap:VASTAdData>
        <VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="vast.xsd" version="3.0">
          <Ad>...</Ad>
        </VAST>
      </vmap:VASTAdData>
    </vmap:AdSource>
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="end" breakType="linear" breakId="postroll">
    <vmap:AdSource id="postroll-ad-1" allowMultipleAds="false" followRedirects="true">
      <vmap:VASTAdData>
        <VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="vast.xsd" version="3.0">
          <Ad>...</Ad>
        </VAST>
      </vmap:VASTAdData>
    </vmap:AdSource>
  </vmap:AdBreak>
</vmap:VMAP>

In this case too, when we have 2 preroll slots where:

• preroll-ad-1: filled
• preroll-ad-2: unfilled (empty VAST)
  The SDK skips the first Ad and throws a 402 VAST error.
  @andrewlewis , could you test this use case too?

[hvisser]

I've been investigating the issues on our end further, and it appears that the IMA SDK sends out two LOADED events for the same ad group, with the number of ads in the group increasing. This yields an error and prevents further ads in that group from playing as they are ignored. Not sure if this is related to this issue or if that needs a new one, I can provide a test ad tag if required too.
Sorry, I was misunderstanding what's happening. The ExoPlayer IMA extension is invalidating the expected ad group when it receives an ad load error when the bumper for that group doesn't load. When the load for the midroll ads come in it does have the correct ad group index set, but by that time it's already invalidated and set to 1 ad.

[shasapo]

Halo,
Is there any update for this ?

I'm experiencing the same issue using exo version : 2.11.2.
Ad keeps loading even though it's already completed. It repeatedly give AD_PROGRESS events but never trigger ad_complete and then the content never played.

[andrewlewis]

@magnusvs I've verified that both prerolls play after migrating to the new IMA SDK preloading APIs in fa7d26d. That change should be in a release soon. Sorry for the long wait!

@tech-advdigital With the ads response provided the preroll plays (it is not skipped) so I think this is probably fixed too.

@shasapo Please could you try to reproduce the behavior you are seen on the dev-v2 branch to pick up fa7d26d? If it still doesn't work as expected, please file a new issue and include your ad tag.