Exoplayer: Ad Load Error

Created on 16 Aug 2017  路  16Comments  路  Source: google/ExoPlayer

Issue description

so I am trying to get the new version of exoplayer's demo to load and correctly play a preroll ad and a hls stream from an m3u8 file. The problem is that I get a vast timeout error such as this :
Caused by: AdError [errorType: PLAY, errorCode: AdErrorCode [name: VAST_MEDIA_LOAD_TIMEOUT, number: 402], message: VAST media file loading reached a timeout of 8 seconds.]

After I recieve this error it starts to play the underlying content

I noticed that in this link https://support.google.com/dfp_premium/answer/4442429?hl=en
under 402 we see another link for this:
"When the loadVideoTimeout setting in the IMA SDK is set unreasonably low. The default is 8 seconds."

However, I don't see a way to set this in the RenderSettings in the android version. I would love any feedback you guys could provide!

Reproduction steps

replace the first IMA Sample ad tags tuple values with the ones in the email; "uri" and "ad_tag_url".

Link to test content

links provided in email

Version of ExoPlayer being used

latest 2.5..

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

Samsung s7 edge 7.0
Samsung s6 7.0

A full bug report captured from the device

emailed in

bug

All 16 comments

8 seconds already seems like a long wait before playback can start. Can you somehow reduce the latency of loading the ad tag?

If you don't want the content to play in this case, you can handle the ad loading error via ImaAdsMediaSource.onAdLoadError and stop the player or show a message.

that just bubbles up the exception, I want the player to ignore this error and continue playing the ad until it finishes and then play the underlying content, right now it just calls this error and finishes the ad and plays the content, if I switch out the content stream for another one it finishes correctly. I am kind of looking for a way to ignore this 8 second time out

Not sure I understand "if I switch out the content stream for another one it finishes correctly" -- please could you clarify this?

For the Android IMA SDK it looks like the default timeout is five seconds and can be overridden via AdsRequest.setVastLoadTimeout. I will mark this as an enhancement to allow apps to customize the value.

So if I take the "uri" field for a different content uri such as https://storage.googleapis.com/exoplayer-test-media-1/mkv/android-screens-lavf-56.36.100-aac-avc-main-1280x720.mkv , it works. let me check the vastLoadTimeout, hard to find this attribute in terms of documentation let me find out if setting this manually works

adding request.setVastLoadTimeout(35000); directly in the requestAds() method in ImaAdsLoader didn't seem to help the situation. Is there a different place one would set this?

Actually, this error is caused by timing out loading the media URL in the VAST response, not loading the VAST response itself, so I think setVastLoadTimeout won't help. It appears that there is no way to customize the media loading timeout on Android (though it is apparently possible with the HTML5 SDK).

I tried playing the URIs provided via email several times and didn't see this error. The ad plays then the content plays reliably. Do you see this error in the ExoPlayer demo app if you modify the first ad sample to use the provided URIs?

I am still a bit confused about the description of the problem. Does the ad start playing, then the error occurs while it is playing? Also, eight seconds should be plenty of time to load the ad media, and I'm not convinced you'd want users to wait longer than that. It might help diagnosing what's going on if you could email logcat captured while reproducing the issue with ImaAdsLoader.DEBUG set to true. Thanks!

I do see this error when I modify the ExoPlayer's first ad sample. it appears that in the method onAdEvent() gets called and we get a resume content requested which causes the ad to stop playing, even though it has clearly not reached the end of playing. We want the ad to play all the way through and then move to play the content I will send more updated logs

I have sent additional information Via email to dev.[email protected]. If you use the information provided the error is repeatable directly from the demo

Is there any additional information than can be delivered on your side of things? or do we need to provide more information?

Also talked to the IMA people over here at their boards : https://groups.google.com/forum/#!topic/ima-sdk/3FFR55HyN6g

they are suggesting that it might be something wrong with the implementation. Also I tested these tags in their player implementation and it would appear to work there.

This is a bug in ExoPlayer, where we incorrectly apply a position offset related to the content to the position during the ad playback. This causes us to report incorrect ad playback positions to the IMA library, which causes the IMA library to think that the ad isn't playing, which triggers the error.

The issue only occurs for HLS content that uses PROGRAM-DATE-TIME tags, since it's these that make the content position offset non-zero. This is why you see the problem for the specific content you link to, but not other HLS streams (or regular media streams).

We'll merge a fix into dev-v2 shortly, and provide a release next week including the fix. Thanks for reporting!

Should be fixed by the change ref'd above.

@ojw28 Is there a planned release date so that we can coordinate our internal release that will include this fix?

We'll be pushing a bugfix release (2.5.2) early next week, so keep an eye out for that. Thanks!

Hi there, this issue or one very similar to it seems to still be occurring with a small subset of devices and ads. On a galaxy S3 mini on Android 4.4.2 certain ads still seem to play audio only and no video and when this occurs the same error earlier in this thread is showing.

AdError [errorType: PLAY, errorCode: AdErrorCode [name: VAST_MEDIA_LOAD_TIMEOUT, number: 402], message: VAST media file loading reached a timeout of 8 seconds.]

Reproducible in the exoplayer sample/demo.

Please file a separate issue if there's still a problem from 2.5.2 or later, together with all of the information requested in the issue template. Thanks!

Was this page helpful?
0 / 5 - 0 ratings