HLS: MergingMediaSource with two HlsMediaSources buffers indefinitely near beginning of stream

Our app streams two HLS audio tracks simultaneously that need to stay synchronized with each other. We have implemented custom code in order to keep these two audio tracks synchronized using a single player.

After upgrading from 2.13.2 to 2.13.3 (mainly so we don’t need to use the JCenter repos), our app starts streaming HLS content but then starts buffering (endlessly) immediately prior to the third byte range, sometime between 16 seconds and 18 seconds for every stream. If we kill the app, restart, and resume playing where we left off, the rest of the stream continues successfully without buffering.

The following messages appear in the debug console while streaming, but it may be unrelated:

W/AudioTrack: getTimestamp_l(117): retrograde timestamp time corrected, 1976309488228578 < 1976309493652016

I think I’ve narrowed the problem down to 0d052e0399e82355f53c77779a2053aa264cbac3 which was intended to address #8700 and #8372. Pretty sure that the thread is falling into the following block and never getting notified:

while (lastSampleTimestampUs == C.TIME_UNSET) {
    wait();
}

I will be following up via email with the ExoPlayer demo app that’s been modified to use our custom player.

• Clear reproduction steps including observed and expected behavior Start streaming the example in the demo app. You can see the buffer stops loading between 16 and 18 seconds and once the playback buffer is exhausted, playback stops. It is expected that the stream will continue to completion.
• Output of running “adb bugreport” in the console shortly after encountering the issue This will be included in my email correspondence
• URI to test content for reproduction These are included in the demo app
• ExoPlayer version number 2.13.3 (this code works on 2.13.2)
• Android version 11 (also reproducible on 10 emulator)
• Android device Google Pixel 4a (also reproducible on emulator)

Thanks for any assistance!

[ojw28]

I think this should be fixed by the commit referenced above. Please give it a try!

[ojw28]

I am looking at some other issues that 0d052e0 caused currently. Once I have a fix for those I’ll see if it also fixes this issue at the same time.