[Clock app] Scheduled alarms fail

Bug Reports
#9

It doesn’t look like just the sound, because during the first 10 minutes past the scheduled time there was nothing, not even the notification. I will further investigate it. Let’s see when it comes back.

Either way, along with some Calendar alarms also broken by 4.5.0.x update, this makes all SFOS alarms/reminders completely unreliable, and I am starting to wonder how can I continue to use this phone as my daily driver if I can never be sure not only if it wakes me up but also whether it reminds me about important events. Should I be carrying a second device for that purpose?

4 Likes
#10

I can confirm. The same happens to me. Three different alarms set up at 5:45, 6:00 and 6:15, and none of them works. Neither sound nor notification.
Although it may seem a minor thing, this is a very serious issue for a basic function like this!

5 Likes
#11

I confirm that this has happened to me since upgrading to 4.5.0.19.

I have two alarms, each set for two week repetition (alternate alarms to put the black or the blue bin out) which fire at 19:00 the night before bin day.

Since upgrading, not only do the alarms not fire, but there is also no notification of a “missed alarm.” I have tried deleting and re-creating the two alarms, but they still don’t fire.

I’ve been holding on for the next OS update in the hope that it would have been noticed and fixed, as it’s a fairly major thing, alarms not firing. I have checked my ambience and the alarm sound is there and works… because I did wonder if it was an ambience thing since upgrading, but I’m clueless as to what could be causing it.

1 Like
#12

It happened to me too a few times since I updated my phone from SFOS 3.4 to SFOS 4.5 a few weeks ago. It’s just that I can’t reliably reproduce it, which makes it hard to write a proper bug report.

#13

Unfortunately, I have this bug regularly with the Xperia 10/III, like every two or three days When it happens all sound seems to be lost, can’t make calls, if I call my message box, don’t hear anything either. A complete reboot seems to be required.

Definitely agree with lupastro above, this is a very serious bug . I now have to take my old Jolla “the first one” along on any business trip with me and use it as the reliable alarm clock!

This bug has been there for at least the last three updates, ever since I moved to Xperia 10/III.

Updates and fixes from Jolla are much too infrequent! Testing totally inadequate! Jolla, we suffered your lousy browser for more than five years, it seems this wasn’t fixed until the Aurora developers put in some real work and now you no longer seem to be working with them for political reasons. The bullshit self-praise on LinkedIn and the Jolla blog is just sickening!. Sailfish quality is a disaster! The only reason I still use it is because it’s not Apple/Android and Ubuntu Touch is even more useless! Maybe you should dump some of the managers and hire more engineers instead of the other way around!

4 Likes
#14

like every two or three days

This means that you are using a particular workflow that enables this bug or you have a faulty device. It would be nice to have it so we can easily reproduce it.

There is this thread: [4.1.0.23][4.0.1.48][4.4.0.64][4.5.0.16] No notification sounds (ringing, SMS, alarm) and I’m pretty sure it’s the same bug as defined here. Please, continue there.

#15

I’m not at all sure the bug is due to the user workflow or a faulty device. I would really guess it’s not, because at least for me the bug happening or not happening seems to be completely random, and I find it inplausible that we all experiencing the bug would have similarly faulty device.

2 Likes
#16

I rarely have this problem on my X10-3. Surely because I do something different to you or because this machine is less affected than the XA2.

The user workflow should allow to find the differences and potentially reproduce the bug.

#17

I also sometimes see this on my phones (X10, Volla), my impression is, it has something to do with the powersafe mode of CPU / “deep sleep” / wake up on events from “idle”. Especially if the phone is untouched for hours before, the first user actions are sooo slooow. Waking up the device by pressing power button and unlocking with fingerprint goes rather fast (only a little bit slower than usual), but then (my impression is) the system needs abt. 10-15 seconds to completely wake up and work at usual speed after it was idle for hours. This is also in the early morning if the phone should wake me up after a long night. It doesn’t always.

1 Like
#18

The described bug is different from the one in linked thread – in that case, only notifications stop working (no sound, no vibration, phone screen not lighting up when there’s an incoming call), phone calls continue working just fine (and sound through phone speaker works). Still no idea what triggers it (I can have phone ringing, answer the call, finish it normally, and less than a minute later, the next call does not show any indication on the phone), but systemctl --user restart ngfd fixes the bug from the other thread (I set up a qCommand shortcut for it).

2 Likes
#19

In my case, the way this “scheduled alarms fail” bug manifested itself had nothing to do with the “no sound” issue. It was not just the alarm sound missing but there was completely NOTHING happening - not even the alarm popup (dialog / notification) shown. Then, after the snooze period (that I have set to 10 minutes) a SILENT notification was shown on the Events screen about the SNOOZED alarm that I never snoozed. And then, another 10 minutes later (i.e. 20 minutes past the scheduled time), the alarm eventually went off with all its sounds and notifications.

So it was definitely something completely different than the famous “sudden lack of sound” bug.

(Un)fortunately, since then I haven’t seen it again, so I couldn’t further investigate it.

#20

Interesting. I guess trying to notify could run into trouble with a dead ngfd.
My “occurrence” of this issue was just no sound at least one of the two times - i.e. there was vibration.

I tried reproducing three times now with stopping ngfd; but all three times it was brought back as if done by the alarm itself (as opposed to systemd supervision).

#21

Indeed, dead ngfd might prevent the notification. What’s strange, however, is how it then appeared as a silent notification on the Events screen about a snoozed alarm (it happened only after 10 minutes, i.e. when the allegedly snoozed alarm should have gone off anyway), and only after yet another 10 minutes the alarm went off as it should, with both sound and dialog.

Well, it never happened again, so I had no chance to further test it.

#22

I’ve never encountered this bug, lucky me since I use the phone as an alarm clock in the morning.

When it happen, may you look into the journal if there is any message that could be related ?

devel-su
journalctl -ar
2 Likes
#23

A workaround for this bug is to restart the home screen (via SFOS utilities).

When the phone has entered the “I do not want to trigger the alarm” state, a home screen restart seems to solve the problem.

Every night, before setting up the alarm I restart the home screen and since then, I have not had the problem anymore.

3 Likes
#24

In case it helps, I just had the situation that the Clock app seemed to be OK, but scheduled enabled alarms just went by without doing anything. Other sounds were OK so PA is working OK.

systemctl --user status timed-qt5 had a warning about

“No such slot: dsme-something”.

Restarting the dsme service produced an error that it couldn’t set up /dev/watchdog.

Exact log messages missing because I rebooted, sorry.)

This system has previously run out of power (emergency shutdown), then was booted to actdead by plugging a charger, and then later booted up properly.
After that, timed-qt5 was restarted manually (because it had ‘lost’ all alarms as reported somewhere else )

3 Likes
#25

So, the error message from restarting timed-qt5 is:

Aug 19 13:53:34 systemd[5495]: Starting Time Daemon...
Aug 19 13:53:34 timed-qt5[12701]: [W] unknown:0 - QObject::connect: No such signal dsme_mode_t::mode_reported(const string &)
Aug 19 13:53:34 systemd[5495]: Started Time Daemon.

Indeed, restarting Lipstick re-enables alarms. Simply restarting timed.service does not (they re-appear in the Clock UI, but do not fire.)

The journal from a successful firing of an alarm looks like this:

Aug 19 14:32:00 dbus-daemon[5527]: dbus-daemon[5527]: [session uid=100000 pid=5527] Activating via systemd: service name='com.nokia.vo
land' unit='jolla-alarm-ui.service' requested by ':1.156' (uid=100000 pid=12701 comm="/usr/bin/timed-qt5 --systemd" label="u:r:kernel:
s0")
Aug 19 14:32:00 DSME[2214]: IPHB: alarm state from timed: powerup=1, resume=1724079600
Aug 19 14:32:00 systemd[5495]: Starting Alarm ui...
Aug 19 14:32:00 [24074]: [W] unknown:0 - org.nemomobile.dbus import is deprecated. Suggest migrating to Nemo.DBus
Aug 19 14:32:00 dbus-daemon[5527]: dbus-daemon[5527]: [session uid=100000 pid=5527] Successfully activated service 'com.nokia.voland'
Aug 19 14:32:00 systemd[5495]: Started Alarm ui.
Aug 19 14:32:00 mce[1938]: tklock.c: tklock_datapipe_uiexception_type_cb(): uiexception_type = none -> alarm
Aug 19 14:32:00 mce[1938]: tklock.c: tklock_uiexception_rethink(): display state req: ON
Aug 19 14:32:00 mce[1938]: modules/display.c: mdy_display_state_leave(): current display state = POWER_UP
Aug 19 14:32:00 pulseaudio[5868]: E: [pulseaudio] classify.c: could not find group
Aug 19 14:32:00 pulseaudio[5868]: E: [pulseaudio] classify.c: could not find group
2 Likes
#26

This looks like Use new qobject signal connection api to avoid signal lookup failure · sailfishos/timed@09cb261 · GitHub

I’d guess this was on 4.5.0 if the fix wasn’t included?

#27

Yes, 4.4 even. My X10iii still is on Vanha Rauma.

I shall try a backported timed, thanks a lot for the link!

#28

Has anyone observed a clock alert failure (of any kind) on 4.6.0.13?
Please describe what was it like.

1 Like