-
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
Ad playback stuck after media timeouts #10510
Comments
Actually, looks like the same circumstances already mentioned in #10494 . Here you have at least a VMAP to test with that will trigger those 402 timeouts. |
Thanks for the excellent reproduction steps! It seems the IMA SDK gets stuck and doesn't issue the expected callbacks any more. In fact, this seems to be caused by not timing out after the configured media timeout. We reported the issue to the IMA SDK team and will also provide a workaround in ExoPlayer that times out in this situation to ensure playback is unstuck. |
The workaround will appear here soon and will be part of the next release. |
Any updates on this issue? Thank you. |
In some cases, the IMA SDK fails to call the expected loadAd event to load the next ad to play. This is (potentially) the only remaining case where playback can get stuck due to missing calls from IMA as the player doesn't even have a MediaSource at this stage and is only waiting for IMA to provide the ad URL. We can reuse the existing adPreloadTimeoutMs that was added for a similar purpose (when preloading the first ad in the group). The JavaDoc matches this purpose as well and the default timeout is appropriate since we expect to get the loadAd call immediately. Issue: google/ExoPlayer#10510 PiperOrigin-RevId: 466953617
In some cases, the IMA SDK fails to call the expected loadAd event to load the next ad to play. This is (potentially) the only remaining case where playback can get stuck due to missing calls from IMA as the player doesn't even have a MediaSource at this stage and is only waiting for IMA to provide the ad URL. We can reuse the existing adPreloadTimeoutMs that was added for a similar purpose (when preloading the first ad in the group). The JavaDoc matches this purpose as well and the default timeout is appropriate since we expect to get the loadAd call immediately. Issue: #10510 PiperOrigin-RevId: 466953617
ExoPlayer Version
2.15.1
Devices that reproduce the issue
Any that we have tested.
Devices that do not reproduce the issue
n/a
Reproducible in the demo app?
Yes
Reproduction steps
[ { "name": "Sample", "samples": [ { "name": "VMAP", "uri": "https://storage.googleapis.com/exoplayer-test-media-1/mkv/android-screens-lavf-56.36.100-aac-avc-main-1280x720.mkv", "ad_tag_uri": "https://devs.origin.cdn.cra.cz/ima/primavmap.xml" } ] } ]
Expected result
Each midroll references the same VAST where there are three ads. The first two emulate slow media server response and return media only after 10 seconds, i.e. after the default timeout of 8 seconds. The third ad in midroll is served with regular speed.
IMA should gracefully skip the first two ads in each midroll and play the third midroll only. Each midroll should be playable the same way.
Actual result
We have received reports from our customer that serves their own ads to our player that it occasionally gets stuck when playing ads. It helped knowing that their ad server tracker received in that case 402 error i.e. timeout as per https://support.google.com/admanager/answer/4442429?hl=en#zippy=%2Cunable-to-download-or-timeout-of-mediafile-uri.
So we prepared the environment with our own VMAP that would emulate the same behavior and first two ads time out from each midroll, only the third is immediately playable.
With this environment we can reproduce the player getting stuck most of the time during the third midroll at 1:30, seldomly at fourth midroll at 2:00. Tested with 2.15.1 and 2.18.1 with the same result.
A hint: it appears that while it works for the first few midrolls, the log can contain
java.net.SocketTimeoutException
but it doesn't when it gets stuck.Media
See reproduction steps section.
Bug Report
adb bugreport
to [email protected] after filing this issue.The text was updated successfully, but these errors were encountered: