Closed Bug 1082938 Opened 5 years ago Closed 5 years ago

[Music] Cannot pause the music after unpairing a BT device and resuming the music

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

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

VERIFIED FIXED
2.1 S9 (21Nov)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- unaffected

People

(Reporter: ychung, Assigned: dkuo)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-flame-test-run-3])

Attachments

(4 files)

Description:
The pause button does not work after the user unpaired a BT headset and resumed the music.

Pre-requisite: Have at least 1 music file on the device.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141013001201.
2) Open Music app, and play a song.
3) Go to Settings > Bluetooth, and pair with a bluetooth headset.
> Music is now heard through the BT headset.
4) Unpair the BT headset.
> Music is paused
5) Bring the music app again, and resume the paused music.
6) Tap the pause button.
  
Actual:
The music does not pause.
  
Expected: 
The music pauses as soon as the user selects the pause button.
  
Environmental Variables:
Device: Flame 2.1
BuildID: 20141013001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Notes:
This bug was found during working on Music and Bluetooth-related test cases.
  
Repro frequency: 100%
See attached: logcat, video
http://youtu.be/2AuRKQAXYV4
This issue does NOT reproduce on Flame 2.2 and Flame 2.1:

Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
BuildID: 20141013040202
Gaia: 3b81896f04a02697e615fa5390086bd5ecfed84f
Gecko: f547cf19d104
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.0

Device: Flame 2.0 KK (319mb) (Full Flash)
BuildID: 20141013000204
Gaia: 6effca669c5baaf6cd7a63c91b71a02c6bd953b3
Gecko: 54ec9cb26b59
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

The music pauses properly when the user selects the pause button.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
The user should be able to pause the song and this is a regression from 2.0 so nominating this 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Bluetooth related issues back, lets get to the root of the problem. Dominic, please investigate and see whats going on. 

Blocking Reason: Regression from previous release, broken functionality
Assignee: nobody → dkuo
blocking-b2g: 2.1? → 2.1+
QA Contact: jmercado
Bug 1066530 seems to have caused this issue.  Both swaps showed reproductions of this issue but that is because the gecko change is only to accept the single change from gaia.

Aurora Regression Window:

Last Working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140922050550
Gaia: 138ead9d7411dd2b0fc46bc2c8bbf578db0e758d
Gecko: eadaf94a0d1c
Version: 34.0a2 (2.1) 
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140922053548
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: 185fc54d29c1
Version: 34.0a2 (2.1) 
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last Working gaia / First Broken gecko - Issue DOES* occur * See above
Gaia: 138ead9d7411dd2b0fc46bc2c8bbf578db0e758d
Gecko: 185fc54d29c1

First Broken gaia / Last Working gekko - Issue DOES occur
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: eadaf94a0d1c

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/138ead9d7411dd2b0fc46bc2c8bbf578db0e758d...689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Blocks: 1066530
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: jmercado
Regression of bug 1066530, would you mind take a look?

Hema, Dominic is already working on bug 1083129. Please assign this to someone else.

Dominic, do you really have bandwidth to take this?
Flags: needinfo?(robert.chira)
Flags: needinfo?(hkoka)
Flags: needinfo?(dkuo)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> Regression of bug 1066530, would you mind take a look?

Bug 1066530 seems not related to the music app codebase, it's patch for the ui-tests. Can we request the regressionwindow-wanted again?

> Hema, Dominic is already working on bug 1083129. Please assign this to
> someone else.
> 
> Dominic, do you really have bandwidth to take this?

I am working on bug 1083129 so probably will investigate this issue later. If it's confirmed I will see if Sherman, Jim or Hubert can help this, but this looks strange because it only happens on v2.1?
Flags: needinfo?(dkuo)
QA Contact: aalldredge
Leaving an NI on Jim to help with this once we have a regression window. Jim, please reassign to yourself when you pick it up if the issue is on the music app side. 

Thanks
Hema
Flags: needinfo?(hkoka) → needinfo?(squibblyflabbetydoo)
I got this issue to reproduce in the first KK Aurora build we have. I was unable to reproduce this issue in any JB aurora builds. Regression window unavailable.

First KK Environmental Variables:
Device: Flame 2.1
BuildID: 20140904062538
Gaia: a47ecb6368c015dd72148acde26413fd90ba3136
Gecko: ffb144a500a4
Version: 34.0a2 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Initial Regression window WAS incorrect - sorry for the noise

unfortunately this issue repro'd in the oldest Aurora (2.1) build we have so we can not get a window on this.
Flags: needinfo?(jmitchell)
QA Contact: aalldredge
I will assume the ni? for me was a mistake since the comment is not addressed to me.
If you would like me to help with something on automation please let me know.
Flags: needinfo?(robert.chira)
What version(s) does this issue appear in? It sounds like it's 2.1 only, and not 2.2 or 2.0, but it's very unclear. I'd also be interested in seeing if this reproduced on a 2.2 JB build.

Given comment 9 though, this sounds like a Gecko/Gonk issue.
Flags: needinfo?(squibblyflabbetydoo)
Jim,

