Increase in ERROR_CODE_FAILED_RUNTIME_CHECK=1004 errors after seek on Android 14 since 1.3.0

[egor-n]

Version

Media3 1.3.0

• The number of errors has grown ~3-4 times after the update from 1.2.0 to 1.3.0
• We will update to 1.4.0 in the near future to see if that helps

More version details

No response

Devices that reproduce the issue

We were not able to reproduce the issue locally yet, but here are some stats from production.

The issue is most prominent on Android 14:

Devices:

Device	Occurrences over last 30 days (unique)
SM-X200	14,885
SM-P613	9,367
SM-A525M	7,118
CPH2363	6,109
SM-A135M	6,082
moto g84 5G	5,732
SM-A235M	5,542
moto g53 5G	5,249
23043RP34G	5,211
motorola edge 30 neo	3,859
A063	3,275
SM-X205	2,615

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

Based on the user behavior, most users face this issue after seeking the video. Examples:

Expected result

The media plays successfully.

Actual result

Playback crashes with the ERROR_CODE_FAILED_RUNTIME_CHECK=1004 error.

Unexpected runtime error at q2.J.handleMessage(ExoPlayerImplInternal.java:293)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loopOnce(Looper.java:257)
    at android.os.Looper.loop(Looper.java:368)
    at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: android.media.MediaCodec$CodecException:
    at android.media.MediaCodec.native_flush(Native Method)
    at android.media.MediaCodec.flush(MediaCodec.java:2504)
 // ... the rest of the stacktrace is obfuscated

The diagnostic info is: android.media.MediaCodec.error_neg_110

https://developer.android.com/reference/android/media/MediaPlayer#MEDIA_ERROR_TIMED_OUT

Media

DASH H.264, Widevine

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[tonihei]

Does this problem only happen for Widevine protected content? (You may not be able to say that if your app doesn't play anything else).

The most suspicious change that could make a difference for 1.3.0+ and Android 14+ specifically is e5aa692.

Could you try calling DefaultRenderersFactory.experimentalSetMediaCodecAsyncCryptoFlagEnabled(false) when setting up the player to see if it makes a difference? The customized DefaultRenderersFactory can be injected into ExoPlayer.Builder.setRenderersFactory.

[egor-n]

Does this problem only happen for Widevine protected content? (You may not be able to say that if your app doesn't play anything else).

The app only plays Widevine DRM-protected content, so I can't say if it happens for anything else.

Could you try calling DefaultRenderersFactory.experimentalSetMediaCodecAsyncCryptoFlagEnabled(false) when setting up the player

Thank you for the suggestion 👍 We have set this flag to false and I will come back with updates once we have more production data.

[egor-n]

Hello @tonihei, it looks like setting DefaultRenderersFactory.experimentalSetMediaCodecAsyncCryptoFlagEnabled to false does seem to help. We see a decrease in the 1004 errors to the level of pre-media3-1.3.0.

[tonihei]

Thanks for the verification! It looks like there might be a bug in the Android platform implementation of this performance optimization then. I'll try to follow up with the relevant team to see if there is something we can do. [internal ref: b/362450802]

[maartenvgpersgroep]

I can confirm exactly the same behavior on a Samsung SM-X200, we can consistently reproduce the issue on version 1.5.0 (we upgraded from 1.2.0 and see the problem since then).

We play a mixture of plain mp4's in a playlist together with Widevine L1 protected DASH streams. Every time we seek in the DASH stream, we get exactly the same playback failure and stacktrace as in the issue description.

I can confirm that calling experimentalSetMediaCodecAsyncCryptoFlagEnabled(false) solves the issue in our case, too.

@tonihei Do you happen have any update regarding this issue? It feels slightly uncomfortable to rely on an experimental flag to fix playback issues in production.

[tonihei]

There is no update from the relevant platform team yet I'm afraid. Since the feature doesn't seem to be reliable, I'm going to flip the default back to "don't use it" until we get more information when a fix will be available.

[tonihei]

It feels slightly uncomfortable to rely on an experimental flag to fix playback issues in production.

Forgot to address this part: The method is "experimental" because we intend to remove it without further deprecation as soon as we are satisfied that no setter is needed. But it simply turns the feature on and off, so it's safe to use (just be prepared for it to disappear in a future update of the library).

[tonihei]

we can consistently reproduce

@maartenvgpersgroep Does that mean you have a reproducible example on a local test device (and not just reports from users)? If so, is there a way to share the reproduction steps with us and/or provide a bugreport after the issue? You can send information to android-media-github@google.com with "Issue #1641" in the subject if needed and report back here once you've done that. If we have a way to directly reproduce the issue it's much more likely to find a root cause and fix.

[maartenvgpersgroep]

@tonihei I have double-checked with our QA, and we cannot reproduce the issue consistently and reliably, but we can reproduce it often. Sometimes it fails a couple of times in a row, sometimes it doesn't happen at all. But it's reproducible enough to capture a bug report.

I have sent an email with our setup, reproduction steps as well as a bugreport to android-media-github@google.com.

I hope it helps.

[tonihei]

Thanks for the additional information! I forwarded that to the platform team, so hopefully it's helpful to investigate the issue.