[Clock app] Scheduled alarms fail

Bug Reports
#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
#29

Can’t swear it was after .13 - and in general morning memory is kind of fuzzy.
But i’m pretty sure pulse committing seppuku (as reported in other threads) prevented the alarm from going off altogether - not just making sound.

#30

Yes it happend for me for the first time after Sauna update. On XA2 dual.
Not much to describe, exept no alarm at the expected time… And alarm still scheduled in the alarm list afterwards.

#31

I’ve also had a timer fail to go off a couple of times, not just an alarm. And that was on sauna.

#32

Happened to me too a while ago.

Reminds me of the multiple bugs on Android when calling 911…

Or phones that get bricked when you roam to another country.

Sigh.

#33

I think it has still kept happening to me occasionally even since updating to 4.6.0.13. And I stress ‘updating’, I haven’t reflashed the OS, I’ve been doing OTA updates for the three years I’ve had the phone.

It hasn’t been so mission-critical thing since I took a habit of setting up my older XA2 as a back-up alarm for the morning shift days. The symptoms are still same as ever; I open the clock app at 5 am and the app got the alarm dot all lit up assuring me “no worry, man, i wake you up at 4.40 am”.

#34

I traveled with Xperias (X, XA2, III) since 2017 through most of Europe and I am reading this forum and its predecessor for years. I never heard of a phone bricked by roaming.
Using it in areas not covered by the hardware or the OS is another thing.

1 Like
#35

Just to clarify, not a bug in SFOS. This was an old bug in feature phones by Sony.

Once you stepped out of a plane, switched on your phone and it started roaming, it would reboot and get into an infinite loop. The fix was sending your device to the manufacturer, who would flash a new ROM. Not the most convenient thing when you are abroad.

The 911/112 bug is Android’s, nothing to do with Sony in particular. My comment was reflecting on the general lack of software assurance in mobile phones.

I now remember the Nokia N9 also had a nasty bug. When replying to an SMS, sometimes the reply would be sent to a different contact, the last one that messaged you. To prevent this, I always deleted all SMS after reading them.

1 Like
#36

As adviced in some reply I always restart the home sceen after setting the alarm an no misses after that procedure.

1 Like
#37

this week this issue happened to me every single day. I think i have a good opportunity here to investigate. How can i proceed ? Where can i find the logs of why this is not working ?

2 Likes
#38

On my Xperia 10 plus with Sauna, the alarm is working but automatically snoozes itself one minute later and does not ring again.