Closed Bug 1113881 Opened 10 years ago Closed 9 years ago

[Music][Song View] Player can reach a state of perpetual fastforward/rewind/play-pause

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.0M unaffected, b2g-v2.1 verified, b2g-v2.1S verified, b2g-v2.2 verified, b2g-master verified)

VERIFIED FIXED
2.2 S5 (6feb)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.0M --- unaffected
b2g-v2.1 --- verified
b2g-v2.1S --- verified
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: onelson, Assigned: squib)

References

()

Details

(Keywords: regression, Whiteboard: [2.2-Daily-Testing])

Attachments

(5 files)

Summary (title) Field:
[Music][Song View] Player can reach a state of perpetual fastforward/rewind/play-pause
  
Description:
When performing multiple hold taps on the user play-control buttons [play-pause/fastforward/rewind], the Music app can reach a state where the song is constantly fast forward, constantly rewinding (essentially staying at 0:00 with the first tick of music playing repeatedly). A state was also seen where the song was constantly ticking between play and pause, causing the song to play extremely slowly as it is only able to play a fraction of a second every second: the time does slowly progress though.
The most common (and demonstrated in the video) results from these steps is breaking the ability to pause while in a song. Song is always playing and cannot pause.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141219040202
2) Open the 'Music' app.
3) Begin playing a song.
4) Hold tap on the 'Play' button. Observe highlighted button.
5) Hold tap on the 'Fastforward' button.
6) Hold tap on the 'Rewind button'.
7) Repeat steps 4, 5 and 6 continously.
  
Actual:
Music playing breaks and constantly rewinds, fastforwards or trying to play when paused or pause when playing breaks. Requires restart of app to fix.
  
Expected: 
Music plays normally according to button presses.
  
Environmental Variables:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141219040202
Gaia: deb90229734e5397cda806fb11f2e001fba83399
Gecko: 021b09e92d30
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
  
  
Repro frequency: 4/8
See attached: 
video- http://youtu.be/kybP2sqflQ8 [demonstrates pause button not working]
logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [2.2-Daily-Testing]
From the youtube video, I only see the play-pause button was unable to pause the music player, but didn't enter a perpetual fastforward/rewind state.
Demonstration of fast forward being held. After leaving the song focus, it appears to have resolved itself.
http://youtu.be/vyfUdEDHyQU
qawanted for branch checks.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
I was able to reproduce the pause button not working issue (though it fixes itself on the next song), but NOT the perpetual fastforwarding/rewinding issue on Flame 2.1.

Device: Flame 2.1 (shallow flash 319MB)
BuildID: 20141222071650
Gaia: 1a58335917b23c170d85bf821f658e964c935b23
Gecko: 5509822354a9
Version: 34.0 (2.1)
Firmware: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

-----

This issue does NOT reproduce at all on Flame 2.0. Play/Pause button, Fastforward button, and Rewind button all work as expected regardless of how I tap hold or tap on them.

Device: Flame 2.0 (shallow flash 319MB)
BuildID: 20141222071429
Gaia: ce83ea7b8e3fa2d1c3fd771fc22b654c18b3c381
Gecko: 7d0adaf6c447
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-------

Marking 2.1 as affected even though only 1/3 of the bug reproduces on the branch.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
NI Music owner for blocking decision / assignment
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(npark)
[Blocking Requested - why for this release]:
Blocking since it is relatively easy to reproduce (by holding the button icons)
blocking-b2g: --- → 2.1?
Flags: needinfo?(npark)
dominic/hema,

Do you need any additional QA help to move forward here ? I need your input in blocking a blocking decision here because i tried reproducing and seeing the impact but was unsuccessful. But when I read the description if the user ends up hitting this bug, he may have to restart the app, which isn't that pretty :-/
Flags: needinfo?(hkoka)
Flags: needinfo?(dkuo)
Jim or Dominic,

Please take a look at the "Non-functional Pause button issue". From the comments it looks like the other issue of perpetual fast forward is not easily reproducible. 

THanks
Hema
Assignee: nobody → squibblyflabbetydoo
Flags: needinfo?(hkoka)
I think this might be a hard to reproduce race condition.  Would it be possible to get some ideas in what race conditions might cause something like this so QA can reproduce this better?
Attached file Fix it
Ok, this patch does two things:

1) It ensures that we update our internal state correctly when we stop seeking. I think there was a Gecko change that caused us to no longer see the "play" event after we stopped seeking, so `playStatus` was always FWD_SEEK (or REV_SEEK). Now, we handle that ourselves.

2) It changes the play/pause button so that it plays or pauses based on what the button looks like, not what the playStatus is. That way, if we ever get into an inconsistent state again, tapping the play/pause button will still do what you'd expect. With this change, a bug like what I fixed in part 1 couldn't cause any problems.

I didn't write any tests, since this is kind of hard to reproduce programmatically. I could try to write some if we think this is really important to test, but I'm not sure of the best way to trigger it consistently. I can usually trigger the bug by rewinding while playing, but not always. This might be the sort of thing that just needs a manual test.
Flags: needinfo?(dkuo)
Attachment #8552606 - Flags: review?(dkuo)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9)
> I think this might be a hard to reproduce race condition.  Would it be
> possible to get some ideas in what race conditions might cause something
> like this so QA can reproduce this better?

You should be able to reproduce it fairly consistently if you rewind while a song is playing, but I think you need to 1) rewind for a second or more, and 2) make sure you're not rewinding all the way to the beginning of the song. That's what I did, and it seemed to cause the bug most of the time.
Decided to put it to 2.1.
blocking-b2g: 2.1? → 2.1+
Comment on attachment 8552606 [details] [review]
Fix it

Jim, thanks for working on this issue and the patch looks good to me, though I was unable to reproduce it but those changes make sense to me, also it should fixes some other potential bugs if gecko has more changes on the timings of the media events.
Attachment #8552606 - Flags: review?(dkuo) → review+
Landed: https://github.com/mozilla-b2g/gaia/commit/f7ccc16dab1966c501b033540bc48489d0bb64ea
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S5 (6feb)
Please request Gaia v2.1 and v2.2 approval on this when you get a chance.
Flags: needinfo?(squibblyflabbetydoo)
David, this has been waiting on approval requests for ~2 weeks now. Can you please help?
Flags: needinfo?(dflanagan)
I have to rewrite the patch for 2.1, and I haven't had a chance to do that yet. I'll do it today or tomorrow.
Flags: needinfo?(squibblyflabbetydoo)
Flags: needinfo?(dflanagan)
Comment on attachment 8552606 [details] [review]
Fix it

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Whatever it regressed from, it's pretty old. Probably when we enabled seeking by holding the fast-forward/rewind buttons.
[User impact] if declined: See bug title
[Testing completed]: Manually tested against master
[Risk to taking this patch] (and alternatives if risky): Low-risk; this just fixes the bug and hardens some logic to make it easier for users to escape similar bugs, if any exist.
[String changes made]: None
Attachment #8552606 - Flags: approval-gaia-v2.2?
Comment on attachment 8565745 [details] [review]
[gaia] jimporter:bug-1113881 > mozilla-b2g:v2.1

See previous comment. This is just the 2.1 port of the above patch.
Attachment #8565745 - Flags: approval-gaia-v2.1?
Attachment #8552606 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Comment on attachment 8565745 [details] [review]
[gaia] jimporter:bug-1113881 > mozilla-b2g:v2.1

Requesting QA verification on branches.
Attachment #8565745 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Keywords: verifyme
Attached video verify video
This problem is verified pass on latest build of Flame2.1/Flame2.2/Flame3.0 (men: 319MB)
See attachments: Verify_Video.MP4
Rate: 0/5

Flame 2.1 build:
Build ID               20150225001618
Gaia Revision          86af0ca427adad12c3109124f31bef2fd9614e47
Gaia Date              2015-02-24 02:22:26
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a275f2c05ca6
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150225.034947
Firmware Date          Wed Feb 25 03:49:58 EST 2015
Bootloader             L1TC000118D0

Flame 2.2 build:
Build ID               20150225002505
Gaia Revision          ca64f2fe145909f31af266b1730874051ba76c78
Gaia Date              2015-02-24 22:06:53
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/16804008c29f
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150225.041814
Firmware Date          Wed Feb 25 04:18:25 EST 2015
Bootloader             L1TC000118D0

Flame 3.0 build:
Build ID               20150225010244
Gaia Revision          f6bfd854fe4746f21bc006eac145365e85f98808
Gaia Date              2015-02-24 21:10:44
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/0a8b3b67715a
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150225.043702
Firmware Date          Wed Feb 25 04:37:14 EST 2015
Bootloader             L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Attached video video2
This problem is verified pass on latest build of 2.1S (men: 319MB)
See attachments: Verify_Video2.MP4
Rate: 0/5

2.1S build:
Build ID               20150226161204
Gaia Revision          a43d64ae01ef108aa4dcc971c770fecd8416a764
Gaia Date              2015-02-26 09:24:39
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2437280c634f
Gecko Version          34.0
Device Name            scx15_sp7715ga
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150226.193307
Firmware Date          Thu Feb 26 19:33:19 EST 2015
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: