Audio playback stutters when 1x repeat is enabled

[Daeng96]

Version

Media3 1.5.0

More version details

The problem occurs in library versions 1.5.0-1.9.0

Devices that reproduce the issue

Redmi note 14 / Android 15

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

Playback stutters at the end of the track, buffering several times before the track plays back normally. This occurs in library versions 1.5.0 and above (version 1.4.1 is safe). The problem occurs when I set repeat to "Player.REPEAT_MODE_ONE".

sc.mp4

Expected result

The audio / track plays smoothly without buffering at the end and repeats immediately after the track ends without buffering.

Actual result

buffering occurs several times until finally the track plays back normally even though I am using a local file, not streaming.

Media

https://audio.qurancdn.com/Shatri/mp3/001001.mp3
https://audio.qurancdn.com/Shatri/mp3/001002.mp3

Bug Report

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

[tianyif]

@Daeng96,

Thanks for reporting this issue! I can reproduce the same behaviour from my side, and same as you said, it is only seen from 1.5.0.

When reproducing, I saw the below method was hit:

media/libraries/extractor/src/main/java/androidx/media3/extractor/mp3/Mp3Extractor.java

Lines 689 to 694 in 7cc1056

	/**
	* If {@link #seeker} is a seekable {@link ConstantBitrateSeeker}, this updates it to end at the
	* last sample we read (because we've failed to find a subsequent synchronization word so we
	* assume the MP3 data has ended).
	*/
	private void maybeUpdateCbrDurationToLastSample() {

As the javadoc pointed, in this case we failed to find a subsequent synchronization word (eg. due to non-MP3 trailing data in the file - #1563) so we assume the MP3 data has ended, therefore the updated SeekMap may have a different duration than the one in the earlier SeekMap.

In the REPEAT_ONE mode, we create new MediaPeriods for each repeat round from the same MediaSource, and load them, one after another. And for your MP3 file, when we load the first MediaPeriod, initially we get a timeline duration of X us, and when the loading of it approaches to the end, the timeline duration is adjusted to Y us. Then same for the second MediaPeriod (for the next repeating round), we get the duration of X initially, and then Y. But to the MediaSource level, the timeline duration keeps flipping between X and Y, and when these changes are propagated to the player, the player will remove the queued MediaPeriod (the second one) due to the updated timeline information. After removal, the player will create and enqueue another new MediaPeriod, and then it will be removed soon for the same reason. When I inspected the MediaPeriodQueue, its size kept flipping between 1 and 2, which means that we couldn't get the MediaPeriod for the next repeating round successfully loaded, then the playback stutter occurred.

We will be providing a solution for this. Thanks for spotting this bug!

[tianyif]

A fix has been submitted.