[B2G][Music] Track length for all songs in a Music app playlist (or album) counts down/up in rapid steps from length of previous track until correct

RESOLVED WORKSFORME

Status

()

Core
Audio/Video: Playback
RESOLVED WORKSFORME
4 years ago
2 years ago

People

(Reporter: Brogan Zumwalt [Inactive], Unassigned)

Tracking

({regression})

26 Branch
ARM
Gonk (Firefox OS)
regression
Points:
---

Firefox Tracking Flags

(b2g-v1.2 affected)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.
Keywords: qawanted
(Reporter)

Comment 3

4 years ago
(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.

Updated

4 years ago
QA Contact: jschmitt

Comment 5

4 years ago
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

Updated

4 years ago
Keywords: qawanted
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.
Keywords: qawanted
QA Contact: jschmitt → rkunkel
(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
Keywords: qawanted
Created attachment 8348425 [details]
34 Small Army.mp3
How many different mp3s were tested?
Flags: needinfo?(rkunkel)
(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.
Flags: needinfo?(rkunkel)
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?
Flags: needinfo?(tzimmermann)
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?
Flags: needinfo?(tzimmermann) → needinfo?(edwin)
(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.
Flags: needinfo?(edwin)

Updated

4 years ago
Component: Gaia::Music → Video/Audio
Keywords: regression
Product: Firefox OS → Core
Version: unspecified → 26 Branch
(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.
Component: Audio/Video → Audio/Video: Playback
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.