Samsung devices: Local or networked mp3 file plays twice rather than ending

[kimdohyung5]

Before filing an issue:

When reporting a bug:

Issue description

When I Played the mp3 file, I didn't get the result "Player.STATE_ENDED" right after the mp3 file was finished.
I think that It happened in library version over 2.8.0 and not happened below 2.7.3
and I expected that it would have fixed in the version 2.8.2 but, It didn't happed.

Reproduction steps

Very simple.. when you play the mp3 file in the sample app then, you can find that i am right.

Link to test content

any contents in the name of mp3s.

Version of ExoPlayer being used

it has the problem over 2.8.0 but, is ok below 2.7.3

Device(s) and version(s) of Android being used

i am using the samsung's s-pad device (SM-T 530)

A full bug report captured from the device

I don't have the error message because it isn't the error when think otherwise.

so I have to attach the sample source which i tested. so that you can find what i mean easily.

ExoAudioTestWithActivity.zip

[ojw28]

I downloaded the test app but cannot reproduce. The mp3 file (duration 2:42) played, the ended event was triggered and the toast you've added was displayed as expected.

[ojw28]

Closing for now because everything seems to work fine. Please provide additional information here if you want us to look again, and we'll re-open.

[kimdohyung5]

After I received your comment, I realized that I just tested the demo app only on the samsung device
which is samsung pad( Samsung GALAXY Tab 4 10.1 ) and model name is SM-T530.

I tested other devices such as LG Pad , Samsung mobile phone and many others but I didn't make the same
bug unfortunately.

I recorded the bug scene and attached below and attached the source code again.
I would be happy if you comment some happy news.

below is the source code.
ExoAudioTestWithActivity_2018.07.18.zip

below is the bug scene which I captured.
20180718_148_rescale.zip

[ojw28]

That's really weird. Please could you provide the output of adb bugreport captured shortly after the point at which the looping occurs?

[kimdohyung5]

I captured the adb bugreport after looping occured.

adbbugreport_2018_07_19.txt

[ojw28]

Unfortunately the important bits are for some reason missing from the bug report. Could you instead try running adb logcat > logcat.txt (start the command when you start the first playback, and kill it at some point after the looping occurs), and providing the captured log? Thanks.

[kimdohyung5]

I logcated two files under one device with difference exo versions( v2.8.0 vs v2.7.3).
One file was logcated under v2.8.0 version and has the issue.
logcat_issue_v2.8.0_2018_07_20.txt

The other was logcated under v2.7.3 version , which works well.
logcat_nonissue_v2.7.3_2018_07_20.txt

I Hope you have good news.
Thanks.

[ojw28]

Are you using the standard ExoPlayer demo app? I'd expect logging from ExoPlayer's EventLogger component if so, but I don't see any. That's the logging I'm really interested in. Any idea why it's missing?

[kimdohyung5]

I didn't know you need that EventLogger.
I suppose that the ExoPlayer demo app has the EventLogger added.
so, I logged with ExoPlayer demo app.

Here is the logs.
one is adb log and the other is adb bugreport.
so I hope it helps the error would be gone.

adb_bugreport.2018.07.23.txt

adb_logcat.2018.07.23.txt

Thanks.

[Artemych]

Hello!

I found the revision where it was broken 3c78dc22.

This is due to on some devices MediaCodec.BufferInfo.size is not equal to zero when (outputBufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0.

[ojw28]

Interesting find, but how does the last output buffer being non-empty result in the described behavior? The only thing I can think of is if the last buffer somehow spuriously contains the entire stream again, but perhaps I've misunderstood.

[Artemych]

@ojw28 Do you need any logs or report?

[ojw28]

Given you can reproduce the issue, I was hoping you could debug further and explain exactly what's happening. I doubt we'll be able to figure it out from the logs.

[kimdohyung5]

My Device "the samsung's s-pad device (SM-T 530)" is still not working properly when playing mp3.

I recently found the below log when it ended playing mp3 and entered the dummy stage.

[log]
08-29 09:15:34.255 10788-10893/? E/AudioTrack: Discontinuity detected [expected 582529568, got 0]

I downloaded the exoplayer source code which currently available in github.com and then found the exact match line

"library\core\src\main\java\com\google\android\exoplayer2\audio\DefaultAudioSink.java" line 673
Log.e(TAG, "Discontinuity detected [expected " + expectedPresentationTimeUs + ", got "
+ presentationTimeUs + "]");

so It would be great that you could fix the problem, and I want to know how to addListener to DefaultAudioSink to catch that event.
When I added method "addListener, addAnalyticsListener" to the Player, I found that they report many infos but didn't show What I want.
and I couldn't access to the DefaultAudioSink properly.

So It would be great to know how to add listener to DefaultAudioSink.

[ojw28]

I suspect the SOC vendor provided MP3 decoder just isn't doing the right thing on this device. Does it fix things if you modify MediaCodecUtil.isCodecUsableDecoder to perform the following check at the top of the method:

if ("OMX.SEC.mp3.dec".equals(name)) {
  return false;
}

If so, we can probably put a targeted workaround in place to fix this (similar to adding the code block above, but additionally targeted to the specific problematic device).

[kimdohyung5]

Yes, It worked fine when I added the code block you gave .
When I added the suggested line to the demo app, I found that the player finishes properly.
So it will be great if you add that code block in the next library release.
Thank you.

[mseroczynski]

It seems like I've encountered the exact same issue repeatedly on Samsung GT-I9515 4.4.2 and SM-G350 4.2.2

[ojw28]

@mseroczynski -

• Could you confirm that these devices both use the OMX.SEC.mp3.dec decoder for MP3 playbacks? The names of the decoders used are printed in the logcat logging during playback (look in the logs for "OMX."), so it should be pretty easy to find out.
• If these devices do use OMX.SEC.mp3.dec, please test whether adding them to the workaround resolves the problem. If it does, please either send us a pull request, or tell us the exact values of Util.MODEL and Util.DEVICE for these devices.

Thanks

[mseroczynski]

I'm sorry but I'm currently super busy (I'm overloaded with migrating many legacy apps to targetSdk=26 before November 1st) but for now I can confirm that downgrading to 2.7.3 fixed the problem.

[ojw28]

Those devices appear to have different chipsets, so it doesn't appear to be exactly the same. I suspect a different decoder is used. I think we'll need more information to add workarounds for those, including Util.MODEL and Util.DEVICE for those devices, the name of the decoder being used, and whether applying a similar workaround to the one in the commit ref'd above fixes the problem. Please file a new issue when you're in a position to provide it.

[dungnn1991]

I have exact same issue on Samsung SM-T231, GT-I9152, GT-P5220. Can we use "omx.google.mp3.decoder" to avoid this problem ?

[ojw28]

@dungnn1991 - Please send a pull request to dev-v2 that blacklists the problematic decoder on the affected devices (only), similar to c3c309b. Thanks!

[ojw28]

Reopening to try and better understand the extent of the problem [Internal tracking ref: 121260468].

[ojw28]

TODO:

1. Add SM-G386T to the blacklist.
2. For each model currently in the blacklist, check for variant model names and make sure they're also blacklisted (using startsWith rather than equals is probably a good idea).
3. Follow up with Samsung.

[rnekicOD]

I believe I'm also seeing this issue on multiple Galaxy S3's (SCH-I535 with 4.4.2). STATE_ENDED does not occur, the playhead position resets to the beginning of the file. Oddly, I don't hear any audio at that point, although the playhead is still progressing. I can confirm this started with ExoPlayer v2.8.0 and is still present in v2.9.3

If I setRepeatMode to Player.REPEAT_MODE_ONE or ALL, the device does properly repeat the track after it ends and playback seems normal. But with REPEAT_MODE_NONE, playback does not end cleanly.

I don't know if it matters but the player returns different durations for the same file when I test with ExoPlayer v2.7.3 (working) vs v2.8.0+ (not working). The v2.8.0+ ExoPlayers are indicating the file is over 20,000 MS longer than the 2.7.3 player says it is.

[rnekicOD]

Actually, our two Galaxy S3s are different models:

SCH-I535
d2vzw
Android 4.4.2 Build KOT49H.I535VRUDNE1
I/OMXCodec: Attempting to allocate OMX node 'OMX.SEC.mp3.dec'

SPH-L710
d2spr
Android 4.4.2 Build KOT49H.L710VPUDOH1
I/OMXCodec: Attempting to allocate OMX node 'OMX.SEC.mp3.dec'

[ojw28]

I don't know if it matters but the player returns different durations for the same file

Please can you provide the media file that you're seeing this with? This is unlikely to be device specific (although the repeating part might be).

[rnekicOD]

Unfortunately, I cannot provide example files. I'm working with large, copyrighted audiobook files. You are correct, I see the same differences in duration between v2.7.3 and v2.9.3 on a Pixel 2 where there are no playback problems. I just checked multiple files and the two ExoPlayer versions consistently report different durations for the same files. It doesn't seem to be file specific.

[ojw28]

I suspect the duration differences are the result of an intentional change (not sure which one, but @andrewlewis might). For the playing-twice issue, I guess we need to add SCH-I535 and SPH-L710 to the blacklist.

[andrewlewis]

Regarding the duration change, there was a fix for constant bitrate MP3s in 975ed6c. This should make audio frame timestamps consistent when playing from the start vs with seeking and the duration calculation.

[mseroczynski]

I had to downgrade back to 2.7.3, many phones seem to still have codec related problems on 2.9.3. I think choosing codecs in MediaCodecUtil should be prioritized (not first in returned list). Are you guys using this updated (2.7.3+) EP version in apps like Youtube / Google Play Music? No bug reports, really..? Just asking.

[ojw28]

Some of our internal apps are using 2.9.x. Note that YouTube doesn't play mp3s, as far as I'm aware. "many phones seem to still have codec related problems on 2.9.3" is vague to the point of being non-actionable. If you have issues, please provide concrete details and we'll fix them.

[rnekicOD]

I think the point here is this issue seems to be pretty common with older 4.4.x Samsung devices and they notoriously release dozens of minor hardware variations which all have unique model names. Blacklisting by specific models is helping but surely dozens of others remain affected. We can report models that we have in our device collection and, for example, 2.9.4 should now work for the devices we happen to have but we are still reluctant to move forward from v2.7.3 because of models that remain unblacklisted that would suddenly come out of the woodwork if we rolled out v2.9.x.

[rnekicOD]

One alternative we are considering is raising our minSdkVersion from 14/4.0 to 21/5.0 so we can at least leave potentially affected users with a version of the app that works after we move forward with ExoPlayer 2.9.x.

[ojw28]

We could just blacklist OMX.SEC.mp3.dec on all Samsung devices prior to API level 21. That should catch all affected devices, although probably quite a few that do not have the issue as well. Thoughts?

[ojw28]

The much wider fix ref'd above should address this issue on all pre-Lollipop devices. We're not aware of any Lollipop+ devices that are affected, but if you've seen this please let us know.

[ojw28]

The wider fix has been released in 2.9.5.

[getyoteamsolutions]

I found the same issue, network mp3 file is not properly finished, just played twice when I used 2.9.6 exo library. I tested in two different devices.

1. Moto G Play
2. Mi Phone
3. Emulator also having same issue Nexus s/Nexus 9/Pixal 3

[ojw28]

@getyoteamsolutions - Please provide complete information about the devices. The informal names aren't sufficient for us to be able to apply the workaround. Can you capture a bugreport with adb bugreport from each device, in each case captured shortly after the start of an MP3 playback? Thanks.