Closed Bug 908525 Opened 11 years ago Closed 10 years ago

[Tarako][Fugu][Buri][Video][Clock]Can not pause video immediately when Alarm rings

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect, P3)

defect

Tracking

(blocking-b2g:-, b2g-v1.3T affected)

RESOLVED DUPLICATE of bug 927862
blocking-b2g -
Tracking Status
b2g-v1.3T --- affected

People

(Reporter: sync-1, Assigned: alive)

References

Details

(Keywords: perf, regression, Whiteboard: [c= p= s= u=tarako] [MemShrink:P3], [FT:System-Platform], burirun1.3-2, 1.3tarakorun2)

Attachments

(12 files)

8.82 MB, application/octet-stream
Details
9.54 MB, application/octet-stream
Details
113.42 KB, image/x-png
Details
9.54 MB, application/octet-stream
Details
8.82 MB, application/octet-stream
Details
9.54 MB, application/octet-stream
Details
9.54 MB, application/octet-stream
Details
113.42 KB, image/x-png
Details
8.82 MB, application/octet-stream
Details
9.54 MB, application/octet-stream
Details
91.76 KB, application/octet-stream
Details
9.54 MB, application/octet-stream
Details
Firefox os  v1.1
 Mozilla build ID:20130817041203
 
 Created an attachment (id=498064)
 JRDLOG
 
 DEFECT DESCRIPTION:
 Can not pause video when Alarm rings
  REPRODUCING PROCEDURES:
 1、launch clock APP and set a alarm time
 2、launch video player and play a video
 3、the video can not pause when Alarm rings->KO1
 4、it caused a minor flickering on the screen when Alarm rings->KO2
 4、the video player force stop when snooze or close the alarm->KO3
 
  EXPECTED BEHAVIOUR:
 the video should paused when Alarm rings->OK1
 the screen should't flicker when Alarm rings->OK2
 the video player keeps playing when snooze or close the alarm->OK3
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 moderate
 
  REPRODUCING RATE:
 3/3
 
  For FT PR, Please list reference mobile's behavior:
blocking-b2g: --- → leo?
Clone from brother
Attached file VCR
Clone from brother
Attached file VCR
Clone from brother
Attached image step5详图
Clone from brother
Clone from brother
Clone from brother
Attached file VCR
Attached file VCR
Clone from brother
Clone from brother
Attached file VCR
Attached file VCR
Clone from brother
Attached image step5详图
Clone from brother
Clone from brother
Attached file VCR
Clone from brother
Attached file VCR
Clone from brother
Clone from brother
Attached file JRDLOG
Attached file VCR
Please reassign as it is a clock issue.
Assignee: nobody → doliver
Flags: needinfo?(doliver)
Component: Gaia → General
I am going to add qawanted to confirm if its a regression from 1.0.1 which is the only case that we would block on this one.
Keywords: qawanted
QA Contact: laliaga
Tested Unagi and Buri devices on 1.0.1. The issue does not repro. Instead, the video is stopped and the user is returned to the video list after canceling/snoozing the alarm.

