ExoPlayer freezes after playing ad

[ogaclejapan]

Issue description

ExoPlayer freezes at the ending of the ad, in BUFFERING state. This problem occurs when the advertisement interval is very short and VAST response document is empty.

<?xml version="1.0" encoding="UTF-8"?>
<vmap:VMAP xmlns:vmap="http://www.iab.net/videosuite/vmap" version="1.0">
  <vmap:AdBreak timeOffset="start" breakType="linear" breakId="preroll-1">
  ..
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="00:00:18" breakType="linear" breakId="midroll-2">
    <vmap:AdSource id="midroll-2-ad-1">
      ...
    </vmap:AdSource>
  </vmap:AdBreak>
  <vmap:AdBreak timeOffset="00:00:19" breakType="linear" breakId="midroll-1">
    <vmap:AdSource id="midroll-1-ad-1">
      ... (VAST response document is empty)
    </vmap:AdSource>
  </vmap:AdBreak>
</vmap:VMAP>

Reproduction steps

https://github.com/google/ExoPlayer/compare/release-v2...ogaclejapan:ima-freezes?expand=1

• Demo1: freezes at 18s
  Ad cuepoints : 0s(empty), 18s, 19s(empty)

• Demo2: no problem
  Ad cuepoints : 0s(empty), 18s, 23s(empty)

Link to test content

CONTENT_URL: https://file.ogaclejapan.com/video/video_30s_hls/index.m3u8
AD_TAG_URL: https://vast-ads.netlify.com/demo.xml

Version of ExoPlayer being used

I tried version is 2.9.0 and 2.9.4 and release-v2

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

Device: Nexus 6P
Version: 8.1.0

[rs146]

Hi, I am facing a similar issue where the player continues playback before the last ad in a multiple ad roll completes. I can see the ad countdown timer at the bottom left of the screen (at 0:00 remaining) while the player has continued playback.

This occurs when the actual ad length is very short as mentioned above. And sometimes it's stuck in the BUFFERING state too (as mentioned above).

I am using DASH and an IMA url which contains multiple pre-roll ads and two mid-roll (each with multiple ads). If you would like a sample stream url and ad url to test, then please let me know.

[andrewlewis]

The IMA SDK doesn't pass us information on which ad group failed to load when reaching an empty ad group (see also #5006). The problem here seems to be that we get the empty ad load error relating to the ad group at 19 seconds even before we've played the ad that successfully loads at 18 seconds. The logic we have for calculating which ad group an empty ad load error relates to currently doesn't expect a load error to be received before we've played an ad that has successfully loaded after the current content position.

I'll look into whether we can refine this logic to match the IMA SDK code more closely, but I'm concerned this will be fragile in case the IMA SDK preloading logic changes in future.

It also seems like a bit of an edge case to have two ad groups so close to each other. I think this bug is triggered if you end up with an ad group that loads less than the preload duration (currently four seconds) after another ad group that does load, so you could try spacing these ad groups apart by four seconds or more. In any case, having two ad groups within a second seems like it would give a bad user experience if both loaded! Alternatively, you can probably avoid this situation in the first place by using optimized ad pods (so no ad pods are empty).

[ogaclejapan]

Thanks for looking it.
demo3 added. I found a new way to cause this problems.

It occurs when fast-forwarding is repeated :(
This problem occur if the repeat fast-forward greater than ad interval.
So it occurs even if the preload duration is very short.

CONTENT_URL: https://file.ogaclejapan.com/video/video_300s_hls/index.m3u8
AD_TAG_URL: https://vast-ads.netlify.com/demo2.xml

[andrewlewis]

Sorry for the long delay. This is probably fixed by fa7d26d but I couldn't verify as I get an error AdError [errorType: LOAD, errorCode: AdErrorCode [name: FAILED_TO_REQUEST_ADS, number: 1005], message: There was a problem requesting ads from the server. Caused by: 6].

We also added automatic timing out when preloading is not working correctly in 793f12d, so that should make the failure mode less bad. Please could you try to reproduce this on the dev-v2 branch and reply here or file a new issue if there are still problems?