We are not testing on JB. Please help narrow down the issue here. Dominic has another blocker to wrap up. Re-assigning this to you. 

Dominic, if you have input based on any investigation you have done already on this, please let Jim know.

Thanks
Hema
Assignee: dkuo → squibblyflabbetydoo
(In reply to Jim Porter (:squib) from comment #12)
> What version(s) does this issue appear in? It sounds like it's 2.1 only, and
> not 2.2 or 2.0, but it's very unclear. I'd also be interested in seeing if
> this reproduced on a 2.2 JB build.


Tracking Flags:
status-b2g-v2.0: 	unaffected
status-b2g-v2.1: 	affected
status-b2g-v2.2: 	unaffected
Joshua: see the end of this comment. Thanks!

(In reply to Hema Koka [:hema] from comment #13)
> We are not testing on JB. Please help narrow down the issue here. Dominic
> has another blocker to wrap up. Re-assigning this to you. 

Whether or not we're officially testing on JB, it would be extremely helpful to see if this still happens on JB, since that would narrow things down quite a bit. Given that this bug report predates any changes between 2.1 and 2.2 (the first big one was bug 841949, and that didn't land until the 15th), I think it's safe to say that this isn't a regression in the music app. This is probably either a Bluetooth or AudioChannel issue.

If we can't get a correct date when this first broke, could we get a date when this first became *unbroken* in 2.2? It's possible we just didn't backport a necessary patch.
Flags: needinfo?(jmitchell)
We can take a look
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: jmercado
All commits come from fx-team and we do not have a way to get a smaller window.

Central Reverse Regression Window:

Last Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20140930060422
Gaia: 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko: 4475aa556e69
Version: 35.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20140930061521
Gaia: 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko: 2ae57957e4bb
Version: 35.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Last Broken gaia / First Working gecko - 
Gaia: 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko: 2ae57957e4bb

First Working gaia / Last Broken gecko - 
Gaia: 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko: 4475aa556e69

Gecko Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4475aa556e69&tochange=2ae57957e4bb
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Jim - it looks like a lot of FX merges in that pushlog
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(squibblyflabbetydoo)
Hm, I was hoping I could get a regression window first to figure out where I should start looking, but it seems I can't reproduce this at all. I'm on 2.1 with a build ID of 20141031001201 (the latest from the mozilla-b2g34_v2_1 branch from the Taipei QA tools), and everything works just fine if I follow the steps in comment 0. I've tried a few other builds with no issue either.
Flags: needinfo?(squibblyflabbetydoo)
Maybe we got lucky and it was fixed by something else? 

QA-Wanted to check again in the latest 2.1 to see if this issue is still present
Keywords: qawanted
QA Contact: jmercado
QA Contact: ckreinbring
The bug repros on today's 2.1 engineering (shallow flash) and nightly (full flash).
Actual result: After unpairing the Bluetooth headset and resuming the currently playing song, the pause button ceases to respond to taps.

Flame 2.1 engineering
BuildID: 20141031084110
Gaia: 18289d3b6136a6cf3efafcaeed677a99ef5362a4
Gecko: 1f1017a1eff5
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.1 nightly
BuildID: 20141031001201
Gaia: f89c7b12c36572262c9ea76058694a139b1a8634
Gecko: 50d48f8a04c7
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Platform Version: 34.0
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Issue is still present for us
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
How are you flashing your devices? I used the following from the Taipei QA tools[1]:

  ./flash_pvt.py -d flame-kk -v mozilla-b3g34_v2_1 --eng -g -G

(This shallow-flashes gecko and gaia for a Flame-KitKat engineering build from the v2.1 branch.) I also tried flashing from mozilla-aurora, and things worked fine for me there too.

[1] https://github.com/Mozilla-TWQA/B2G-flash-tool
Flags: needinfo?(jmitchell)
Hi Jim,

For shallow flashing we use a modification of Naoki's Flash tool to work with current builds.  For full flashing we use the flash.sh included in the b2g-distro folder included in the builds.
Flags: needinfo?(jmitchell)
I loaded base image of v188-1 and shallow flashed 2.1 gaia & gecko. I can repro this as well.

I paired the BT device, played the music, then instead of unpairing, I turned off the BT in flame.
After going back to the music app, the music starts playing, but I cannot pause it (the pause button does not work)

The version I used is:
Gaia-Rev        8b0cf889ae0d48a9eb7ecdcb9b67590de45cc5e5
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/388b03efe92d
Build-ID        20141104001202
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  40
FW-Date         Tue Oct 21 15:59:42 CST 2014
Bootloader      L1TC10011880
Jim,

If you are still unable to reproduce? If so, please work with No-jun, he seems to be able to reproduce this on 2.1 shallow flash and V188-1

Thanks
Hema
Flags: needinfo?(squibblyflabbetydoo)
This still works fine for me. I must admit, I'm baffled as to why this doesn't work for anyone else, since I've never had a single problem with it. Maybe the Bluetooth hardware I'm using is different?

Dominic: Could you try reproducing this? I've had no luck with it whatsoever. Maybe you'll fare better...
Flags: needinfo?(squibblyflabbetydoo) → needinfo?(dkuo)
Could be related to headset issue.  I'm using Plantronics M25, and I can repro this bug on the following build: 

Gaia-Rev        4c159e75a1568afbbf0c83c1235ec56facfbe87d
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/b9849b3c6aaa
Build-ID        20141112001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  40
FW-Date         Tue Oct 21 15:59:42 CST 2014
Bootloader      L1TC10011880

But :squib uses different headset (http://www.amazon.com/LG-Electronics-HBS-730-Bluetooth-Headset/dp/B009A5204K) and that could be a factor I think.

The link to logcat while the bug is happening: https://pastebin.mozilla.org/7272711 

dkuo, what kind of headset are you using?
(In reply to Jim Porter (:squib) from comment #27)
> This still works fine for me. I must admit, I'm baffled as to why this
> doesn't work for anyone else, since I've never had a single problem with it.
> Maybe the Bluetooth hardware I'm using is different?
> 
> Dominic: Could you try reproducing this? I've had no luck with it
> whatsoever. Maybe you'll fare better...

Okay, I gave a try just now and can reproduced it, so probably I should take this one since my setup seems closer to the reporter’s.

> dkuo, what kind of headset are you using?

I am using a bluetooth headset(Razer Adaro Wireless) that supports media streaming only(A2DP, no SCO), probably related?

Taking it and hope I can find the root cause.
Assignee: squibblyflabbetydoo → dkuo
Flags: needinfo?(dkuo)
Attached file v2.1 - patch
Jim,

The hard part of this issue is it's only reproducible once after we reboot the device, and fortunately I have found it's a must-have step then found the root cause.

The music player will set the play status to PLAYING when the audio element receives the |playing| event, but for some reason(should be gecko issue) after the bluetooth headset is disconnected and we resumed the player, the |playing| event does not fire so that the play status is still PAUSED, then when we press the playpause button again, the player logic just called the player to play repeatedly, and feels like the player is unpauseable.

So I have moved the logic of setting the PLAYING status from the |playing| event to |play| event, which seems more reliable and represents the audio element does play[1], would you please review this patch? thanks!

[1] https://developer.mozilla.org/en-US/docs/Web/Events/play
Attachment #8522996 - Flags: review?(squibblyflabbetydoo)
Attached file patch
Comment on attachment 8522996 [details] [review]
v2.1 - patch

I can't test this, since I haven't been able to reproduce it, but this looks sensible to me. Thanks!
Attachment #8522996 - Flags: review?(squibblyflabbetydoo) → review+
Thank you, too, Jim!

master: 48ab6013499981e6c7987c13d69284b564053b01
v2.1: 10b84fae70cfab428030cc086b433f89ac440c14
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Keywords: verifyme
This landed on Gaia v2.1 without approval. Per the policy change announced nearly 3 months ago, *ALL* patches require approval regardless of blocking status.
https://wiki.mozilla.org/Release_Management/B2G_Landing#Landing_Procedure_5
Flags: needinfo?(dkuo)
Target Milestone: --- → 2.1 S9 (21Nov)
(In reply to [Away 18-Nov to 23-Nov] Ryan VanderMeulen [:RyanVM UTC-5] from comment #34)
> This landed on Gaia v2.1 without approval. Per the policy change announced
> nearly 3 months ago, *ALL* patches require approval regardless of blocking
> status.
> https://wiki.mozilla.org/Release_Management/B2G_Landing#Landing_Procedure_5

Oops! apologize for landing the v2.1 patch without approval, I thought this was a 2.1 only bug, so just landed it because it's a 2.1 blocker, but looks like I should still follow the landing rules on the wiki page, sorry about it :P

reverted on v2.1: 1b231b87aad384842dfc79614b2a9ca68a4b4ff3
Flags: needinfo?(dkuo)
See Also: → 1100771
Comment on attachment 8522996 [details] [review]
v2.1 - patch

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 1100771.
[User impact] if declined: unable to pause the music after disconnected the bluetooth headset.
[Testing completed]: passed the manual tests with flame and bluetooth headset.
[Risk to taking this patch] (and alternatives if risky): low.
[String changes made]: none.
Attachment #8522996 - Flags: approval-gaia-v2.1?
Attachment #8522996 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
This issue has been verified successfully on Flame v2.1.
See attachment: Verify_Video_Flame v2.1.MP4
Reproducing rate: 0/10

Flame v2.1 version:
Gaia-Rev        afdfa629be209dd53a1b7b6d6c95eab7077ffcd9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/dc3018cbdbe6
Build-ID        20141123001201
Version         34.0
v2.1: f93f2b92c7410815b785f6d8b286593d703a65d9
This issue is verified fixed on Flame 2.1

Result: While paired to another device, if you then unpair, play a song, and then try to pause it, the song will pause like it should.

Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141125001201
Gaia: 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko: db893274d9a6
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.