Closed Bug 982540 Opened 11 years ago Closed 11 years ago

[Tarako][Dialer][Music]Hang up the phone within 4 seconds, resume to music will get no any sound

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T verified, b2g-v1.4 verified, b2g-v2.0 verified)

VERIFIED FIXED
1.4 S4 (28mar)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- verified
b2g-v1.4 --- verified
b2g-v2.0 --- verified

People

(Reporter: mlien, Assigned: dkuo)

References

Details

(Keywords: regression, Whiteboard: [caf priority: p2][CR 636578],)

Attachments

(3 files)

Attached file logcat.txt (deleted) —
[Device] Tarako --------------------------------------------- [Reproduction build] - V1.3T Gaia 1f00cb5e533e698c5607bfce668a945270e79944 Gecko N/A BuildID 20140312075534 Version 28.0 --------------------------------------------- [Reproduce Steps] 1. Launch Music app 2. Play any music 3. Make a phone call to Tarako and pick it up 4. Hang up the phone within 4 seconds --------------------------------------------- [Expected Result] Tarako resume to music and play normally --------------------------------------------- [Actual Result] If hang up within 4 seconds, resume to music will get no any sound
blocking-b2g: --- → 1.3T?
if hanging up after 4 seconds, music will resume properly? thanks
Flags: needinfo?(mlien)
yes, after 4~6 seconds then hang up the phone, music will resume properly
Flags: needinfo?(mlien)
It should be fixed on v1.3T
blocking-b2g: 1.3T? → 1.3T+
Component: Gaia::Dialer → Performance
Dominic, do you think you can take a look at this? Thanks
Flags: needinfo?(dkuo)
I believe the music app was killed by the LMK during the call, and this should be the same as bug 983541, please see my comment in bug 983541 comment 12, thanks.
Flags: needinfo?(dkuo)
But if the music app was not killed, then this should be another issue... Mike, after the call was ended, does the [Actual Result] in comment 0 mean: 1. The music app resumed without sound? or 2. The music app was killed and you relaunched it but didn't resume from where it was interrupted?
Flags: needinfo?(mlien)
Also NI on john here for some more testing
Flags: needinfo?(jhammink)
https://bugzilla.mozilla.org/show_bug.cgi?id=967581#c45 may also be relevant, it looks like gecko is stopping the audio when it should not.
(In reply to Dominic Kuo [:dkuo] from comment #6) > But if the music app was not killed, then this should be another issue... > > Mike, after the call was ended, does the [Actual Result] in comment 0 mean: > 1. The music app resumed without sound? or > 2. The music app was killed and you relaunched it but didn't resume from > where it was interrupted? Comment 0 actual result is music still in playing status(both progress bar and timecode are running) I verify the latest build and get the different result, information as below Gaia bebf5f27a332fcfc880619380067bbfdc845a281 Gecko 0236f48bf8c0ee6032fbc126c03cf09137cf20e8 BuildID 20140320060057 Version 28.0 Result: 1. After hang up phone call(no matter how many seconds), UI resume to music app and can hear sound continuing from interrupted position 2. Pause/Play control button doesn't work 3. Progress bar and timecode have no any status update 4. Click previous/next button or drag progress bar can let music app resume to normal About detail information, please check with the 2nd attachment
Flags: needinfo?(mlien)
Attached file logcat-20140320.txt (deleted) —
Dominic, please check comment 9.
Flags: needinfo?(dkuo)
I am seeing the same results as Mike Lien on Comment 9. This is slightly different from the original STR. Gaia 2f753b12d60a250cdedd895b9bba73891115b7a3 Gecko d2daafaa28c4aed079907fda9516201e93d0c25a BuildID 20140320112344 Version 28.0 ro.build.version.incremental=118 ro.build.date=Thu Mar 20 11:28:08 CST 2014
Flags: needinfo?(jhammink)
Assigning this to Dominic and switching to the Music component as this appears to be a functional issue with sound handling between Music and Dialer.
Status: NEW → ASSIGNED
Component: Performance → Gaia::Music
Assigning to Dominic
Assignee: nobody → dkuo
Flags: needinfo?(squibblyflabbetydoo)
Based on the comments here, my guess would be that bug 967581 comment 49 is the issue.
Flags: needinfo?(squibblyflabbetydoo)
This really should be nomed for 1.3?, not 1.3T?, as this is a regression from 1.1 --> 1.3.
blocking-b2g: 1.3T+ → 1.3?
(In reply to Mike Lien[:mlien] from comment #9) > Result: > 1. After hang up phone call(no matter how many seconds), UI resume to > music app and can hear sound continuing from interrupted position > 2. Pause/Play control button doesn't work > 3. Progress bar and timecode have no any status update > 4. Click previous/next button or drag progress bar can let music app > resume to normal > > About detail information, please check with the 2nd attachment Thanks Mike, now I am sure this issue is different from bug 983541, music was not killed but some playback abilities were broken. This should be an issue in gecko(maybe audio channel) because music app actually did nothing when dialer app interrupts or music app resumes, the audio channel should handle theses interrupt/resume actions. And the regressionwindow is requested, meanwhile I will ask help from gecko dev(Star) to investigate this issue as well.
Flags: needinfo?(dkuo)
What's the impact to the user on a non-Tarako device? Can we live with this till 1.4?
(In reply to Preeti Raghunath(:Preeti) from comment #21) > What's the impact to the user on a non-Tarako device? Can we live with this > till 1.4? Any audio channel conflict that happens will break the play/pause button. We probably can't live with this - it's basic bustage from an audio channel conflict in the music app.
QA Contact: mvaughan
Whiteboard: [CR 636578]
(In reply to Jason Smith [:jsmith] from comment #22) > (In reply to Preeti Raghunath(:Preeti) from comment #21) > > What's the impact to the user on a non-Tarako device? Can we live with this > > till 1.4? > > Any audio channel conflict that happens will break the play/pause button. > > We probably can't live with this - it's basic bustage from an audio channel > conflict in the music app. Blocking on this for 1.3 then.
blocking-b2g: 1.3? → 1.3+
Adding Star for help with investigating on the audio channel front
Flags: needinfo?(scheng)
TINDERBOX: - Last Working - Device: Buri ENG v1.3 MOZ RIL BuildID: 20140310133310 Gaia: 8d235a284173ea6d441c8d1ce1cc164b6b91423a Gecko: 87f30fd34b67 Version: 28.0 Firmware Version: V1.2-device.cfg - First Broken - Device: Buri ENG v1.3 MOZ RIL BuildID: 20140311003244 Gaia: 6b1180917fa4af4e4b7e31b51fc06a4bbaa2ad0f Gecko: 8976860941f2 Version: 28.0 Firmware Version: V1.2-device.cfg **This looks to be a gaia issue** last working gaia/first broken gecko = NO REPRO Gaia: 8d235a284173ea6d441c8d1ce1cc164b6b91423a Gecko: 8976860941f2 first broken gaia/last working gecko = REPRO Gaia: 6b1180917fa4af4e4b7e31b51fc06a4bbaa2ad0f Gecko: 87f30fd34b67 Tinderbox push log: https://github.com/mozilla-b2g/gaia/compare/8d235a284173ea6d441c8d1ce1cc164b6b91423a...6b1180917fa4af4e4b7e31b51fc06a4bbaa2ad0f NOTE: The tinderbox push log shows only 1 commit while the inbound push log shows 4. I assume this is due to the tinderbox being for 1.3 while the inbound is for master. Both push logs contain the same commit however and in case it is useful/needed, below is the inbound push log for the b2g-inbound regression window. Inbound push log: https://github.com/mozilla-b2g/gaia/compare/b31771c0be6c4d7c67a8762be2f1b80237203b08...41d4cb48f5ff7f66ab5b6c1ac16203be06a62fb1
This was caused by bug 973156.
Blocks: 973156
(In reply to Jason Smith [:jsmith] from comment #26) > This was caused by bug 973156. Thanks Matthew and Jason, and apologize for misleading this issue to a wrong direction. We tried to hide the playback controls when music app is interrupted(mozinterruptbegin) in bug 973156, but the patch didn't fully recover after the music resumed(mozinterruptend), the fix should be simple and I will attach a WIP later.
Flags: needinfo?(scheng)
Attached file patch for master (deleted) —
WIP attached, and see if I can add some tests.
Dominic, Can this be wrapped up by 27th? Could you please provide an eta? Thanks Hema
Whiteboard: [CR 636578] → [CR 636578] [fix-in-progress]
(In reply to Hema Koka [:hema] from comment #29) > Dominic, > > Can this be wrapped up by 27th? Could you please provide an eta? > > Thanks > Hema I will finish the tests and request for review today(3/25), hope I can got r+ and land it tomorrow(3/26), thanks.
Whiteboard: [CR 636578] [fix-in-progress] → [CR 636578] [fix-in-progress] [eta 3/27 PST]
Comment on attachment 8395503 [details] patch for master Jim, This issue was caused by bug 973156(please see comment 27), and the fix is simple(actually only two lines), but to prevent we break the basic play/pause functionality again, I have added the integration tests to test the scenario about mozinterruptbegin and mozinterruptend in music app, it's similar to the tests for ringtones app(bug 958470), though the tests was backed out but I think this time the tests seems passed all the time. Would you please review it? thanks. (And after I got r+, I will make different PR for each branch because the tests should be the same but with slightly changes on the configurations of marionette js test framework)
Attachment #8395503 - Attachment description: WIP → patch for master
Attachment #8395503 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8395503 [details] patch for master This looks mostly good and the tests pass! r=me. I have one comment over on Github that you should try to address. I think you can remove some unneeded code. :)
Attachment #8395503 - Flags: review?(squibblyflabbetydoo) → review+
Thanks Jim, I have addressed those issues and travis passed in https://travis-ci.org/mozilla-b2g/gaia/builds/21602652 Landed on master: 26c7ce665cfca34f1df2d22a261eabdb23f993b3
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 8395503 [details] patch for master NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Bug 973156 [User impact] if declined: unable to pause the music after answered a call [Testing completed]: yes, with new integration tests [Risk to taking this patch] (and alternatives if risky): low [String changes made]: none
Attachment #8395503 - Flags: approval-gaia-v1.4?(fabrice)
Attachment #8395503 - Flags: approval-gaia-v1.3?(fabrice)
Flags: in-testsuite+
Keywords: verifyme
Attachment #8395503 - Flags: approval-gaia-v1.4?(release-mgmt)
Attachment #8395503 - Flags: approval-gaia-v1.4?(fabrice)
Attachment #8395503 - Flags: approval-gaia-v1.3?(fabrice)
Attachment #8395503 - Flags: approval-gaia-v1.3+
Comment on attachment 8395503 [details] patch for master given this is 1.3+, this would be landed to 1.4 automatically. Nevertheless, rubber-stamping the approval here.
Attachment #8395503 - Flags: approval-gaia-v1.4?(release-mgmt) → approval-gaia-v1.4+
Verified as fixed v1.5. This issue does NOT reproduce in the latest v1.5 Buri build: 3/27 Environmental Variables: Device: Buri 1.5 MOZ RIL BuildID: 20140327092814 Gaia: 287195d1fed2e6c883745d7091a4c05e56c4dbb7 Gecko: bb4dd9872236 Version: 31.0a1 Firmware Version: V1.2-device.cfg Verified as fixed v1.4. This issue does NOT reproduce on the latest v1.4 Buri build: 3/28 Environmental Variables: Device: Buri 1.4 MOZ RIL BuildID: 20140328000202 Gaia: e07a5915737727ba22c06f270ee7af6572f746f3 Gecko: 33e7fd745c1b Version: 30.0a2 Firmware Version: V1.2-device.cfg Verified as fixed v1.3. This issue does NOT reproduce on the latest v1.3 Buri build: 3/28 Environmental Variables: Device: Buri 1.3 MOZ RIL BuildID: 20140328004002 Gaia: 523196662f4d19c7898d5f4773da020c39cfe57e Gecko: aa1d48ab3715 Version: 28.0 Firmware Version: V1.2-device.cfg - 1) Changing bug status to verified as this was tested against master v1.5.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Sorry guys, had to back this out of v1.3 for test failure: https://github.com/mozilla-b2g/gaia/commit/0d54a796bdaeb96ca7fb63da2166a46b4f8859f2 The new integration test use marionette file manager, which is not a plugin we have on the v1.3 branch. Before re-landing this, make sure you also include that plugin. https://github.com/mozilla-b2g/gaia/commit/85c0ce7239d544add7be2d6053ed78e2b4a3dccf#diff-c6184496bf60ffae2f21ac71bd7a648aR38
Blocks: 989915
Re-landed with skipping the new tests. v1.3: 554ea9e469e2060f87c87d0463d4a0cfcf70c54d v1.3t: 769c3b00a43f03ca901414ec533f7b313a7684c5
No longer blocks: 989915
The Music app gets killed in the background. This is why the music app doesn't resume after hang up for 1.3T Gaia 27a0e773e01eed74e20709bdcab6894469f42a72 Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/257dd37da601 BuildID 20140411004003 Version 28.1 ro.build.version.incremental=eng.cltbld.20140411.045851 ro.build.date=Fri Apr 11 04:58:57 EDT 2014 Going to clone the bug and mark it as an OOM bug.
Whiteboard: [CR 636578] → [CR 636578],
Whiteboard: [CR 636578], → [caf priority: p2][CR 636578],
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: