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

RESOLVED FIXED in Firefox 28

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: dwatson, Assigned: eflores)

Tracking

({regression})

unspecified
mozilla29
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:1.3+, firefox27 wontfix, firefox28 fixed, firefox29 fixed, b2g-v1.2 unaffected, b2g-v1.3 fixed)

Details

Attachments

(3 attachments)

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
Darren, does it happen on any musc? Can you upload the music file?
Flags: needinfo?(dwatson)
Does this reproduce on 1.1 or 1.2?
Keywords: qawanted
Posted audio 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.
Flags: needinfo?(dwatson)
There's something really weird going on here. comment 3 might imply that this can happen more than 10% of the time.
blocking-b2g: --- → 1.3?
QA Contact: 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
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
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
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.
Component: Gaia::Music → Video/Audio
Product: Firefox OS → Core
blocking+ for regression
blocking-b2g: 1.3? → 1.3+
(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.
Flags: needinfo?(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.
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.
Flags: needinfo?(dkuo) → needinfo?(cpearce)
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?
Flags: needinfo?(cpearce) → needinfo?(edwin)
Posted patch 945864.patchSplinter Review
Attachment #8359454 - Flags: review?(cpearce)
Flags: needinfo?(edwin)
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...
Attachment #8359454 - Flags: review?(cpearce) → review+
https://hg.mozilla.org/mozilla-central/rev/10d56cf4ca6d
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in before you can comment on or make changes to this bug.