[1.Description]: [Flame][v2.2&v3.0][Music]Drag the progress bar to end while it is one song repeation mode, the played time may be incorrect, and the song will not be played. Found time: 8:59 AM Attachment:logcat_859.txt & v859.mp4 & 859.png & Test.mp3; [2.Testing Steps]: 1. Launch Music 2. Play a song 3. Tap "Circle" twice to switch to one song repeation mode 4. Drag the progress bar to the end [3.Expected Result]: 4. The played time should be correct and the song will be played from the beginning again. [4.Actual Result]: 4. The played time will be incorrect and the song will not be played. [5.Reproduction build]: Flame 2.2 (affected) Build ID 20150331162505 Gaia Revision 8b3086ad3963f1707e2bee9094baccafffe161c4 Gaia Date 2015-03-31 21:48:06 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/88e0e00cd64e Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150331.200333 Firmware Date Tue Mar 31 20:03:44 EDT 2015 Bootloader L1TC000118D0 Flame 3.0 (affected) Build ID 20150331160205 Gaia Revision 03164bd160809747e6a198e0dba1b7c3ee7789f5 Gaia Date 2015-03-31 14:48:14 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/18a8ea7c2c62 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150331.191641 Firmware Date Tue Mar 31 19:16:50 EDT 2015 Bootloader L1TC000118D0 [6.Reproduction Frequency]: occasionally Recurrence,2/10 [7.TCID]: Free Test [8.Note]: It's easy to reproduce this issue with some music files, so please use "Test.mp3" to reproduce this issue. Can't reproduce this issue with some other music files.

Hi, Paladin, May I have your help? Can it be reproduced with latest v2.1 build? Many thanks.

Hi William, This problem can be reproduced on latest build of Flame 2.1 with the Test.mp3 file in comment 3 and any other music file. But i have met two cases: 1. After dragged the progress bar to the end, the played time is displayed incorrectly for a short time, then music continues playing. 2. After dragged the progress bar to the end, the played time is displayed incorrectly all the time and music stops playing. STR: 1. Launch Music 2. Play a song 3. Tap "Circle" twice to switch to one song repeation mode 4. Drag the progress bar to the end. 5. If issue cannot be reproduced repeat step 3 and step 4. See attachment: Flame2.1_logcat_2210.txt Rate: 4/30 Device: Flame 2.1(Affected) Build ID 20150406001204 Gaia Revision 87e55a7ec688138812181747f690fd188d2a0668 Gaia Date 2015-04-03 21:43:01 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/747b6132c44d Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150406.034925 Firmware Date Mon Apr 6 03:49:36 EDT 2015 Bootloader L1TC000118D0

See video:VIDEO1287_Compress.MP4

[Blocking Requested - why for this release]: Thanks Shine. --- -- - --- -- - --- -- - --- -- - This defect has existed on FxOS for a long time. But, the reproduction rate is low. Suggest to improve it on the latest branch or put to backlog. Many thanks!

I've tried this about 50 times with various songs in my collection and can't reproduce it at all. Can we have QA take another look?

Hi Jim, This bug still can be repro on latest Flame KK v2.5 by the STR in comment 5, but can't be repro on Aries KK v2.5. Could you take a look at this please? Thank you very much. Actual results: On the Flame KK v2.5, the played time is displayed incorrectly for a short time, then music continues playing or stops playing. --KO On Aries KK v2.5, the played time (00:00) is displayed correctly. See attachments: new_FlameKK_v2.5.3gp and logcat_0708_FlameKK_v2.5.txt Reproduce rate: 6/10(FlameKK), 0/30(AriesKK) Device: Flame KK 2.5 (Affected) Build ID 20150826150203 Gaia Revision c1ae9f02f2a9cfb89bf67aeea97e467c41c3362c Gaia Date 2015-08-25 22:03:05 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/fea87cbeaa6b64510dff835549ed906fe405d558 Gecko Version 43.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150826.182949 Firmware Date Wed Aug 26 18:30:01 EDT 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Aries KK 2.5(Unaffected) Build ID 20150826212128 Gaia Revision c1ae9f02f2a9cfb89bf67aeea97e467c41c3362c Gaia Date 2015-08-25 22:03:05 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/fea87cbeaa6b64510dff835549ed906fe405d558 Gecko Version 43.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150826.204803 Firmware Date Wed Aug 26 20:48:11 UTC 2015 Bootloader s1

Are you sure you didn't hit the end of the playlist when it left the player view? Even in the video, it seems to work almost all the time, and always works when "Repeat" is active.

