Insufficient loading throughput and repeated buffering during high-bitrate progressive direct playback on Android TV — is this a known issue?
@tonihei is already working on this.
Since Sep 10, 2026.
- Dominant language
- Java
- Stars
- 3k
- Forks
- 955
- Avg merge
- 12d 14h
- Merged PRs (30d)
- 2
Description
Media3 version
Media3 1.11.0
Device that reproduces the issue
Device: Google TV Streamer (4K)
Codename: kirkwood
SoC: MediaTek MT8696
RAM: 4 GB
Android version: [VERSION]
API level: [API LEVEL]
Network: [Gigabit Ethernet / 5 GHz Wi-Fi]
Description
Our application is an Android TV media client that uses Media3 to play content provided by an Emby server.
When playing high-bitrate 4K content, Media3 starts playback normally, but the loading rate cannot consistently keep up with media consumption. The observed behavior is:
isLoading = true
totalBufferedDuration continues to decrease
the player eventually enters STATE_BUFFERING
We have confirmed through the Emby dashboard and server logs that the affected content is using Direct Play. There is no video transcoding, audio transcoding, or container remuxing.
Increasing the buffer size only delays the stall and does not resolve the sustained loading-rate deficit.
As a comparison, the same content appears to play normally when using ExoPlayer/Media3 on a more powerful Android phone. It also plays normally with Kodi on an Android TV device.
Based on these observations, the issue appears to occur more frequently on Android TV devices with relatively limited performance, although we have not yet identified the root cause.
Configurations tested
Asynchronous MediaCodec queueing is already enabled:
forceEnableMediaCodecAsynchronousQueueing()
This does not resolve the issue.
I also tested tunneling:
setTunnelingEnabled(true)
Based on my personal observation, enabling tunneling appears to improve the rate at which buffered content accumulates compared with non-tunneled playback. However, the improvement is still insufficient to sustain smooth playback.
This result has not yet been measured through a controlled benchmark, so I am only providing it as a potentially relevant observation.
Impact
This does not appear to be isolated to a single test device.
All users of our application use Android TV devices or Android TV boxes, and a large proportion of them have reported the same or similar behavior, particularly with high-bitrate 4K content.
For some media, repeated buffering prevents users from watching continuously and is affecting normal playback functionality.
Reproducible in the Media3 demo app?
Not tested yet.
The actual media URLs require Emby authentication, and some original media files cannot be shared publicly. We do not currently have a public minimal reproduction demo.
If necessary, we can try to prepare a minimal reproduction project, a publicly accessible test file, or a URL that can be tested with the Media3 demo app.
Request for assistance
We do not currently know which part of the playback pipeline is responsible, and we do not want to assume a specific root cause without sufficient evidence.
We would first like to confirm:
- Whether similar behavior is already known to the Media3 team or community.
- Whether this is a known issue or limitation on Android TV devices.
- Whether there is a recommended direction for investigation or mitigation.
Because this issue is affecting normal playback for a large number of our Android TV users, we would be happy to work with the Media3 team to investigate it.
If additional information is required, we can provide playback and buffering logs, EventLogger output, Emby Direct Play logs, an adb bugreport, a Perfetto trace, or other diagnostics requested by the maintainers.
Possibly related issues
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.