1052245 - [Meta] [ZTE Open C + Other devices] Alarm clock rings at the wrong times, or does not ring

Status: RESOLVED WONTFIX

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

Description

[Ralph Daub [:rdaub]]

There have been reports on the SUMO forums and User Advocacy's Input page about alarms firing off at random times - sometimes in the middle of the night, or hours before the real alarm is supposed to ring.

I'm hoping that there may be some troubleshooting steps that might help resolve or investigate this issue.

STEPS TO REPRODUCE:
There doesn't seem to be specific steps to reproduce this issue. The user simply adds an alarm to the clock app.

EXPECTED RESULTS:
An alarm should ring at the configured time.

ACTUAL RESULTS:
The alarm rings at a random time, and then again at the configured time.

USER'S VERBATIM:
https://support.mozilla.org/en-US/questions/1009059
https://input.mozilla.org/en-US/dashboard/response/4513154
https://input.mozilla.org/en-US/dashboard/response/4281209
https://input.mozilla.org/en-US/dashboard/response/4024276
https://input.mozilla.org/en-US/dashboard/response/4015124


Please let me know if there is any information I could provide to help with the investigation and troubleshooting of this issue.

Thanks!!

- Ralph

Comment 1

[Ralph Daub [:rdaub]]

Attachment: Alarm ringing at the wrong time

Comment 2

[Ralph Daub [:rdaub]]

For tracking purposes - 
Another user is reporting this issue in the SUMO forums: https://support.mozilla.org/en-US/questions/1015102

Comment 3

[Ralph Daub [:rdaub]]

For tracking purposes -
Two users recently posted on the Mozilla Hispano forums to report experiencing this issue as well.

User:     Cyprexx
Device:   ZTE Open II
Feedback: "Alarm sounds too often, and during times that it's not configured. It's now 7:45pm and it just sounded an alarm for 2am."
Link:     https://www.mozilla-hispano.org/foro/viewtopic.php?f=47&t=17573&start=10#p72249

User:     Javi
Device:   TCL OTF C
Feedback: "Today it was programmed for 8am. It didn't ring, then I restarted the phone at 10am. As soon as it turned on, the alarm rang, when it was clearly showing 10am."
Link: https://www.mozilla-hispano.org/foro/viewtopic.php?f=47&t=17573&start=10#p72607

Comment 4

[Ralph Daub [:rdaub]]

For tracking purposes -
Another user is reporting this issue in the SUMO forums: https://support.mozilla.org/en-US/questions/1009343#answer-628459

Device: ZTE Open, FFOS2.0 Custom Build

Comment 5

[Julien Wajsberg [:julienw]]

See also bug 998209.

Comment 6

[Clément Lefèvre]

[Blocking Requested - why for this release]: Sounds like this happens on the Open C as well.

Comment 7

[Candice Serran (:cserran)]

Need to QA to try to reproduce

Comment 8

[Andrew Overholt [:overholt]]

The triage group decided that we *really* need to fix the clock situation so we're marking this as a blocker.

Comment 9

[Cody Roesch [:croesch]]

I could only do limited alarm testing for this bug because we are flashing our devices all the time to new branches, and I don't have a flame device to let sit all day and wait for alarms. But I did set up several times that I could wait for and several that should not trigger while I waited and I did not experience any issues with alarms triggering when they should not.

I noticed on a lot of the posts that were written in the different forums listed in the comments above, that people were setting reoccurring alarms (Mon,Tues,Wed etc.) I tried to mess around with this more because it seems likely that this may be a problem area.

Tested with Shallow Flashes set to 319mb

This bug does NOT repro on Flame kk build: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK

Actual Result: All alarms set that should trigger did trigger at appropriate times and alarms set in the future did not trigger.

Repro Rate: 0/14

Environmental Variables:
Device: Flame Master KK
BuildID: 20141001060621
Gaia: a23d2c490b39c4699c9375e25c4acdf396a2fa85
Gecko: 835ef55e175e
Version: 35.0a1 (Master) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141001060122
Gaia: b327c640fea887770d011a127e349838b3b44724
Gecko: 7359d0d0222d
Version: 34.0a2
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0
BuildID: 20141001060124
Gaia: 8079cba2133e6f5443dba24dad077f7f91e6c978
Gecko: 66c1ea78b6c1
Version: 32.0 (2.0) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Leaving QAWanted tag to see if another tester can repro.

Comment 10

[Clément Lefèvre]

It actually happen at random times, I wasn't able to find a workaround to exactly reproduce it when I want.
I thought it was linked to recurrent alarm as it happened to me on those alarms only, but recently it happened to non-recurrent alarm too, as for ringing when it shouldn't or don't ringing when it should have.

Still on a ZTE Open C with out-of-the-box ROM, based on Firefox OS 1.3.

Comment 11

[Dietrich Ayala (:dietrich)]

This problem has been around since pre-1.0. All it takes is one missed plane or missed job interview to destroy Firefox OS forever in the eyes of a user.

I think we need to do a few things:

* Have one of the devs of clock add some debugging code into master to log relevant information.

* Once that is in place, rally dev-gaia to set a ton of alarms.

* Get QA a couple of devices to dedicate to this testing. Tony, can you help with this?

Comment 12

[Dietrich Ayala (:dietrich)]

Dylan, can you find the right person on your team who can add the debugging info described in comment #11?

Comment 13

[Dylan Oliver [:doliver]]

(In reply to Dietrich Ayala (:dietrich) from comment #12)
> Dylan, can you find the right person on your team who can add the debugging
> info described in comment #11?

Marcus will add logging on master to see if we can find & analyze any time mismatches when the alarms fire.

Comment 14

[Marcus Cavanaugh [:mcav]]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24768

This patch adds logging of all relevant data:

- system time
- system timezone offset
- indexedDB alarm data
- scheduled mozAlarms
- currently-firing mozAlarm data

It logs them at these times:

- at startup
- every 10 minutes, while clock is open
- at alarm firing

It produces the following output to the console:

[Clock] ### ALARM FIRED! ### Details: {"id":5,"date":"2014-10-03T12:38:13.772Z","respectTimezone":"ignoreTimezone","data":{"type":"timer","date":"2014-10-03T12:38:13.772Z"}} 
[Clock] =====================================
[Clock] Alarm Debug: {"now":"2014-10-03T12:38:13.780Z","tz":240} 
[Clock] ===== Remaining mozAlarms: =====
[Clock] --------------------------------
[Clock] ===== Raw IndexedDB Alarm Data: =====
[Clock]    {"id":1,"registeredAlarms":{},"repeat":{},"hour":8,"minute":24,"label":"","sound":"ac_awake.opus","vibrate":true,"snooze":10} 
[Clock]    {"id":2,"registeredAlarms":{},"repeat":{},"hour":8,"minute":28,"label":"","sound":"ac_awake.opus","vibrate":true,"snooze":10} 
[Clock]    {"id":3,"registeredAlarms":{},"repeat":{},"hour":8,"minute":36,"label":"","sound":"ac_awake.opus","vibrate":true,"snooze":10} 
[Clock] -------------------------------------

Comment 15

[Miller Medeiros [:millermedeiros]]

Comment on attachment 8499738 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24768

LGTM! logging ALL the things!

Comment 16

[Marcus Cavanaugh [:mcav]]

Logging in master: https://github.com/mozilla-b2g/gaia/commit/5430bbee9a821e2880706cfa02afecd878b7b737

Comment 18

[Julien Wajsberg [:julienw]]

> - every 10 minutes, while clock is open

I wonder how this can affect battery?

Comment 19

[Marcus Cavanaugh [:mcav]]

(In reply to Julien Wajsberg [:julienw] (PTO until 7th October, ask :steveck or :azasypkin for SMS stuff) from comment #18)
> I wonder how this can affect battery?

It seems exceedingly unlikely that this would measurably affect battery life. It doesn't touch the radio or any other physical hardware, nor does it consume much CPU. If we find it does affect the battery, we can pull it out -- which we'd ideally do anyway, upon finding the problem, well before we branch 2.2.

Comment 20

[Marcus Cavanaugh [:mcav]]

(The periodic log was added to catch the possible scenario that something system-related causes the mozAlarms to change, and that we might be able to better pinpoint such a cause by regularly monitoring the expected vs. actual settings.)

Comment 21

[Dylan Oliver [:doliver]]

(In reply to Dietrich Ayala (:dietrich) from comment #11)
> This problem has been around since pre-1.0. All it takes is one missed plane
> or missed job interview to destroy Firefox OS forever in the eyes of a user.
> 
> I think we need to do a few things:
> 
> * Have one of the devs of clock add some debugging code into master to log
> relevant information.
> 
> * Once that is in place, rally dev-gaia to set a ton of alarms.
> 
> * Get QA a couple of devices to dedicate to this testing. Tony, can you help
> with this?


We have done the first two items here and hopefully that will help us diagnose the issue. But given the difficulty in reproducing so far and the lack of any clear STR, I don't feel that this is something we can block on at this point. If we find and fix the issue we would certainly pursue approval for uplift.

Comment 22

[Julien Wajsberg [:julienw]]

(In reply to Marcus Cavanaugh [:mcav] <[e-mail]> from comment #19)
> (In reply to Julien Wajsberg [:julienw] (PTO until 7th October, ask :steveck
> or :azasypkin for SMS stuff) from comment #18)
> > I wonder how this can affect battery?
> 
> It seems exceedingly unlikely that this would measurably affect battery
> life. It doesn't touch the radio or any other physical hardware, nor does it
> consume much CPU. If we find it does affect the battery, we can pull it out
> -- which we'd ideally do anyway, upon finding the problem, well before we
> branch 2.2.

One of the battery-saving operation is that the phone goes in super-idle state (I don't know how it is really called). My guess is that this super-idle state is what triggers the issue. Therefore here is what I am afraid of: the bug is worked around by this log because it will prevent entering the super-idle state :) But we'll see...

Comment 23

[Dietrich Ayala (:dietrich)]

Triage group still thinks we should block. As our user base grows, this will damage yet more lives.

Dylan, we should escalate to the drivers meeting maybe?

Comment 25

[Joshua Mitchell (Inactive)]

qa-wanted team has had a few flames and an open-c with alarms set and monitored them the last few days with no-repro.

might be Open 2 specific

Comment 26

[Dietrich Ayala (:dietrich)]

(In reply to Joshua Mitchell [:Joshua_M] from comment #25)
>
> might be Open 2 specific

I've experienced it on a variety of devices, finally just stopped using it as an alarm clock.

Comment 27

[Marcus Cavanaugh [:mcav]]

Attachment: Logcat from Youtube Video STR

Comment 28

[Marcus Cavanaugh [:mcav]]

I have tracked down STR; as some had suspected, this is a system time
bug (i.e. some combination of RIL/device settings). For the flame: Not
only does the system not persist time across reboots (bug 1069863),
but crucially, upon a reboot, the system time can end up hours in the
future. When this happens, Clock alarms fire -- as you would expect,
since the system time has advanced past the time when the mozAlarm
should fire.


Steps to Reproduce & Video
----------------------------------------------------------------

I could only reproduce on a Flame; see extended discussion on device
specificity below. But I suspect that these symptoms would be seen
immediately preceding any instance in which the Clock alarm misfires.

1. Set the System Time to the correct time. (I do not believe that it
   matters whether or not the time was automatically set.)

2. Set a Clock alarm for a couple hours in the future.
   (This step is not strictly necessary; the logic above explains
   why Clock alarms are firing.)

3. Reboot the phone.

4. Observe that the system time is wrong. If the resulting system time
   is later than the time for the Clock alarm you've set, the clock
   alarm will fire immediately. If the time is before, the alarm will
   not fire (but will probably fire at the "wrong" time, when the
   system clock catches up).

A video of me following the STR (flame-kk, master, wifi only):
https://www.youtube.com/watch?v=OqIyOujuHyU&feature=youtu.be

I've attached a logcat (which I took during the video), but I don't
think it shows anything relevant other than one line mentioned below
in note F.

The system time was always wildly incorrect after reboot in my
testing, but it varied whether the subsequent "Automatic Date/Time"
correction would actually update the phone to the correct time.


Notes/Issues/Leads
----------------------------------------------------------------

A. Sometimes, after a reboot, the "Set Date/Time Automatically"
   setting doesn't actually correct the system time, as it did in the
   video. The system time will remain wrong, and toggling the "Set
   Date/Time" and/or airplane mode has no effect.

B. Note that in the video, there are three different times: The system
   clock, the statusbar clock, and the wall clock are all different.

C. I was also able to reproduce this with "Set Date/Time
   Automatically" set to off -- since the system clock's time doesn't
   persist across reboots, the only thing "Set Date/Time
   Automatically" seems to do is present another opportunity for the
   clock to be wrong (see point A above).

D. The timezone, in all cases, remains correct, in that JS reports the
   proper offset. Note that the time differences do NOT align to
   timezone boundaries; thus it does not appear to be timezone-related.

E. If you run "adb wait-for-device && adb shell" and then repeatedly
   mash the "date" command into the shell, you'll note that the system
   time begins WAY in the past (sometime in May, on my phone), before
   jumping to whatever time it decided to settle on. So it's not just
   an issue of being reset to some sort of epoch; something else
   causes a time change too.

F. One error message appears in my console whenever I change the time:

     "alarm_set_rtc: Failed to set RTC, time will be lost on reboot"

   This explains the lost system time on reboot, but not the
   subsequent "future time-travel".

G. The phone I was testing on did NOT have a SIM card; this was
   reproducible on wifi only.


On the SUMO forum reports and "Is This Flame-Specific?"
----------------------------------------------------------------

The screenshot at
<https://support.mozilla.org/en-US/questions/1009059> also shows a
glaring mismatch between the system time and the alarm firing time.
That was also a Flame.

I know that Dietrich has reproduced this on a number of devices, so
I'm inclined to think that they experienced the same System Time
anomalies seen here. If those devices appear to show the correct time
on startup,it's still possible that they experience the "system time
changes twice during startup", but end up correcting themselves. If
the system time leaps into the future at all, it seems possible that
mozAlarms would fire even if the system subsequently corrects itself.

The ZTE Open C reports are harder to analyze, as they include no
screenshots and only symptoms. There were known bugs in v1.3 and
earlier with regard to clock alarm firing, and there is not enough
information in these reports to determine whether or not they're
caused by those (fixed) bugs or this one. I do not have an Open C with
which to test.

I don't yet know if this is Flame-specific. It seems likely, but the
Clock App symptoms described here will occur with any device whose
system time leaps into the future.

Even if it _is_ Flame-specific, I don't think we can conclude much
from the Open C reports without more data; again, devices <= v1.3 may
be encountering other Clock-app specific bugs. In any case, we're
blocking on this for 2.1, which makes the ZTE Open reports irrelevant
in terms of this particular blocker. I don't think I've seen any bug
reports from other devices >= 1.4 regarding alarm firing times, but
most people have been dogfooding Flames since then.

I could NOT reproduce any alarm or system time issues on my old-style
ZTE Open, nor on my Nexus 4.


Theory & Conclusions
----------------------------------------------------------------

The system time issue explains all of the "Clock alarm misfire"
reports perfectly -- sometimes alarms fire late, sometimes not at all
(and then subsequently at random times). I would expect that
regardless of device specificity, the system time issues are the
culprit, based upon how Clock's alarm logic works.

While this bug is definitely related to "not persisting time across
reboots" (bug 1069863), that in and of itself wouldn't cause the
behavior seen here. The alarm firings occur because the system time
teleports far into the _future_ upon resume, which is a different,
though likely related, problem.

I do not think we can work around this in the Clock app for v2.1;
there's no way for Clock to know if an alarm is firing "late" because
'the phone was off' vs. 'the system time was broken', and our target
market may turn off their devices from time to time to save battery.

I will attempt to find an Open C at the office tomorrow and continue
to poke around for more information and reproducibility.

Since this is clearly a system time bug, I'm moving this to another
component for visibility; I'm unclear as to which component this best
fits into, so please redirect if appropriate.

Comment 29

[Clément Lefèvre]

@Marcus Cavanaugh : So what about the ZTE Open C here? I mean, I red all of your explanations, and don't think it's 100% the same problem. Maybe the problem you expose here can be related and part of the problem, but not alone, here's why :

- I didn't noticed time difference between displayed time and real time.
- The phone rang some times several time in an hour, a different day from the one programmed to ring (for example, programmed to ring on Monday, Wednesday, Thursday and Friday to, maybe 6:50 ; got some rings at several times like ~13, 15, 19 and so on on a…Sunday.

My guess is that if it was just a time jump/travel of the intern phone time, it would just have ring ONE time at a wrong hour, not several, at several time as I didn't rebooted the phone? Unless an alarm firing was causing a new intern clock change.

Comment 30

[Julien Wajsberg [:julienw]]

Marcus, I disagree with you here. For a simple reason: we get the issue even without rebooting.

FWIW I didn't get this behavior on Flame but on Peak (and I still do on my Peak that I left with a v1.4 build, btw). The behavior I see is that it doesn't wake up properly, and that the alarm rings when it wakes up for some reason (on the Peak, it's when I press "power" to wake it up). I can try to update it and see.

What I definitely saw on Flame (v2.0 though): the alarm was confused by timezone changes (note: this is what seems to happen on the forums).

I think this can be 2 different issues.

Maybe this issue on Flame can have its roots in the mozAlarm API, while the Peak issue can have its roots in some low-level capability to wake up the phone at the proper time. 

I also think I got the timezone issue on Peak back at the time. So maybe the "ignoreTimezone" part of the API is buggy.

Comment 31

[Jessica Jong [:jessica] (inactive)]

I wasn't able to reproduce this (system time set to an arbitrary time after reboot) on Flame, with v180 base image + today's (Oct 9) master + NO SIM + wifi connected. What I observe from the logs with '-v threadtime' is the following:

1. On device bootup, it starts in a very strange time (and this is on every bootup):

> 01-01 08:04:46.879   192   192 I Vold    : Vold 2.1 (the revenge) firing up

2. When RIL is up, it is set to /system/b2g/b2g last modified time, see [1]

> 10-09 14:36:54.010   208   208 I Gecko   : -*- RadioInterface[0]: 'ril.cellbroadcast.disabled' is now [false,false]

3. When wifi gets connected, SNTP will start working, and it is set to the correct date/time:

> 10-09 17:40:05.510   208   208 I Gecko   : -*- Sntp: Scheduled SNTP request in 86400000ms


I am not sure how QC-time-services works here, if the date/time should persist across reboots, then I think we should ask for partner's help, and it looks a lot like what bug 1069863 is doing. IMHO, the description in comment 28 and the current bug title seems to be a dupe of bug 1069863, maybe we should track the issue mentioned in comment 30 in a separate bug? or was this bug supposed to track the alarm issues (w/o reboots)?


[1] http://hg.mozilla.org/mozilla-central/file/f0bb13ef0ee4/dom/system/gonk/RadioInterfaceLayer.js#l3090

Comment 32

[Tony Chung [:tchung]]

clearing ni? from me, as it sounds like this could be a system issue, not device dependent.  if there are particular tests that you'd like QA to run, please re-ping.

Comment 33

[Julien Wajsberg [:julienw]]

Jessica, from what you're saying, then the time is actually bad until we have either Wi-Fi or a GSM connection? Isn't it _exactly_ what Marcus is saying? ("set to /system/b2g/b2g last modified time" sounds like arbitrary to me; would be closer to the reality if it would be the user preferences file for example). I agree all of this is the same than bug 1069863 and that we should focus on the other bug (outlined in comment 30) here.

Comment 34

[Dylan Oliver [:doliver]]

I tested with an Open C and confirmed that it also has unpredictable system clock time at startup. With my device it always started with a date in the past but it wasn't consistent -- sometimes one day in the past, sometimes over a month. Even in the cases where I have a SIM and/or wifi turned on, the phone always displays an incorrect time on the first lock screen before it has had a chance to correct itself.

So I didn't see the exact same behavior where the alarms fire directly at startup because my phone was starting in the past instead of the future, but after connecting to wifi and correcting time then it would immediately fire any past due alarm.

Comment 35

[Hsin-Yi Tsai (she/her) [:hsinyi]]

According to comment 31, comment 33 and comment 34, it looks this is the duplicate of bug 1069863. I'll close this as a duplicate. Feel free to reopen if you don't agree.

I will open another new bug for comment 30 since most of the above discussion are around the rebooting issue. Having a clear scope and clean discussion thread for comment 30 is helpful in tracking and further investigating.

Comment 36

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hey Julien, 

While I am going to file a new bug for your comment 30, I smell bug 1031573 similar to your problem. Do you think they are the same? Should we track there or a new bug is more appropriate? Thank you.

Comment 37

[Jessica Jong [:jessica] (inactive)]

(In reply to Julien Wajsberg [:julienw] from comment #33)
> Jessica, from what you're saying, then the time is actually bad until we
> have either Wi-Fi or a GSM connection? Isn't it _exactly_ what Marcus is
> saying? ("set to /system/b2g/b2g last modified time" sounds like arbitrary
> to me; would be closer to the reality if it would be the user preferences
> file for example). I agree all of this is the same than bug 1069863 and that
> we should focus on the other bug (outlined in comment 30) here.

Yes. From my experiments, the time is bad until we have either wifi or a data connection. But the main problem is: the time is not preserved across reboots, so even you get the correct time, it is messed up again on next boot. This problem is being investigated in bug 1069863.

Comment 38

[Julien Wajsberg [:julienw]]

Hsin-Yi: ok for me. Anyway we have several issues and we need to tackle one by one. If we have more issues after we fix all of these, we'll file new bugs :)

Comment 39

[Ralph Daub [:rdaub]]

For tracking purposes - 
Another user in the SUMO forums is reporting this issue with the same behavior reported in Comment 0, 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."

***********

I understand that this bug is currently marked a duplicate of bug 1069863, but this user report may (possibly) be evidence that the alarm issue happened without a reboot. I also inquired the user if he noticed a reboot on the device and will update this bug once I receive a response.

Thanks,
- Ralph

Comment 40

[Ralph Daub [:rdaub]]

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


OTHER THOUGHTS:
Adding Needinfo from [:hsinyi], [:jjong], [:mcav] and [:julienw] to decide if the bug is still a duplicate of bug 1061797 or some other system time issue.

Comment 41

[Julien Wajsberg [:julienw]]

I already said it, I think we have several different issues but it it's difficult to set them apart.

Comment 42

[Jessica Jong [:jessica] (inactive)]

Hi Ralph, we set it as a duplicate of bug 1061797 cause latter part of the bug indicated that the root cause was "time is reset after reboot until we have a network connection". Since different issues were discussed in this bug, to make things clearer, maybe we should file a brand new bug to track alarms issues (without a reboot) only. What do you think?

Comment 43

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Ralph,

Just echo Jessica on the reason we set this as a duplicate of bug 1061797. The reason is still valid to me.

According to your latest comment 40, it does sound another issue other than 1061797 at least based on the STR and scenario. Is it related to bug 1031573? If no, filing a new bug for tracking the issue seems help discussion focused.

Comment 44

[Ralph Daub [:rdaub]]

Hi Hsin-Yi, thanks for the input.

The behavior described in comment 40 and in some of the reports from comment 0 appear to be related to bug 1031573. Thanks for the suggestion, I will update that bug with this information.

- Ralph

Comment 46

[Ralph Daub [:rdaub]]

Another user in the SUMO forums is reporting the alarm clock issue on a ZTE Open C:

https://support.mozilla.org/en-US/questions/1046603

I am reopening this bug and renaming it reflect the issue that was originally described in comment 0. 

The ZTE Open C does not suffer from bug 1069863. Therefore reason described in comment 28 is not a valid explanation the alarm clock issues with the ZTE Open C device, as described in comment 0.

[:dietrich] Have you heard of any other users experiencing this issue?

The following users are reporting this issue on the ZTE Open C device:
* https://support.mozilla.org/en-US/questions/1009059
* https://support.mozilla.org/en-US/questions/1015102
* https://support.mozilla.org/en-US/questions/1046603
* comment 10

This is in addition to reports from users with other devices as well. 

Also adding needinfo to [:hcondei] to keep her in the loop.

Comment 47

[Clément Lefèvre]

I got some random alarm clock problems on a stock ZTE Open C months ago, but I'm unsure it happened again recently. Problems included alarm that didn't ring or alarm that was ringing at the wrong time or day or even several times a day (like, scheduled alarm from monday to friday, and ringing several times…a sunday…at different times  [noon, afternoon for example, while scheduled time is in the morning]).

Here are current infos of this one:

Build ID               20141011095656
Build Type             user
Gaia Revision          Unknown Git commit; build date shown here.
Gaia Date              2014-10-11 01:19:27
Gecko Revision         n/a
Gecko Version          28.0
Build Name             FFOS_FR_ZTE_OPENCV1.0.0B03
Device ID              ZTE_P821A10
Device Name            ZTE_OPENC
Firmware(Release)      4.3
Firmware(Incremental)  eng.mengzhaxi.20141011.091825
Firmware Date          Sat Oct 11 09:19:03 CST 2014

I heard that other persons had problems too on the same phone using 2.0+ community builds (Updated Gecko & Gaia but not low level layer) about time, date and so alarm too.
As dattaz is the one preparing these builds for people and he's aware for some of these problems more than me, I NI him, in case he could give more informations.

Comment 48

[Julien Wajsberg [:julienw]]

See bug 998209 comment 22, I have a reproducible STR that triggers symptoms similar to this bug. I _don't_ _know_ if that's the same issue, but that's one with a reproducible STR we can fix. Then we'll be able to look whether this bug still happpens.

This does not look like what the SuMo user is seeing though.

Comment 49

[dattaz]

Yes, some people report me they have same issue.
I just reproduice now: set alarme to 05:59, alarm ring at 07:44
No change of date or time (manually or automatically)
So STR of Julien is not what I have.

With a 2.2 build

Comment 50

[Panos Astithas (he/him) [:past] (please ni?)]

My latest weird experience with a Flame on 2.2 is that *some* alarms ring both an hour later and at the right time. I'm not sure when that behavior started as I flash almost weekly on Friday and my alarms are set on weekdays, so I experience any issues on Monday.

Of course now I don't get any alarms at all, due to bug 1134649.

Comment 51

[Jean-Baka]

Hi there,

Since I purchased my ZTE Open C (in France), I have always experienced random issues with the alarm not ringing at the correct time. It was originally on FFOS 1.3, then on 2.2 (aurora build by dattaz) and finally now in 3.0 (nightly from MozFR, uploaded two or three days ago and also built by dattaz, I think -- thanks, dattaz!)

This morning, interesting behaviour: alarm set at 6:06 am, then I switched on the flight mode, and the alarm didn't ring until I press the "on/off" button on top of the phone to switch it on: it was now 6:43 am, and the alarm immediately went off. I must add the screen lock option was also activated. So it seems the alarm doesn't ring until an event occurs, e.g. user switching the screen on or maybe events from some data connection?

It is probably unrelated, but worth mentioning it so that you point me to the correct bug report: the icons in the status bar on top of the screen are sometimes not in sync with the true status of the phone, depending on the application. For example right now, as the wifi is deactivated and the GSM network is on, I have:
(1) "screen lock" screen: ok (no wifi icon, GSM network steady)
(2) after I unlock the screen, homescreen with large icons: BAD (GSM icon says "searching for a GSM network" and wifi icon on AND wrong time, i.e. 14:01 while it's in truth 15:44)
(3) going into the mail app: all wrong, same as (2)
(4) back to home screen, tapping to slide down and get the parameters/notifications screen: all icons correct, as in (1)
(5) SMS app: all wrong, as in (2)
(6) browser: all icons good, as in (1)

Etc (I won't try all the apps here)..

Thanks for your info on this!

Comment 52

[Julien Wajsberg [:julienw]]

This is not a support forum, so please refrain yourself from asking unrelated questions on a bug. There are other channels for this (eg: the mailing list, IRC...) . The sync icon issue is maybe bug 1112706 (but it's supposed to be fixed).

Comment 53

[BMO Automation]

Firefox OS is not being worked on