Er, to clarify: if a song is alphabetically the last one in the list and repeat is off, then there are no songs after it, so ending that song means the playlist is over. That appears to be what's happening in the video, in which case this is working as intended.

Removing from release blocking queue based on reproducibility and attached video.

I can reproduce this issue on NGA & OGA music app of FlameKK/AriseKK v2.5 latest build by STR in comment 5. Actually result: When device played Test.mp3,then dragged the progress bar to the end, the played time is displayed correctly all the time but music stops playing. Reproduce rate: 10/10 See NGA_FlameKK_v2.5.3gp Device: Flame KK v2.5(Affected) Build ID 20151007150205 Gaia Revision b99837aa2294348317bcae68acabe71d9a83d774 Gaia Date 2015-10-07 13:04:16 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/1e1fa696e2b626ead6817b7c5bd871fec5d5ab5a Gecko Version 44.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20151007.183338 Firmware Date Wed Oct 7 18:33:51 EDT 2015 Bootloader L1TC000118D0 Device: Aries KK master(Affected) Build ID 20151008002716 Gaia Revision b99837aa2294348317bcae68acabe71d9a83d774 Gaia Date 2015-10-07 13:04:16 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/c6ede6f30f3dc886543bb1c76fd7c8b5a151786b Gecko Version 44.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151007.234555 Firmware Date Wed Oct 7 23:46:03 UTC 2015 Bootloader s1

(In reply to Paladin from comment #3) > Created attachment 8586698 [details] > Test file: test.mp3 This MP3 appears to be corrupt. The issue has nothing to do with the scrubber/seek bar. If you download this file, it will stop playing about 40+ seconds in.

Comment on attachment 8671666 [details] [gaia] justindarc:bug1149930 > mozilla-b2g:master Patch to bail out on corrupt media files during playback. This simply will skip to the next song in the queue. Also had a lightbulb moment and fixed a linter issue while I was in there :-)

Landed on master: https://github.com/mozilla-b2g/gaia/commit/6f59de432c2ae55e915578104f329c40d8b1d454

This seems to have made Gij10 extremely intermittent. Also seen on your gaia try results on the pull request. Backing this out.

reverted in https://github.com/mozilla-b2g/gaia/commit/d400cda6bf0f8b30dcf7d7d71bfa61f29a3f1588 seems nigel was planning this but never happened :) so reverted

Updating the summary to clarify the issue here.

Comment on attachment 8673839 [details] [gaia] justindarc:bug1149930 > mozilla-b2g:master Carrying over R+

One caveat that we might want to take into account: if we end up with lots of busted (or deleted?) songs, immediately skipping to the next track could cause some weird UX. foobar2000 works around this by adding a short delay before skipping over a busted track.

That said, it might not be a problem for us, and I don't think we'd need to fix that for 2.5. Just something to think about, though.

Ooh, another thing I just thought of: what happens if we hit an error like this in the open activity? (Or the pick activity for that matter.) Going to the next song doesn't make sense there.

(In reply to Jim Porter (:squib) from comment #28) > Ooh, another thing I just thought of: what happens if we hit an error like > this in the open activity? (Or the pick activity for that matter.) Going to > the next song doesn't make sense there. Yeah, good point. I'm still running into issues with tests with this patch (only on treeherder), so I'll update the patch to deal with some more of these edge cases.

Paul, The test run on gaia-try with apparently PULSE_SERVER=":" This cause playback errors which this patch is now handling gracefully instead of ignoring, making any other playback test fail as a side effect. Do you have any idea on how this could be solved? I can file a bug if you say it is indeed a bug Thanks

Cancelling the NI. We filed platform bug 1215272 instead. Thanks.

Should we really be blocking on this? Comment 0 says it happens on 2.2 as well as 2.5, and given that we're blocked by the fact that our test infrastructure is bad, it might make more sense to remove blocking status and just fix it for 3.0.

[Blocking Requested - why for this release]: See comment 33.

There was a mis-understanding in the last triage that this bug happens more often and that user is stuck as we don't skip on the corrupted mp3 file (hence the priority was raised from p3 to p1). But after talking through this case and testing, the user has a workaround to tap manually to get to the next song. Therefore removing P1 and blocker flag. However, we need to get the test infrastructure fixed (see dependent bugs) to handle running the automated test case for this scenario. Thanks Hema

Not working on this. Unassigning myself.

Firefox OS is not being worked on