Player moves to next item in playlist before completing previous item.

Version

Media3 1.4.1

More version details

No response

Devices that reproduce the issue

Pixel 8 running Android 15
Emulator Pixel 5 Android 14

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

Play the issue causing mp3 file
Wait until reached 1:40 (1 min 40 sec) position

Expected result

The media plays successfully

Actual result

Either the player starts playing next item in the playlist, or the sound stops but position is increasing.
No Error shown by player.
Following warnings are there:

6038-6103  CCodecConfig            I  query failed after returning 7 values (BAD_INDEX)
6038-6076  MediaCodec              D  keep callback message for reclaim
6038-6103  Codec2Client            W  query -- param skipped: index = 1342179345.
6038-6103  Codec2Client            W  query -- param skipped: index = 2415921170.

I am observing this issue with more mp3 files also but at different positions.
The issue is not observed by other softwares, such as Windows Media Player, Chrome Browser Player.

Media

MP3 file link

Bug Report

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

This is happening because the file has a VBRI header where the table of contents (ToC) only covers 2255081 bytes, while the file on disk is 13605001 bytes long.

When I play this file in ExoPlayer I see a warning logged about this:

VbriSeeker              androidx.media3.demo.main            W  VBRI data size mismatch: 13605001, 2255081

The result of this that we indicate the frame just before byte 2255081 is the last sample, and so playback stops at that point. With some extra logging I see dataEndPosition=2255081, extractorInput.getPeekPosition()=2255491 at these lines:

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

Lines 322 to 324 in 827966b

    
           if (peekEndOfStreamOrHeader(extractorInput)) { 
        
             return RESULT_END_OF_INPUT; 
        
           }

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

Lines 455 to 460 in 827966b

    
           private boolean peekEndOfStreamOrHeader(ExtractorInput extractorInput) throws IOException { 
        
             if (seeker != null) { 
        
               long dataEndPosition = seeker.getDataEndPosition(); 
        
               if (dataEndPosition != C.INDEX_UNSET 
        
                   && extractorInput.getPeekPosition() > dataEndPosition - 4) { 
        
                 return true;

We are currently assuming that the ToC in the VBRI frame covers the whole file. This is perhaps an unreasonable assumption.

The VBRI frame also has a bytes field to indicate the amount of MP3 data in the file (which we don't use atm). This should be the number of MP3 bytes, not including the VBRI frame itself.

In your file, the VBRI frame has bytes=13603849, so based on that we'd expect the end of the MP3 data to be at:

  vbriFrameStart + vbriFrameSize + bytes
= 1024 + 522 + 13603849
= 13605395

This seems incorrect, because the file on disk is only 13605001 bytes long!

With a bit of guesswork, and noting that the VBRI frame also has a frameSize=128 field (which is meant to be the average frame size of the rest of the file), we can re-run the calculation assuming whatever populated the bytes field incorrectly assumed the VBRI frame itself was 128 bytes long:

  vbriFrameStart + avgFrameSize + bytes
= 1024 + 128 + 13603849
= 13605001

And this now exactly matches the file on disk.

Aside: We can also derive the MP3 data length from the VBRI frame size & count values: numFrames * frameSize = 2882048. This is clearly also incorrect in this file (but roughly consistent with the ToC).

Summary:

This file has a strange VBRI frame, with a ToC that only covers the first ~1:40 of the file, an incorrect average frameSize value, and an incorrect bytes value which assumes the VBRI frame itself is 128 bytes long (when it's actually 522 bytes long) - meaning it's wrong by 394 bytes.

If we switch to using the bytes field from the VBRI header then other parts of ExoPlayer's MP3 machinery handle the 394 length error fairly gracefully and playback continues for the whole duration of the file. I'll send a change for this.

This file has a strange VBRI frame, with a ToC that only covers the first ~1:40 of the file

This also results in seeking being broken/nonsensical for this file, because the VBRI ToC assumes that each of the N entries covers an Nth of the file. The result of this is that (with the bytes fix applied), when I play your file and seek near the end, playback continues well past the 9:48 'duration' - because the "seek near the end" actually resulted in us seeking near the end of the first 2255081 bytes, so there's lots more MP3 data left to consume.

Add MP3 test asset with `VBRI` frame

MP3: Exclude `VBRI` frame from ToC position calculations

MP3: Use `bytes` field from `VBRI` frame instead of deriving from ToC

This invalid file is now handled more gracefully after 46578ee

Add MP3 test asset with `VBRI` frame

MP3: Exclude `VBRI` frame from ToC position calculations

MP3: Use `bytes` field from `VBRI` frame instead of deriving from ToC

Navigation Menu

Repository navigation

Player moves to next item in playlist before completing previous item. #1904

Version

More version details

Devices that reproduce the issue

Devices that do not reproduce the issue

Reproducible in the demo app?

Reproduction steps

Expected result

Actual result

Media

Bug Report

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if (peekEndOfStreamOrHeader(extractorInput)) {
	return RESULT_END_OF_INPUT;
	}

	private boolean peekEndOfStreamOrHeader(ExtractorInput extractorInput) throws IOException {
	if (seeker != null) {
	long dataEndPosition = seeker.getDataEndPosition();
	if (dataEndPosition != C.INDEX_UNSET
	&& extractorInput.getPeekPosition() > dataEndPosition - 4) {
	return true;

Player moves to next item in playlist before completing previous item. #1904

Description

Version

More version details

Devices that reproduce the issue

Devices that do not reproduce the issue

Reproducible in the demo app?

Reproduction steps

Expected result

Actual result

Media

Bug Report

Activity

icbaker commented on Nov 22, 2024

icbaker commented on Nov 22, 2024

icbaker commented on Nov 26, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions