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
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
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.
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 )
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
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?
Yes, 4.4 even. My X10iii still is on Vanha Rauma.
I shall try a backported timed, thanks a lot for the link!
Has anyone observed a clock alert failure (of any kind) on 4.6.0.13?
Please describe what was it like.
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.
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.
I’ve also had a timer fail to go off a couple of times, not just an alarm. And that was on sauna.
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.
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”.
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.
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.
As adviced in some reply I always restart the home sceen after setting the alarm an no misses after that procedure.
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 ?
On my Xperia 10 plus with Sauna, the alarm is working but automatically snoozes itself one minute later and does not ring again.
Few days ago I set an alarm in the evening without restarting the homescreen after alarm setting. Mobile data was offline. Once during night I switched on the screen to check the time from the home screen. The alarm was not functioning. XPeria 10 II with Sauna installed.
Thanks for this hint. I’ll add it to the related internal bug.
XA2, SFOS 4.6.0.13.
Alarms failing ATM. I can keep that state till 10 pm UTC.
Saw “only once” alarms just beeing disabled wo going off.
Saw recurrent alarms most of time getting disabled wo going off. Once it stayed enabled.
Logs are not consistent, sometimes there is systemd[2728]: Starting Alarm ui…, but not always.
After “ngfd restart” there was a dbus message with comm="/usr/bin/timed --systemd".
systemctl list-unit-files|grep timed doesn’t give anything.
Logs saved with journalctl --no-pager >> log.$(date ‘+%Y%m%dT%H%M%S’).txt.
Any suggestions?
Ping @dcaliste @nephros @pvuorela
EDIT: “settings” doesn’t start/show up, hmmm…