Closed Bug 1031573 Opened 10 years ago Closed 9 years ago

Alarm clock is intermittently fired at random times, even though the correct time is displayed on the status bar

Categories

(Firefox OS Graveyard :: Gaia::Clock, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::Clock
Platform:
x86_64
Linux
Type:
defect

Tracking

(blocking-b2g:2.5+, b2g-v2.0 affected, b2g-v2.1 affected, b2g-master affected)

Status:
RESOLVED DUPLICATE of bug 1181489
Project Flags:
blocking-b2g 2.5+
Tracking Flags:
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-master --- affected

People

(Reporter: smaug, Unassigned)

References

Details

(Keywords: foxfood, Whiteboard: [ft:productivity])

Attachments

(1 file)

Alarm fired at the wrong time - logcat
30.90 KB, text/plain
Details 
I had the alarm set to 9:55am, yet the alarm fired at 1:43am.
It also happened on v1.3

The following is related information from Bug 1022877

--------------------------------------------------------------
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20140609030202

Steps to reproduce:

Model: Open C
Software: FFOS_EU_EBAY_OPENCV1.0.0B05
Build ID: 20140519040012
OS Version: 1.3.0.0
Hardware revision: P821A10B01

1. Set a timer for x minutes.
2. Lock screen.
3. Wait x minutes.


Actual results:

The timer alarm does not sound after x minutes. It only triggers whenever the user brings up the lockscreen after x minutes has passed.


Expected results:

The alarm should have triggered after x minutes, even though the screen is locked.
blocking-b2g: --- → 1.3?
I've encountered this as well. And since I didn't know whether the bug can be reproduced, I mail to the dev-gaia and dev-b2g:

https://groups.google.com/forum/#!topic/mozilla.dev.gaia/1B6A2evVAc0
Whiteboard: [ft:productivity]
Since 1.3 is finished already, I suggest to fix it in 2.0. I think this is also reproducible with 2.0, right?
blocking-b2g: 1.3? → 2.0?
Flags: needinfo?(whsu)
(In reply to Kevin Hu [:khu] from comment #7)
> Since 1.3 is finished already, I suggest to fix it in 2.0. I think this is
> also reproducible with 2.0, right?

Yes! You got that right.
Thanks Kevin!
Flags: needinfo?(whsu)
I need to notice that the symptom I've seen is not only alarm at wrong time. What I saw is the system clock is incorrect. For example, in the first case I mentioned in the letter, I saw the alarm correctly wake me up at *its 8:00AM*, however the real time is 6:00AM. So maybe this bug is actually two bugs: one is for the alarm, and another is for the clock.
That sounds indeed familiar. I think my phone shows first some wrong for a short while before getting
the right one from the network.

And just tried. Switch to fligh-mode, and reboot phone. The time is all wrong.
Depends on: 1032233
I've found that NTP may be related: if I switch on/off the NTP via Settings, it sometimes get wrong time.
Maybe low quality network can affect it, however I'm not sure.
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9)
> So maybe this bug is actually two
> bugs: one is for the alarm, and another is for the clock.

I'm not sure how we'd separate them unless we have evidence that other system time things (Calendar notifications?) are functioning properly while the Clock alarm is clearly sounding at the wrong time.

This seems likely to be a dupe of bug 1032233 (or some related confusion around system time) -- so removing the 2.0 nomination until we can get more information specific to the Clock app.
blocking-b2g: 2.0? → ---
I've reproduce one of these cases with hardware manipulation:

1. Make sure your time is correct
2. Remove your battery while it's power on
3. Wait about 30 secs to 5 mins
4. The System time would randomly later/earlier from +10 hours to -10 mins

The step3, would randomly affect the clock (system clock). We've tried to wait 5 mins twice, but only the first time it give the incorrect time, while in the second try it keep to the time before the battery got removed. 

Moreover, in one case the Clock app, it's icon missing from Homescreen. And I'm pretty sure only it got disappeared, while the other apps are all there. After reboot and adjust time to the correct date/time, the app appear again.
same thing, flame running 1.4 , alarm at 9am, rings at 7.3x am.... then set it again at 9.05 as a test, and it ring with different ring tone and no snooze/stop screen, just one ring and disappears... weird.
It should be fixed quite soon imho....people count on their alarm...missing a plane or such is no fun...
Yes, that's why I think this is a very serious bug, but with STR very difficult to reproduce. Unfortunately, I don't know who now is working on this, or have a clue how to pin down the root cause. Maybe we should have more people to dogfood with Flame to caught the problem, although we have only so few people already do that.
So I haven't see this recently. Probably after Bug 1032233 was fixed.
I wonder if 1.4 has some other Alarm related issue - I'm dogfooding only 2.1.
Hi guys,

incredibly today after I given up using Flame as alarm  I decided to use a brand new 500$ android tablet.... only to find it didnt work either ?!?!?!... what's wrong these days with simple programs??? Maybe the problem is on the underlying android libs rather than the firefox os part?

http://forums.androidcentral.com/verizon-samsung-galaxy-s4/385811-alarm-not-working-all-time-after-getting-kitkat.html

I would say to put this thing into show stopper level... first time someone comes up with a big review and says alarm doesnt work...we're screwed.. eh.... 

also errata on my previous post: I run 1.3 on flame out of the box..etc. (not 1.4)
Blocks: 1069863
No longer blocks: 1069863
Depends on: 1069863
Inconsistent alarms experienced with zte open c on firefox os 1.3 as well.
For tracking purposes - 
Another user in the SUMO forums is reporting this issue with two different devices:
https://support.mozilla.org/en-US/questions/1009059#answer-645139

ENVIRONMENT:
ZTE Open (Movistar) with FFOS 1.1
GeeksPhone Revolution with FFOS1.3

USER VERBATIM:
"In both cases the alarm clock rang one hour before the set alarm (5:45 instead of 6:45) and then at 6:45 again. Maybe it's worth mentioning, that both times it was a friday (Friday October 3 and Friday October 24). In both devices the alarm was set for "every day" (monday to sunday), vibration turned off.

Last time it happend, the device (Geeksphone) was connected to a PC via USB for charging. The PC (win7) was running when the phone was connected, but it was shutdown in the evening, so it was off when the alarm(s) rang."

USER WRITES BACK WITH ADDITIONAL INFORMATION:
The user from the report mentioned in comment 39 provided some additional information -

ENVIRONMENT: Geeksphone Revolution v1.3

USER VERBATIM:
"The last reboot was yesterday evening at about ~6pm. 
The first (false) alarm was this morning at 5:45am, so about 12 hours later. 
Then at 6:45am the correct alarm rang too.

I think I also remember that a few weeks ago an alarm was completely dismissed."
Can we set a higher Importance here?
It blocks users from using the Flame in production. And I hate it to woke up at the wrong time -.-
Was it solved by Bug 1118272 ?
Flags: needinfo?(sjw)
I can't finally verify this, because my alarm clock stops working completely for a while. I'll now continue to observe it.
Flags: needinfo?(sjw)
I got woken up at 5:05 in the morning today on Z3C[1]. Since this device doesn't have issues with time (unlike the Flame), I think this bug is still valid. Here's attached a logcat showing that there was no activity on my phone for half an hour, and then at 5:01, the alarm was fired for 5:05. Gaia debug traces are enabled in there.

An interesting line is the following:
> 06-19 05:01:05.709  9926  9926 I Clock   : Content JS LOG: [Clock] ### ALARM FIRED! ### Details: {"id":721,"date":"2015-06-19T05:05:00.000Z","respectTimezone":"ignoreTimezone","data":{"id":1,"type":"normal","date":"2015-06-19T05:05:00.000Z"}} 

If I understand correctly, the timezone was ignored. As I'm currently in UTC+2 and my alarm is set to 7:05am, that would explain the behavior.

Additional notes: 
* After I deactivated the 5:05am alarm, the one at 7:05 rang as I wanted
* I didn't change the alarm before going to sleep. This alarm has been set to 7:05 for at least a week. This is the first time it didn't ring at the correct time.
* When I was on 2.1, I also got this issue a couple of times. I thought it was related to the internal clock of the Flame, though, and 2.1 didn't have logshake to be able to get a logcat in the middle of the night.

[1] Build ID               20150618035728
Gaia Revision          b404c41c5471c31610e64defb74ec066b411e724
Gaia Date              2015-06-17 17:01:15
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/a3f280b6f8d5
Gecko Version          41.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150612.053308
Firmware Date          Fri Jun 12 05:33:15 UTC 2015
Bootloader             s1
[Blocking Requested - why for this release]: If we want people to dogfood, we don't want them to have reasons to get upset against Firefox OS :)
blocking-b2g: --- → spark?
Flags: needinfo?(drs)
Flags: needinfo?(doliver)
Keywords: dogfood
(In reply to Olli Pettay [:smaug] from comment #10)
> And just tried. Switch to fligh-mode, and reboot phone. The time is all wrong.
If it's on the Flame, that's also probably due to bug 1110010.

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9)
> I saw the alarm correctly wake me up at *its 8:00AM*, however the real time
> is 6:00AM. So maybe this bug is actually two bugs: one is for the alarm, and
> another is for the clock.
Agreed, let's track this bug for the timezone-like issue. Changing the name accordingly.
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-master: --- → affected
See Also: → 1110010
Summary: [Flame][2.1] Alarm clock alarms at random times → Alarm clock is intermittently fired at random times, even though the correct time is displayed on the status bar
I experienced this bug for a long time, I moved timezones and all, but it doesn't seem to be the real reason. It's definitely something to do with how long/when you plug it in a computer with a usb to charge it. 'Every' time I do it, the alarm goes bonkers....
(In reply to Ronald Claveau [:sousmangoosta] from comment #24)
> Was it solved by Bug 1118272 ?

(In reply to sjw from comment #25)
> I can't finally verify this, because my alarm clock stops working completely
> for a while. I'll now continue to observe it.

There are still some issues in the following cases:
a) after Firefox OS crashed
b) Low battery / energy safe mode
c) Flame was switched off for a some hours
d) Flame was/is in flight mode

This is mostly because it fails to set the correct timezone and/or the alarm ring before the current time is set.
See Also: → 1178208
blocking-b2g: spark? → 2.5?
QA Whiteboard: [foxfood-triage]
See Also: → 1181489
Flags: needinfo?(doliver)
Worked for me on my Z3C device. However, it isn't instantaneous - still a few seconds delayed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
I think all these issues are inherently intermittent issues; so it's difficult to say "ok, it worked this time, so this is working".
Agreed with comment 33.

I dup'd bug 1179208, because this current bug is not Flame-specific. See comment 26.

Side note: The logs I uploaded don't show it, but I have the feeling it's the same root issue as bug 1180257.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #35)
> the same root issue as bug 1180257.
I meant bug 1181489.
blocking-b2g: 2.5? → 2.5+
Flags: needinfo?(drs)
triage: P1 as this is now on Z3C too -- we need to get a handle on what is happening here.
Priority: -- → P1
Dylan, note that this is likely bug 1181489.

(but all these bugs are interlinked anyway)
Tim, please verify this bug with you patch in bug 1181489.
Flags: needinfo?(tihuang)
The patch of bug 1181489 already landed, you could try this bug on that patch.
Flags: needinfo?(tihuang)
Hi William, can you please help test this?
Flags: needinfo?(whsu)
(In reply to Ken Chang[:ken] from comment #42)
> Hi William, can you please help test this?

Hi, Ken,

Thank for the information. :)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi, Norry,

