Description: All tracks in a multi-track playlist or album initially display incorrect "time-remaining", counting down or up from length of previous song played until the correct time remaining length is reached. Repro Steps: 1) Updated Buri to Build ID: 20131205004003 2) Open music app (with multiple songs in library) 3) Tap playlist icon 4) Select "Shuffle All" 5) Press "Next Track" button Actual: Time remaining count for all songs in a playlist counts up or down to correct time. Expected: On start of song, all tracks display correct "time remaining" count. Environmental Variables Device: Buir v 1.2 COM RIL Build ID: 20131205004003 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/af2c7ebb5967 Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a Platform Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: V1.2_US_20131115 Notes: Repro frequency: 3/3, 100% See attached: video clip - http://www.youtube.com/watch?v=cl0CcB3IEdM
Are you using MP3s? We need to look at all of an MP3's content to compute it's duration, but we need to load it in small chunks for performance reasons. So while the MP3 loads, the duration is incorrect. Maybe the estimated duration can be improved, but the problem is inherent to the file format.
Does this reproduce on 1.1? Also - we need to address comment 1's question.
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #1) The files I tested were all MP3's
You should read through bugs 831224 and 918135. I think the latter added support for MP3 extensions that store the correct duration for the whole file. Plain MP3 doesn't support this.
Does Not reproduce in Buri 1.1, the correct time remaining is being shown. Buri 1.1 Environmental Variables: Device: Buri v1.1 COM RIL BuildID: 20131206041202 Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f Gecko: 05117f42088f Platform Version: 18.1 RIL Version: 01.01.00.019.281 Firmware Version: v1.2_20131115
I need more information to conclude this is truly a regression. Can we specifically: 1. Can test mp3 files included on the bug for testing this? 2. Test with these mp3 files on a 1.2 & 1.1 build The problem with the above rationale in comment 5 is that the audio files in use could be different than the reporter's, which might mean that the testing isn't conclusive on proving this is a regression.
(In reply to Jason Smith [:jsmith] from comment #6) > 1. Can test mp3 files included on the bug for testing this? I spoke with Brogan and was able to retrieve the .mp3 files used to file the original bug. > 2. Test with these mp3 files on a 1.2 & 1.1 build This does not reproduce in the latest Buri v1.1 build. The time stamps were shown as expected without any sporadic behaviour. 1.1 Environmental Variables: Device: Buri v1.1 Mozilla RIL BuildID: 20131214040201 Gaia: 4795e1f663b26e03268cfd8e1a168f413b2bd396 Gecko: 9d593727eb94 Version: 29.0a1 RIL Version: 01.02.00.019.102 Firmware Version: V1.2_US_20131115 This does reproduce with the latest Buri v1.2 build. Out of the .mp3 files provided only one of the .mp3 files was shown to have a sporadic end time stamp. Attaching the specific .mp3. Environmental Variables: Device: Buri v1.2 COM RIL BuildID: 20131216004002 Gaia: fcf1c2fe020c29da4755621cbffdc1a333a43be9 Gecko: 129ad3c335a5 Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: V1.2_US_20131115
How many different mp3s were tested?
(In reply to Jason Smith [:jsmith] from comment #9) > How many different mp3s were tested? Brogan sent me 3 .mp3 files that he used in the original bug. I tested with those.
Tom - Do you have any idea how likely a user would come across this bug that has the same problem demonstrated in the attached mp3 file?
Sorry for the long delay here. I just came back from PTO. I have no idea how often this 'bug' can be seen in practice. It depends on the mp3 file having variable bit rate, and the bit rates themselves. There are extensions to mp3 for handling this problem. I think we do support them in m-c. BTW, I can see a similar problem with the Rhythmbox music player on my Linux computer. It never shows the correct duration for affected files, but just assumes constant bit rate for all mp3s. @edwin: Does the latest version of the mp3 frame parser support XING or VBRI?
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #12) > @edwin: Does the latest version of the mp3 frame parser support XING or VBRI? Both. The attached file seems to have a Xing header; at a glance I'm not sure why it's going wrong. Might have time to have a deeper look later.
(In reply to Roland Kunkel [:RolandK] from comment #7) > This does not reproduce in the latest Buri v1.1 build. The time stamps were > shown as expected without any sporadic behaviour. > > 1.1 [...] > Version: 29.0a1 > > This does reproduce with the latest Buri v1.2 build. [...] > Version: 26.0 Why does the 1.2 build have such an old version of Gecko? I fixed a bunch of MP3 bugs in the last couple months; this is likely a non-issue that will go away with a more recent Gecko.