832147 - After seeking to an arbitrary point in Security Now podcast, the audio is off by 10-15 seconds (& consequently, we reach 0:00 remaining time too early, and the end of the podcast is cut off)

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Download this mp3...
       http://aolradio.podcast.aol.com/sn/sn0387.mp3
    ...and copy it onto your b2g device.
 2. Open the Music app, and start playing that file.
 3. Seek as close as you can to the end. (The closest I can get is ~1:30 from the end)
 4. Tap "Play" and let the remainder of the podcast play.

EXPECTED RESULTS: Podcast should end successfully -- with a bit of the show's theme song playing after the last bit of talking, brief silence, and then the end.

ACTUAL RESULTS: Podcast is cut off while people are still talking.  Specifically, the time-counter reaches 0:00 time remaining and ends the podcast early, when there are actually 10-25 seconds of time remaining (approximately -- from comparison to Totem, an audio player for Ubuntu desktop).

The time counter doesn't suddenly jump from 0:15 to 0:00 or anything -- it's just that the time-remaining is incorrect (off by 10-25 seconds) to start with, I think.

Comment 1

[Daniel Holbert [:dholbert]]

YouTube video demonstrating the problem (w/ audio from the podcast):
 https://www.youtube.com/watch?v=GAiojGjyJ9g

The app reaches 0:00 while the podcast is still going; then it plays another 1-2 seconds of audio, and then it abruptly stops playing & returns to the menu.

Comment 2

[Daniel Holbert [:dholbert]]

Build ID: 20130114070200

Comment 3

[Daniel Holbert [:dholbert]]

Easier STR: Just seek to an arbitrary point in the show on the phone; then, seek to the same time in a desktop MP3 player (in a separate copy of the file on your desktop machine).  The audio playing at that timestamp is generally different for me. (It's off by at least a few seconds.)

I think that's the underlying bug.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

CC-ing product to make the call on whether this is a) already known and perhaps part of audio feature work as well as b) whether a possible fix for this would be v1-next or v2

Comment 5

[Jason Duell]

cpearce/padenot,

Can you give us an assessment here?

Comment 6

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

Dunno. Maybe it's current time is slipping due to a rounding error in playback rate code somehow? Paul might have an idea about that.

Edwin Flores and Chris Double are our mobile video experts, Edwin's away, but Chris Double might have an idea?

Comment 7

[Paul Adenot (:padenot)]

Chris, the playbackRate feature is not in B2G, it has been landed after [1].

I can repro on a recent build, with the exact file mentioned in comment 0.

On a long, but shorter file (around 45min), I cannot reproduce.

With a podcast that lasts 3 hours and 18 minutes long, and I can't reproduce either. Both the 45min and the 3 hours file are mp3.

Also, mplayer on Linux reports a duration of 1 hour, 45 minutes and 7 seconds for the file in comment 0. My Firefox OS phone (Unagi, Gecko from yesterday, Gaia a bit older, but not much), the duration reported for the same file is 1 hour, 44 minutes, 37 seconds.

I did not investigate further, but I can if we feel that this is important.

[1]: http://mxr.mozilla.org/mozilla-b2g18/source/content/media/nsAudioStream.cpp

Comment 8

[cajbir (:cajbir)]

(In reply to Paul Adenot (:padenot) from comment #7)
> Also, mplayer on Linux reports a duration of 1 hour, 45 minutes and 7
> seconds for the file in comment 0. My Firefox OS phone (Unagi, Gecko from
> yesterday, Gaia a bit older, but not much), the duration reported for the
> same file is 1 hour, 44 minutes, 37 seconds.

Durations on MP3 files on B2G are estimates based on reading a few frames and calculating based on the bitrate.

Comment 9

[Paul Adenot (:padenot)]

Ha, then it probably interacts badly with this [1]. Is is possible to get an exact duration for mp3 files?

[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/Player.js#L651

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

If we can get a low-risk fix here into v1 that would be great, tracking.

Comment 11

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

(In reply to Paul Adenot (:padenot) from comment #9)
> Is is possible to get an exact duration for mp3 files?

No. Not without reading the entire file.

Comment 12

[Daniel Holbert [:dholbert]]

OK. If we can't do better than an estimate, perhaps the music app just needs to be fixed to allow music files that continue to play for a bit beyond our estimate for their duration? (rather than arbitrarily calling it "over" when we hit the estimate)

Comment 13

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

Yes. The music app should listen for the "ended" event that is dispatched when playback ends. There was a bug somewhere that caused this event not to be fired on B2G (bug 783512), but no one on the media team ever had time to look at it.

Comment 14

[Jim Porter (:squib)]

Does this still happen with the new music app?

Comment 15

[Pi Wei Cheng [:piwei] (inactive)]

Could you upload the test mp3 at comment 0 again?

Comment 16

[Daniel Holbert [:dholbert]]

Darn, yeah -- looks like comment 0's URL is 404. I don't have the mp3 handy, but a version of the same podcast is also available here: http://media.grc.com/sn/SN-387.mp3

Given the slightly-different filename, it might be a different re-encoding of the same audio, so it may or may not have reproduced the original bug.  But it's better than nothing I guess.

Comment 17

[Pi Wei Cheng [:piwei] (inactive)]

I was NOT able to reproduce the bug on Music nor on Music OGA. Specifically the following quoted behavior is NOT observed:

> Podcast is cut off while people are still talking. Specifically, the time-counter reaches 0:00 time remaining
> and ends the podcast early, when there are actually 10-25 seconds of time remaining

Current behavior observed on Aries and Flame:
The podcast correctly played to the end after I dragged it to near the end, however when it ended it was showing it still had ~30 seconds remaining to play. So it seems like the remaining time is wrong.

Scrubbing (dragging progress bar around) seems sluggish as well, though irrelevant to this bug.

Tested on:
Device: Flame 2.5 (319MB memory)
BuildID: 20151007030237
Gaia: 77d463a009a1425e413edaae92b237e116708560
Gecko: d1c5a7c5b4331ee9ea5443de893fcfd0a5b80e2a
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Aries 2.5
BuildID: 20151007142909
Gaia: 77d463a009a1425e413edaae92b237e116708560
Gecko: 263526a3368d6e94f31ff526b9f5beba46f56347
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 18

[Jim Porter (:squib)]

Let's resolve this then.

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to Pi Wei Cheng [:piwei] from comment #17)
> Current behavior observed on Aries and Flame:
> The podcast correctly played to the end after I dragged it to near the end,
> however when it ended it was showing it still had ~30 seconds remaining to
> play. So it seems like the remaining time is wrong.

:piwei, could you make sure a new bug is filed on this "however" issue? (unless it's already covered by some existing bug)

Thanks!

Comment 20

[Pi Wei Cheng [:piwei] (inactive)]

QAwanted to address comment 19

Comment 21

[Jim Porter (:squib)]

Filed bug 1212948