Environmental Variables
Build ID: 20130715070214
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0
Gaia: 054cdc27404e2daca91d3065d9783681032b2151
Platform Version: 18.0
Keywords: qawanted
QA Contact: laliaga
(In reply to Lucas A. from comment #29)
> Tested Unagi and Buri devices on 1.0.1. The issue does not repro. Instead,
> the video is stopped and the user is returned to the video list after
> canceling/snoozing the alarm.
> 
> Environmental Variables
> Build ID: 20130715070214
> Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0
> Gaia: 054cdc27404e2daca91d3065d9783681032b2151
> Platform Version: 18.0

Did you confirm you could reproduce this on 1.1?
Yes, I was able to reproduce on 1.1.
Any update?
Eric, can you take a look at this one?
Assignee: doliver → eric
Flags: needinfo?(doliver)
Made leo+ since it is a regression issue.
blocking-b2g: leo? → leo+
Keywords: regression
Component: General → Gaia::Clock
Eric, can you comment to provide the status on this bug?
Flags: needinfo?(eric)
Hi Dylan,

I can replicate this on my device. I'm looking into it now.
Flags: needinfo?(eric)
Any updates?
Eric,any findings?
Flags: needinfo?(eric)
Dylan,

Haven't seen Eric's comments since a week. Hope this is being worked on.
Flags: needinfo?(doliver)
Eric is working actively on this bug. From reading it over, however, it seems to me more likely to be a Video app bug or a System app bug than a Clock bug.  Or maybe it is a combination of all three.

I'm curious to know what happens when there is an incoming call with a video playing. If things work there, but not for an alarm, then maybe this is a system app issue.

Setting needinfo to get input from John and Alive.  Eric, John and Alive ought to be able to figure out what is going on here.
Flags: needinfo?(johu)
Flags: needinfo?(alive)
I try to reproduce the issue on build "mozilla-b2g18-hamachi-eng/2013/09/2013-09-24-04-12-00". But I'm not able to flash the image from pvt. It will get the error message as following:

adbd is already running as root
remount succeeded
ls: /builds/slave/b2g_m-cen_hamachi_ntly-0000000/build/objdir-gecko/dist/b2g: No such file or directory
cannot stat '/builds/slave/b2g_m-cen_hamachi_ntly-0000000/build/objdir-gecko/dist/b2g': No such file or directory

Is QA team able to flash the latest build with Firefox os v1.1?

Basically, it looks like an audio competing issue. I think Clock app don't have the ability to control Video app. As David's comment, we have to check the Audio channel competition normally or not.
Keywords: qawanted
Flags: needinfo?(alive)
Component: Gaia::Clock → AudioChannel
After discussion with Ian and alive, I also think it is related to audio channel competition.
Flags: needinfo?(johu)
This bug is already under audio channel component now.
Hi all,

I can't reproduce it on the newest v1-train today and I listed what version I tested it.

Gaia: V1-train from https://git.mozilla.org/releases
      commit 2cae0622ee942906daaca90293441afdbd2cb7de
Gecko: b2g18 from HG
      changeset:   119924:18175c7fdaa6

There are two things to let video app stop playing.
  1. AudioChannel will cause video element to be paused during Alarm fired.
  2. Video app itself will stop to play when it detect it is under background.

Hi Ian,

If you can reproduce it, I will check this with you. Thanks.
QA Contact: sarsenyev
Reassigning to Marco since this has now moved to AudioChannel.
Assignee: eric → mchen
Flags: needinfo?(eric)
Flags: needinfo?(doliver)
Able to reproduce the following issue on Buri 1.1 MOZ RIL
The video is continuing  to play with sound for another 2 seconds, after the alarm fires up
The issue doesn't reproduce with Incoming call, the video is paused right away without delay when the Incoming call screen appears
When receiving SMS the audio is muting for about 3 seconds but the video is continuing to play 

Build ID: 20130925041202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/18175c7fdaa6
Gaia: 6d9eec501a209bea945c6f841400ec0a75fac11d
Platform Version: 18.1
Assignee: mchen → eric
Keywords: qawanted
I'm guessing the change back to Eric was a mistake -- I don't think he is the right assignee here.
Assignee: eric → mchen
Hi Sync-1,

May I double confirm that comment 46 is what you met and fired here?
Thanks.
Flags: needinfo?(sync-1)
(In reply to sarsenyev from comment #46)
Hi all,

Let me recap one audio competing policy first. The foreground audio can be playable always.
So both of audio competing policy and video app depend on visibility change for pausing the media element.

> Able to reproduce the following issue on Buri 1.1 MOZ RIL
> The video is continuing  to play with sound for another 2 seconds, after the
> alarm fires up
Please refer to the log as below. video app needs 2.61 seconds for a visibility change event after alarm is fired.
This is the root cause of this situation.

09-26 14:49:01.220 I/AudioManager( 1742): NotifyOwnerDocumentActivityChanged hidden 0
...
09-26 14:49:03.830 I/AudioManager( 1569): NotifyOwnerDocumentActivityChanged hidden 1

> When receiving SMS the audio is muting for about 3 seconds but the video is
> continuing to play 
> 

In this case, I found that video app didn't receive any visibility change event and this is the root cause.

-----------------
Alive may need to help this case about timing of visibility change event.
Flags: needinfo?(alive)
(In reply to Marco Chen [:mchen] (PTO, 09/16, 09/18~09/22) from comment #48)
> Hi Sync-1,
> 
> May I double confirm that comment 46 is what you met and fired here?
> Thanks.

Yeah, KO1 is same with comment 46 , KO2 can't reproduce now and KO3 is not mentioned by comment 46.
Flags: needinfo?(sync-1)
The issue exactly is talking about:
there is a 3sec delay before we set visibility of app under attentionscreen.
I have some ways to fix this but I think this should not be considered to be a blocker for 1.1
Because the video in the end stops after 3 sec delay. It's not really "Cannot pause" anyway.
Flags: needinfo?(alive)
Hi, I'd like to help but I wonder it's really too late to make this blocks leo release,
also this isn't a regression IMO, it was a 'wrong-but-acceptable' design from long time ago.

I'd like to renom this for koi+.
blocking-b2g: leo+ → leo?
Set category to Gaia::System because it is related to timing of visibility change event.
Assignee: mchen → nobody
Component: AudioChannel → Gaia::System
Component: Gaia::System → Gaia::System::Window Mgmt
Summary: [Buri][Video][Clock]Can not pause video when Alarm rings → [Fugu][Buri][Video][Clock]Can not pause video when Alarm rings
blocking-b2g: leo? → koi?
blocking-b2g: koi? → 1.3+
Given how close we are in 12 and we have already shipped with this regression once, I am blocking it for 1.3, so this gets fixed.
Alive, do you want to take it?
Flags: needinfo?(alive)
Assignee: nobody → alive
Flags: needinfo?(alive)
Not v1.3 blocking since attention-window is not in scope of 1.3.
blocking-b2g: 1.3+ → 1.3?
Whiteboard: [FT:System-Platform]
Considering this is recoverable and user will most likely be watching video and able to respond to the alarm, pushing this out since a fix is incoming after window manager updates.
Adding to backlog.
Blocks: 908549
blocking-b2g: 1.3? → 1.5?
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> from comment #60)
> Considering this is recoverable and user will most likely be watching video
> and able to respond to the alarm, pushing this out since a fix is incoming
> after window manager updates.
> Adding to backlog.

v1.5 maybe too later, v1.4 ?
Whiteboard: [FT:System-Platform] → [FT:System-Platform], burirun1.3-2
blocking-b2g: 1.5? → 1.3T?
It'll cause incoming call performance issue, v1.3T.
Summary: [Fugu][Buri][Video][Clock]Can not pause video when Alarm rings → [Tarako][Fugu][Buri][Video][Clock]Can not pause video when Alarm rings
Adding qawanted to confirm if the experience is regressed further on tarako ? If the behavior is same as on 1.3, we would not block on 1.3T.
Flags: needinfo?(brhuang)
Keywords: qawanted
(In reply to bhavana bajaj [:bajaj] from comment #64)
> Adding qawanted to confirm if the experience is regressed further on tarako
> ? If the behavior is same as on 1.3, we would not block on 1.3T.

Doubt it. This bug has been around since 1.1.
Keywords: qawanted
Tested w/ buri v1.3 and tarako v1.3t. The video stopped on buri but didn't stop on tarako while incoming call. Video stopped on both of the devices while clock alarm rang.
Flags: needinfo?(brhuang)
With comment 66, Alive, are you still the right assignee of this bug? If not, feel free to re-assign.
Flags: needinfo?(alive)
Comment 66 seems a edge bug for tarako only, so I propose to fire another bug for it.

Al, I think you misunderstand this one, it's not talking about 'video does not stop playing', but
'video continues playing for 3 seconds after alarm or call coming. (Note, it finally stops.)
Flags: needinfo?(alive)
Summary: [Tarako][Fugu][Buri][Video][Clock]Can not pause video when Alarm rings → [Tarako][Fugu][Buri][Video][Clock]Can not pause video immediately when Alarm rings
I modified the bug summary for not causing confusion.
Given the recent QA testing and bug comments this was discussed in triage and is not a blocker for release of 1.3T
blocking-b2g: 1.3T? → -
I think it will cause tarako v1.3t performance issue.
Do we miss some patch has been merge into v1.3 but not on v1.3t?
blocking-b2g: - → 1.3T?
Flags: needinfo?(fabrice)
(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #51)
> The issue exactly is talking about:
> there is a 3sec delay before we set visibility of app under attentionscreen.
> I have some ways to fix this but I think this should not be considered to be
> a blocker for 1.1
> Because the video in the end stops after 3 sec delay. It's not really
> "Cannot pause" anyway.

I think 3sec delay will cause tarako performance issue. Peipei, can you confirm it?
Flags: needinfo?(pcheng)
No we don't miss anything from 1.3 - there is a daily merge from 1.3 to 1.3t
Flags: needinfo?(fabrice)
(In reply to James Zhang from comment #72)
> (In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #51)
> > The issue exactly is talking about:
> > there is a 3sec delay before we set visibility of app under attentionscreen.
> > I have some ways to fix this but I think this should not be considered to be
> > a blocker for 1.1
> > Because the video in the end stops after 3 sec delay. It's not really
> > "Cannot pause" anyway.
> 
> I think 3sec delay will cause tarako performance issue. Peipei, can you
> confirm it?

I saw the 3sec delay on tarako build 20140318033320. Besides this, I didn't see other performance issues.
Flags: needinfo?(pcheng)
base on comment 68 and comment 74, this does not seem like the highest priority for tarako at this moment, minus
blocking-b2g: 1.3T? → -
In today's build, I spent 30 seconds with only sound and no video (black screen other than the status bar).  The alarm sounded 1 minute later than it should have sounded

Gaia      acd18bbd94ebfa534e252a24a75a0617e4b5d5ae
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/91a1b54da4a6
BuildID   20140404004001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140404.044841
ro.build.date=Fri Apr  4 04:48:48 EDT 2014
Tarako
Keywords: perf
Whiteboard: [FT:System-Platform], burirun1.3-2 → [FT:System-Platform], burirun1.3-2, [MemShrink]
Whiteboard: [FT:System-Platform], burirun1.3-2, [MemShrink] → [FT:System-Platform], burirun1.3-2, [MemShrink], 1.3tarakorun2
Status: NEW → ASSIGNED
Whiteboard: [FT:System-Platform], burirun1.3-2, [MemShrink], 1.3tarakorun2 → [c= p= s= u=][FT:System-Platform], burirun1.3-2, [MemShrink], 1.3tarakorun2
The Tarako behaves pretty much as expected in this scenario.
When the alarm triggers, the video pauses, and the alarm alert appears without any flickering. After dismissing the alert, the video remains paused, but resumes at the right place when the play button is pressed.
Current performance is much improved.
Whiteboard: [c= p= s= u=][FT:System-Platform], burirun1.3-2, [MemShrink], 1.3tarakorun2 → [c= p= s= u=][FT:System-Platform], burirun1.3-2, [MemShrink:P3], 1.3tarakorun2
Priority: P1 → P3
Whiteboard: [c= p= s= u=][FT:System-Platform], burirun1.3-2, [MemShrink:P3], 1.3tarakorun2 → [c= p= s= u=tarako] [MemShrink:P3], [FT:System-Platform], burirun1.3-2, 1.3tarakorun2
Alive, is this bug a dup to what's already been fixed?
Flags: needinfo?(alive)
Bug 927862 should fix |3、the video can not pause when Alarm rings->KO1| already, I am not sure about the remaining issues.
Flags: needinfo?(alive)
Let's dup the bug then.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: