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

Status: VERIFIED FIXED

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

Description

[Yeojin Chung [:YeojinC]]

Attachment: logcat_20141014_MusicNotPausing.txt

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

Comment 1

[Yeojin Chung [:YeojinC]]

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.

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

The user should be able to pause the song and this is a regression from 2.0 so nominating this 2.1?

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

[Blocking Requested - why for this release]:

Comment 4

[Hema Koka [:hema]]

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

Comment 5

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

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

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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?

Comment 7

[Dominic Kuo [: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?

Comment 8

[Hema Koka [:hema]]

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

Comment 9

[Adam Alldredge [:AdamA][Inactive]]

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

Comment 10

[Joshua Mitchell (Inactive)]

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.

Comment 11

[Robert Chira [:RobertC]]

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.

Comment 12

[Jim Porter (:squib)]

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.

Comment 13

[Hema Koka [:hema]]

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

Comment 14

[Joshua Mitchell (Inactive)]

(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

Comment 15

[Jim Porter (:squib)]

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.

Comment 16

[Joshua Mitchell (Inactive)]

We can take a look

Comment 17

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

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

Comment 18

[Joshua Mitchell (Inactive)]

Jim - it looks like a lot of FX merges in that pushlog

Comment 19

[Jim Porter (:squib)]

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.

Comment 20

[Joshua Mitchell (Inactive)]

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

Comment 21

[Chris Kreinbring [: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

Comment 22

[Joshua Mitchell (Inactive)]

Issue is still present for us

Comment 23

[Jim Porter (:squib)]

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

Comment 24

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

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.

Comment 25

[No-Jun Park [:njpark]]

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

Comment 26

[Hema Koka [:hema]]

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

Comment 27

[Jim Porter (:squib)]

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...

Comment 28

[No-Jun Park [:njpark]]

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?

Comment 29

[Dominic Kuo [:dkuo]]

(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.

Comment 30

[Dominic Kuo [:dkuo]]

Attachment: 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

Comment 31

[Dominic Kuo [:dkuo]]

Attachment: patch

Comment 32

[Jim Porter (:squib)]

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!

Comment 33

[Dominic Kuo [:dkuo]]

Thank you, too, Jim!

master: 48ab6013499981e6c7987c13d69284b564053b01
v2.1: 10b84fae70cfab428030cc086b433f89ac440c14

Comment 34

[Ryan VanderMeulen [:RyanVM]]

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

Comment 35

[Dominic Kuo [:dkuo]]

(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

Comment 36

[Dominic Kuo [:dkuo]]

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.

Comment 37

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

v2.1: https://github.com/mozilla-b2g/gaia/commit/f345f746754d9d37aa35dba0c34ed5006f8c9ba7

Comment 38

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame v2.1.MP4

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

Comment 39

[Dominic Kuo [:dkuo]]

v2.1: f93f2b92c7410815b785f6d8b286593d703a65d9

Comment 40

[Robert Mead [:RobertM]]

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