945864 - [B2G][Music] On occasion the duration of songs displays a large number

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Darren]

Attachment: Incorrect Duration for song

Repro Steps:
1. Updated Buri to Build ID: 20131203040236
2. Load some music on the device(Bluetooth, USB, or any other method)
3. Open up the music app
4. Tap on Artist view
5. Select one of the artists
6. immediately select a song before the album art loads completely

Actual Results:
The Songs duration displays as a very long number.

Expected Results:
The duration of the songs will displays the time remaining of the song.

Environmental Variables
Device: Buri v1.3 MOZ RIL
Build ID: 20131203040236
Gecko: http://hg.mozilla.org/mozilla-central/rev/8648aa476eef
Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b
Platform Version: 28.0a1
Base Build: 20131115

NOTES:
Seems to happen more often on initial load, so restarting the phone might help.
Repro Rate: 1/10

Comment 1

[Sotaro Ikeda [:sotaro]]

Darren, does it happen on any musc? Can you upload the music file?

Comment 2

[Jason Smith [:jsmith]]

Does this reproduce on 1.1 or 1.2?

Comment 3

[Darren]

Attachment: 01 Lip Gloss.mp3

I was able to switch back and forth with other songs and this song and was able to repro the issue. I did not have the issue happen on v1.2.

Comment 4

[Jason Smith [:jsmith]]

There's something really weird going on here. comment 3 might imply that this can happen more than 10% of the time.

Comment 5

[sarsenyev]

After following steps in the comment 3, the repro level is much higher than 1/10
I was able to get a regression window

The last working build (I couldn't reproduce it after trying many times)
Device: Buri 1.3 Central
BuildID: 20131202092621
Gaia: 8527840366eec3252d04e0dad64e7a40dbe3dc56
Gecko: 2581b84e0ca1
Version: 28.0a1
Firmware version: v1.2_20131115

The first broken build:
Device: Buri 1.3 Central build
BuildID: 20131203040236
Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b
Gecko: 8648aa476eef
Version: 28.0a1
Firmware version: v1.2_20131115

Comment 6

[Punam Dahiya [:pdahiya]]

Failed to replicate the issue in the below environment. Used the attached music file for testing and in both cases duration showed up as 03:39

Device: Hamachi 1.3 Central build
BuildID: 20131204040204
Platform Version 28.0a1
Gaia: 45564d6318cdab2fae2de0eb801308e2bcf4e472
Gecko: 5b4e54eb26a5b14435f0e35fd25a2da52aa0e2bb

Device Hamchi 1.4 Central build
BuildID:20131213040203
Platform Version 29.0a1
Gaia:dea74850442df6aff8405333a973d49a9f1af2ec
Gecko:5cfcfcf8a4c222a38d7f35ff70d3fb39b3abb129

Comment 7

[sarsenyev]

Just tried on the latest 1.3 build, the issue still reproduces
A song duration displays wrong info, however it doesn't reproduce with all songs

Device: Buri 1.3 Aurora Moz RIL
BuildID: 20131213004002
Gaia: 888f9df5515a47d2f5806efee77485e05e1e5416
Gecko: dfae9c83bfbc
Version: 28.0a2
Firmware Version: v1.2_20131115

Comment 8

[Dominic Kuo [:dkuo]]

I can also reproduce this issue but not sure what's the correct steps, and with one same file it's not 100% reproducible so I think this should be an audio decoding issue, changing the component to Video/Audio to catch the attention.

Comment 9

[Jason Smith [:jsmith]]

blocking+ for regression

Comment 10

[Kai-Chih Hu [:khu]]

(In reply to Dominic Kuo [:dkuo] from comment #8)
> I can also reproduce this issue but not sure what's the correct steps, and
> with one same file it's not 100% reproducible so I think this should be an
> audio decoding issue, changing the component to Video/Audio to catch the
> attention.

Maybe the variable(for the information) was not initialized? 
Or, there have some functional calls don't have an initialized returned value? 

Dominic, can you help to own and track this bug? Thank you.

Comment 11

[Dominic Kuo [:dkuo]]

Sure, although I don't know the root cause yet but I will first investigate it, I am leaving the needinfo flag in case I forget this one.

Comment 12

[Dominic Kuo [:dkuo]]

Update:

I found sometimes audio.duration returns 'Infinity' for the first timeupdate event which triggers the music player tries to read duration from audio.buffered, and audio.buffered returns a huge number which seems also not the value we expected, then caused the large number we saw in attachment 8341879 [details].

Chris, I am not sure who to ask about this issue, do you know who can help on this? thanks.

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

Thanks for bringing this to my attention Dominic. Edwin has been making changes to our MP3 duration calculations recently.

Edwin: Can you look into this please?

Comment 14

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Attachment: 945864.patch

Comment 15

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8359454 [details] [diff] [review]
945864.patch

Review of attachment 8359454 [details] [diff] [review]:
-----------------------------------------------------------------

I don't see the bug, but this is a good idea anyway...

Comment 16

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/10d56cf4ca6d

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/10d56cf4ca6d

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/724948445046