ConcatenatingMediaSource2 playback stuck (with MRE)

[TomasValenta]

Version

Media3 1.8.0

More version details

No response

Devices that reproduce the issue

• Almost any emulator (very often, almost always)
• Samsung Galaxy A33 5G (SM-A336B) Android 15 (very rare, but reported several times)
• Probably another devices

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

1. Checkout my release fork: https://github.com/TomasValenta/media
2. Play any content
3. After a while (mostly on Emulators) playback continues, but no sound is heard (many times in a different part) and "playback" continues with no sound even though it should have ended long ago based on the timeline (with no error and isPlaying=true)

Expected result

The media plays successfully (the sound is heard until the end, after all ConcatenatingMediaSource2 sources are played), then playback stop

Actual result

The media plays successfully for a while, then no sound is heard and "playback" continues with no sound even though it should have ended long ago based on the timeline (with no error and isPlaying=true).

Media

Please see full MRE diff:
release...TomasValenta:media:release

and comments:

• BasePlayer
• ExoPlayerImpl

This issue is annoying mainly because it also happens on physical devices (although rarely), but it can be reproduced very well on Emulators.

Bug Report

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

[microkatz]

@TomasValenta

Thank you for reporting your issue. Firstly, it would help if you sent a bug report. If you cannot provide one publicly then please send it to android-media-github@google.com with the subject Issue #2835. Please also update this issue to indicate you've done this.

Next it would be easier if we could simplify your test setup to narrow the scope of the issue. Could you please provide some of the content that you were testing with? Again if you cannot send it publicly then please send it to android-media-github@google.com with the subject Issue #2835. After I received your example content I would test with the simple demo application. You can test this as well but I'd be editing the player media setup to setMediaSource with a created ConcatenatingMediaSource around here, https://github.com/TomasValenta/media/blob/ec491462bb46ac785178e9376fc4e18b608acd4f/demos/main/src/main/java/androidx/media3/demo/main/PlayerActivity.java#L294

Finally, is there a reason that you are using ConcatenatingMediaSource? I would suggest using the Player Playlist APIs like addMediaItem.

[TomasValenta]

Hello @microkatz,

Firstly, it would help if you sent a bug report.

Here is the bug report file: Dropbox link

Could you please provide some of the content that you were testing with?

The test content is already provided in the MRE commit (link already provided in the report), just play any content in the Demo-session app on any emulator.

Finally, is there a reason that you are using ConcatenatingMediaSource?

Yes, as described here #2627, ConcateningMediaSource2 perfectly fits for my usecase (I know that ConcateningMediaSource was predecessor of the playlists feature), because I simply want to concatenate multiple (in a real implementation up to hundreds) media items into a single timeline.

Again, please see full MRE diff (contains only important modifications for minimal reproducible example):
release...TomasValenta:media:release

and this two comments:

• BasePlayer
• ExoPlayerImpl

Thank you.

[marcbaechinger]

Thanks for the details and the bug report!

I found several playback sequence in the logs that appear to illustrate what you describe.

• Playback starts normally with the expected EventLogger output
• At some point these EventLogger events stop.
• The media session is still updated with a new position, but the buffered position remains always the same.

This is easily visible when grepping the logs for "EventLogger" and "onSessionPlaybackStateChanged". An example is at 10-09 21:20:20.852 starting at that moment, the buffered position isn't changed anymore while the position of the session continues to grow even beyond the buffered position. I'm not sure if this an interpolated value and hence a red herring.

However this happens once at period 2 once at period 7 so with no specific media event.

--

When you say above that this can be reproduces with the demo app, do you mean the fork with the changes on top of it?

I'm asking because the change includes a custom media source implementation and usage of ResolvingDataSource and the like. While I'm not saying this is the reason for the problem, it makes it bit unclear for us where to start digging. This is specifically the case as it seems to repro mostly on emulators.

Another thought is whether this happens with any network stack? Like you added OkHttp to the demo app. Was this happening without that dependency as well?

[marcbaechinger]

Just to confirm again. From the logs it looks like that the player stops loading at an arbitrary period within the concatenating media source that has 12 periods.

The pattern is consistently the same that we see the last loading phase ends:

10-09 21:08:46.669 10215 21041 21041 D EventLogger: loading [eventTime=10.29, mediaPos=2.22, window=0, period=0, false]
10-09 21:08:49.678  1000   638   795 D MediaSessionService: onSessionPlaybackStateChanged: record=androidx.media3.demo.session/androidx.media3.session.id./133 (userId=0) playbackState=PlaybackState {state=PLAYING(3), position=5233, buffered position=8275, speed=1.0, updated=29565500, actions=7339995, custom actions=[Action:mName='Disable shuffle mode, mIcon=2131231035, mExtras=Bundle[mParcelledData.dataSize=140]], active item id=0, error=null}

The "buffered position" that the playback state reports right after is then not changed again. There are some trailing EventLogger statements until the available periods/buffer is played out. Then playback stalls without emitting a a STATE_BUFFERED or a failure.

---

I tried to repro this with a custom media soruce factory that I inject to the player by the builder. This way any media item creates the same concatenationg media source. See below.

I couldn't see the behavior from the log where event logger stops with output. What I can see or better hear is that on the emulator audio is not audible anymore, but the player continues to load and doing kind of everything as expect. I don't hear ouput though. In such a case I always see lots of such lines:

2025-10-13 16:59:46.946   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       W  pcmWrite:259 pcm_writei failed with 'cannot read/write stream data: I/O error' (-1)
2025-10-13 16:59:46.946   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       E  pcmWrite:260 failure: -1
2025-10-13 16:59:47.050   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       W  pcmWrite:259 pcm_writei failed with 'cannot read/write stream data: I/O error' (-1)
2025-10-13 16:59:47.050   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       E  pcmWrite:260 failure: -1
2025-10-13 16:59:47.154   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       W  pcmWrite:259 pcm_writei failed with 'cannot read/write stream data: I/O error' (-1)
2025-10-13 16:59:47.154   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       E  pcmWrite:260 failure: -1
2025-10-13 16:59:47.262   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       W  pcmWrite:259 pcm_writei failed with 'cannot read/write stream data: I/O error' (-1)
2025-10-13 16:59:47.262   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       E  pcmWrite:260 failure: -1
2025-10-13 16:59:47.324   633-692   BufferPoolAccessor2.0   media.swcodec                        D  evictor expired: 2, evicted: 0
2025-10-13 16:59:47.366   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       W  pcmWrite:259 pcm_writei failed with 'cannot read/write stream data: I/O error' (-1)
2025-10-13 16:59:47.366   507-10753 android.ha...mpl.ranchu android.hardware.audio.service       E  pcmWrite:260 failure: -1

This I think is something with audio playback in the framework on the emulaotr not working anymore.

I tried with OkHttp data source and with default but the loading issue seen in the bug report, are not reproducible.

May I ask to try with the less introsive approach of simply calling ExoPlayer.Builder().setMediaSourceFactory(factory) and use the below code? Just to see whether you can repro like this because that would be a good state for further investigation and repo.

@UnstableApi
class FakeMediaSourceFactory(val context: Context) : MediaSource.Factory {

  val uris =
    listOf(
      "http://example.com",
      "http://example.com",
      "http://example.com",
     ....
    )

  val durations = listOf(7000L, 2000L, 1000L, 1000L, 12000L, 2000L, 4000L, 3000L, 1000L, 3000L, 7000L, 12000L)
  val factory = ProgressiveMediaSource.Factory(OkHttpDataSource.Factory(OkHttpClient()))

  override fun setDrmSessionManagerProvider(
    drmSessionManagerProvider: DrmSessionManagerProvider
  ): MediaSource.Factory {
    factory.setDrmSessionManagerProvider(drmSessionManagerProvider)
    return this
  }

  override fun setLoadErrorHandlingPolicy(
    loadErrorHandlingPolicy: LoadErrorHandlingPolicy
  ): MediaSource.Factory {
    factory.setLoadErrorHandlingPolicy(loadErrorHandlingPolicy)
    return this
  }

  override fun getSupportedTypes(): IntArray {
    return factory.supportedTypes
  }

  override fun createMediaSource(mediaItem: MediaItem): MediaSource {
    val builder =
      ConcatenatingMediaSource2.Builder()
        .useDefaultMediaSourceFactory(/* context= */ context)
        .setMediaItem(mediaItem)
    uris.forEachIndexed { index, uri ->
      builder.add(factory.createMediaSource(MediaItem.fromUri(uri)), durations[index])
    }
    return builder.build()
  }
}

[TomasValenta]

First, thank you @marcbaechinger for you investigation.

The media session is still updated with a new position, but the buffered position remains always the same.

What I observed when I tried to reproduce the problem was that ExoPlayerImpl getContentBufferedPosition() (called from BasePlayer getBufferedPercentage()) obtain on line long contentBufferedPositionUs = playbackInfo.bufferedPositionUs; C.TIME_UNSET. Please see: ExoPlayerImpl.

However this happens once at period 2 once at period 7 so with no specific media event.

Yes, this is the weirdest part, it does not depend on a specific source, order, or length.

When you say above that this can be reproduces with the demo app, do you mean the fork with the changes on top of it?

Yes, that's exactly why I created the fork, but it's true that I can try to cut as few Media3 components from the MRE as possible as long as the problem can still be reproduced.

Like you added OkHttp to the demo app

Yes, maybe it's in that combination (but everything is only from Media3), in production I can't do without it due to authorization. Please see: DemoPlaybackService.

May I ask to try with the less introsive approach of simply calling

Please give me a moment, I'll try it and let you know.

[TomasValenta]

May I ask to try with the less introsive approach of simply calling ExoPlayer.Builder().setMediaSourceFactory(factory) and use the below code?

With setMediaSourceFactory(FakeMediaSourceFactory(this)) it works as expected, so the problem will be somewhere in between. I'll investigate and let you know. Thank you Marc!

[TomasValenta]

@marcbaechinger Thank you Marc again for your suggestions! I investigated it again and found the problem in my prepareSourceInternal() implementation inside the CustomMediaSource (please take a look in the updated FakeMediaSource).

This synchronous logic works as expected:

override fun prepareSourceInternal(mediaTransferListener: TransferListener?) {
    try {
        prepareConcatenatingSource(
            uris = uris,
            durations = durations,
            mediaTransferListener = mediaTransferListener,
        )
    } catch (e: Exception) {
        Log.e(TAG, "Unable to process prepareSourceInternal", e)
    }
}

but my asynchronous implementation cause the issue:

override fun prepareSourceInternal(mediaTransferListener: TransferListener?) {
    coroutineScope.launch {
        try {
            val uris = uris
            val durations = durations
            delay(2.seconds) // Simulate background work

            withContext(context = Dispatchers.Main) {

                prepareConcatenatingSource(
                    uris = uris,
                    durations = durations,
                    mediaTransferListener = mediaTransferListener,
                )
            }
        } catch (e: Exception) {
            Log.e(TAG, "Unable to process prepareSourceInternal", e)
        }
    }
}

I also tried to block the thread on which prepareSourceInternal is called:

override fun prepareSourceInternal(mediaTransferListener: TransferListener?) {
    try {
        val (uris, durations) = runBlocking {
            delay(2.seconds) // Simulate background work
            uris to durations
        }

        prepareConcatenatingSource(
            uris = uris,
            durations = durations,
            mediaTransferListener = mediaTransferListener,
        )
    } catch (e: Exception) {
        Log.e(TAG, "Unable to process prepareSourceInternal", e)
    }
}

which seems to no longer cause a complete playback "stuck" issue, but rather a silence lags/gaps in the playback.

[marcbaechinger]

Thanks Tomáš for the details.

Hmmm, not sure what is going on. I looked at your FakeMediaSource.

Your intention to start a thread in prepareSourceInternal is the right one. What almost every media source does when preparing, is doing some network work or similar on a dedicated thread.

It's important to know that prepareSource and hence prepareSourceInternal are called on the playback thread that you don't want to block. So your intention is correct.

ExoPlayer is then expecting to be called back on refreshSource when the source has completed preparation. It's expecting this method to be called on the playback thread again.

This is different with the coroutine approach you're doing in FakeMedaiSource I think. The Coroutine is passed into from the factory where the corouting is created in the init block of the class. In Kotlin I think this is kind of instantiated when the constructor of the Factory is called, so the coroutine is created, as I guess on the app/main thread when the factory is created. The coroutine is then created like this:

private val coroutineScope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

and later

coroutineScope.launch {
            try {
                val uris = uris
                val durations = durations
                delay(2.seconds) // Simulate background work

                withContext(context = Dispatchers.Main) {

                    prepareConcatenatingSource(
                        uris = uris,
                        durations = durations,
                        mediaTransferListener = mediaTransferListener,
                    )
                }
            } catch (e: Exception) {
                Log.e(TAG, "Unable to process prepareSourceInternal", e)
            }
        }

From this I think that refreshSource that is called from prepareConcatenatingSource is called on the main thread as per Dispatcher.Main. The code around it with the delay , is called on a background thread that you start with the coroutine, and then the context with the Dispatche.Main is started to call back onto the main thread.

What we want to achieve is that your dispatcher dispatches to the playback thread instead.

My guess would be that we have to create a Handler when we are running on the playback thread, and then with that handler we can create a Dispatcher. Something like:

import kotlinx.coroutines.android.asCoroutineDispatcher

[....]

override fun prepareSourceInternal(mediaTransferListener: TransferListener?) {
     [...]
    val looper = Looper.myLooper()!! 
    val handler = Handler(looper)
    val playbackDispatcher = handler.asCoroutineDispatcher()
      [...]
}

If you then dispatch the call with playbackDispatcher then the refreshSource is called on the playback thread as well.

To summarize in case my talking is too confusing:

1. The hypothesis is that the problem could happen because refresSource is called on the wrong thread.
2. It should be called on the playback thread
3. To create a Kotlin dispatcher to pass the execution path back to the playback thread we have to use handler.asCoroutineDispatcher()

That's the theory. Mind trying to confirm my assumptions in practice? :)