The fix is touching a low level library : the one saving the events to a database and updating the alarms accordingly. It should not affect any UI code.
Thanks, it also works on the Gemini PDA
Oh yes, I do. But since most of my recurring events are all-day events and because I don’t like being reminded at midnight, I only use reminders for a fraction of them…
For an all-day event you can set the reminder to go off e.g. 1 hour, or 2 hours, or 6 hours, or 12 hours before the event, and this way be reminded not at midnight but at 23:00, or 22:00, or 18:00, or noon, respectively.
That works. However, I would very often need a (first) reminder days in advance.
I rarely use recurring events with reminders, but i added one and I noticed this bug. Thank you @dcaliste for the fix!!
I’ve edited the thread title as it wasn’t correct.
I have this issue again, I’m in sfos 4.5.0.24, and it wasn’t working in sfos 4.5.0.21 either: alarm only work in the first event and there is no alarm for the next events. Anyone with the same situation as me?
@carmenfdezb The fix provided by @dcaliste has been merged. Are you still impacted by this issue?
Yes, I’ve noticed that if I add a recurring event and I don’t set an end date, alarm only sound in the first event.
I came mark this as tracked but changes that changes that been make are have available only next bigger release.
But isn’t it fixed for sfos 4.5.0.24? I installed mkcal-qt5 when I was in sfos 4.5.0.21 from here: http://dcaliste.free.fr/SailfishOS/mkcal-qt5-0.6.12.1-1.aarch64.rpm. After, I’ve updated SailfishOS to last version (4.5.0.24) and I have currently mkcal-qt5-0.6.12.1-1.18.1.jolla.aarch64 installed. As I said, it’s not working for recurring events when I don’t set an end date.
I need to clarify myself as I realized that changes in mkcal upgrade-4.5.0 branch have indeed been already released in 4.5.0.21 meaning that something else has to be broken.
@carmenfdezb that 0.6.12.1 is exactly the right version. Whatever comes after last dot doesn’t count as that’s coming from build counter.
I cannot reproduce. Can you give a bit more description of your event / alarm setup ? What is the recurring period, when is it schedule to trigger, do you have exceptions…
From my side, I tested by setting up a daily event, triggering alarm at the moment of event, without exceptions and without ending date. The alarm rung at the moment of the first event and I checked with timedclient-qt5
that an alarm was reschedule for tomorrow.
Hi @dcaliste! Thank you for your answer. In my case was weekly event and I set the alarm 15 minutes before the event. This recurrent event is working now, I think since a set an ending date. I will try to reproduce again this bug, with a new recurrent event (daily event) and I will comment here if it’s working or not.
I have 4.5.0.24 on a 10 III. This problem was existing for me before this update and when the update came out, it started working again for maybe a week or two… and now I am back to no alarms. I have been watching this thread and noted that there doesn’t seem to be a firm solution even though it is marked as solved.
I have two calendar events, each bi-weekly. (blue bin goes out one week, black bin goes out the other) and the alarm is set for 5 mins before the event on Wednesday at 7pm. Doesn’t sound.
I have tried timedclient-qt5 as su and normal user and nothing shows. Also tried setting an end date on one of the events and that hasn’t solved it either. Nor has a reboot.
I have also tried destroying and re-creating the events. Come to think of it, this might have resulted in the “first alarm only” of a series sounding. I’ll try another destroy and re-create. But… this has resulted in me not relying on the phone for alarms any more.
I was testing this in the background (read: I forgot about it, up to the moment I remembered that an alarm was supposed to ring every two weeks…), and it occured to me also.
I don’t know how to reproduce though : / So for the moment, no good news on this problem. Still investigating.
The original bug reported in this thread was fixed to 4.5.0.21. It alleviated the problem but obviously did not fix it fully (see the latest comments of msknight and dcaliste).
I have closed the internal Jolla bug about this issue. Let’s also close this thread and write a new one having the details of the current issue on 4.6.0.