Please assign an engineer to verify this patch (bug 1181489)
Thank you.
Flags: needinfo?(whsu) → needinfo?(fan.luo)
Hi William,
I used patch of “bug 1181489” to build a new Rom. And I get following behaviours about this bug after flashing the build.
1. After flash, go through the FTU, then you can find the system time is incorrect.
  1.1 Connect to a wifi access point.
  1.2 Enable the "Set Automatically" from Settings - > Data & Time, and select the correct Region and City.
Behaviour: The time automatically retrived by system is still incorrect. The system time will change only if user reboots device, and user can set the time to be correct successfully.

2. After setting system time to be correct, create an alarm which will go off 5 minutes later.
3. Reboot device.
**After reboot, you can find that the system time is still correct (same as that before reboot)
4. 5 minutes later, the alarm goes off as expected at the time you set, and at this time system time is correct.

So I guess we find another bug in Step 1, but given the behaviour of  Sep2 to Step4, we can say this bug has been fixed. 
May I know your opinion? Thanks!
Flags: needinfo?(fan.luo) → needinfo?(whsu)
See Also: → 1180257
According to Sandking's information, I think this bug has been fixed by Gecko commit-"f7b98d678e3e" (Bug 1181489).
We can close this bug and solve the remaining issue on Bug 1180257.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Flags: needinfo?(whsu)
Resolution: --- → DUPLICATE
Thank you, Mahendra! :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: