Closed Bug 833517 Opened 12 years ago Closed 12 years ago

[music] Sometimes when the song switches on it's own, you will hear 1 second of a different song and then it will switch to another song.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g18+ fixed, b2g18-v1.0.1 fixed)

RESOLVED FIXED
blocking-b2g -
Tracking Status
b2g18 + fixed
b2g18-v1.0.1 --- fixed

People

(Reporter: nhirata, Assigned: rudyl)

Details

Attachments

(2 files)

## Environment : Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/0e43266ca3c6 Gaia 1890022f3ca36108621a832f31ac5df8bf89a22e BuildID 20130122070203 Version 18.0 Unagi ## Repro : 1. launch music app with more than 3 songs 2. play a song from the mixed album page 3. wait til the song switches to the next song ## Expected : 1. the next song plays right ## Actual : 1. sometimes a song will play for a moment (1 sec) and switch to another song. ## Note : Maybe this occurs because it already hit the next song and then the thread is getting killed? 01-22 12:14:01.345: D/memalloc(108): /dev/pmem: Allocated buffer base:0x4a600000 size:36864 offset:1474560 fd:103 01-22 12:14:01.345: D/memalloc(734): /dev/pmem: Mapped buffer base:0x49c45000 size:1511424 offset:1474560 fd:100 01-22 12:14:01.375: E/QC_MP3DEC(734): Execute flush for both I/p O/p port 01-22 12:14:01.375: E/QC_MP3DEC(734): Killing timer thread... 01-22 12:14:01.375: E/QC_MP3DEC(734): Timer thread exited 01-22 12:14:01.375: E/QC_MP3DEC(734): Component-deinit m_drv_fd = -1 01-22 12:14:01.375: E/QC_MP3DEC(734): COMPONENT DEINIT... 01-22 12:14:01.375: E/QC_MP3DEC(734): OMX MP3 component destroyed 01-22 12:14:01.385: D/memalloc(108): /dev/pmem: Freeing buffer base:0x4ac63000 size:8192 offset:6696960 fd:192 01-22 12:14:01.445: D/memalloc(734): /dev/pmem: Unmapping buffer base:0x495a8000 size:6705152 offset:6696960 01-22 12:14:01.465: E/OMXCodec(734): Attempting to allocate OMX node 'OMX.qcom.audio.decoder.mp3' 01-22 12:14:01.475: E/QC_MP3DEC(734): component_init[0x446b5000]component init: role = OMX.qcom.audio.decoder.mp3 01-22 12:14:01.475: E/OMXCodec(734): Successfully allocated OMX node 'OMX.qcom.audio.decoder.mp3' 01-22 12:14:02.016: D/memalloc(108): /dev/pmem: Freeing buffer base:0x4aa87000 size:81920 offset:4747264 fd:173
This happens often enough for me to be really annoying.
blocking-b2g: --- → tef?
blocking-b2g: tef? → -
tracking-b2g18: --- → +
Naoki, does this always happen on the same song? (play for a moment (1 sec)) I guess it might be some VBR mp3 to cause this problem. Please see bug 831224, maybe you can get some clues.
blocking-b2g: - → tef?
tracking-b2g18: + → ---
This issue is talking about: After the 1st song ends, the 2nd song would be played for a short time, and then we skip to the 3rd song in the playlist. ** Notes for Triage ** 1. For my test, it is quite easy to reproduce this issue, you only need to play songs from Mixed album page or just pick an album from the album list to play. -- [Root Cause] 1. We have a workaround for Bug 783512 to invoke next() to play the next song when the played song is about to end. This logic may have a defect to produce this order, a. invoke setTimeout() to create a timer for next() b. the timer is triggered -> clear the timer variable -> invoke next() c. invoke setTimeout() again for the same song, that is why it skipped to the 3rd song Please refer to the debug logs as attached.
Comment on attachment 705822 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7776 Dear Dominic, Please help review this patch. Thanks for your guidance on the code path. :)
Attachment #705822 - Flags: review?(dkuo)
It's annoying but as it isn't consistent, it happens on different song and not twice on the same song, we would track it.
blocking-b2g: tef? → -
tracking-b2g18: --- → +
Assignee: nobody → rlu
Blocks: 834529
No longer blocks: 834529
Comment on attachment 705822 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7776 r+, looks good to me. From Rudy's attached log we can see, The root cause is because the next() will be triggered twice, due to we set the endedTimer to null before it's time to play next song, but a timeupdate event from the previous song will still called again then triggers another next(). To prevent this, Rudy's patch does not clear the endedTimer before calling next(), and move the part that clear the endedTimer into setAudioSrc(), which is the async callback of musicdb.getFile(), this can make sure before Music plays the next song, any timeupdate event will not trigger another next()(because endedTimer is not "null").
Attachment #705822 - Flags: review?(dkuo) → review+
I remember video in Gallery also used this workaround in Bug 783512, not sure that workaround already caused an issue or not, ccing David first to let him know about this.
Comment on attachment 705822 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7776 [Approval Request Comment] Bug caused by (feature/regressing bug #): a workaround for Bug 783512. User impact if declined: the repeat mode for music playback could not work normally. Testing completed: Yes Risk to taking this patch (and alternatives if risky): low.
Attachment #705822 - Flags: approval-gaia-v1?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 705822 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7776 Approving low-risk, tested fix for uplift to v1-train
Attachment #705822 - Flags: approval-gaia-v1? → approval-gaia-v1+
v1-train: e96607d2ae42944cabbfb3e94c157f780834d890
Batch edit: bugs fixed on b2g18 since 1/25 branch of v1.0 are fixed on v1.0.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: