OK, I will further test it later today.
1 Like
I did some further tests with non-recurring events and despite multiple attempts I couldn’t reproduce it this time. So, for now, I guess it is safe to assume that the issue was limited to recurring events only. Of course, if I ever encounter this problem with a non-recurring event, I’ll report it here right away.
Once again, thanks a lot for your help!
2 Likes
3 Likes
@dcaliste Is there some temporary fix possible until the actual fix comes with some future OS update?
Pull request was merged in master today. I’m on holidays this week without computer. I can compile a RPM for 4.5.0 with the fix next week though.
That will be really great, thank you. Have fantastic holidays!
You can find a compiled RPM for aarch64 phones. It is a compilation in SDK for 4.5.0 of the upgrade-4.5.0 branch in mkcal repository.
Notice that faulty recurring events (events created after the upgrade to 4.5.0, or events that triggered the alarm already) are not automatically corrected by the fix : / Instead, you have to touch them (modify anything in the event) to regenerate the alarm.
3 Likes
Installed, touched all affected recurring events, all alarms were correctly registered.
Thank you Damien!
When you find the time, would it be also possible for you to compile an armv7 build so that I could patch my XA2 Ultra as well? TIA!
1 Like
Here is the same code compiled for ARMv7hl target : http://dcaliste.free.fr/SailfishOS/mkcal-qt5-0.6.12.1-1.armv7hl.rpm
1 Like
Thank you!
P.S. It’s quite interesting that I am the only person who needs this. Don’t Sailfish OS users use recurring events with reminders?
I use it and it works fine. But most important recurring appointment is 10 am once in a week and reminder is at 7 am on the same day, so alarm time is always at the same day and never in previous month. Other calendar entries the same, with 5 min alarm before event also work fine. So my appointment and alarm times are always on the same day.
Please note that according to Damien the bug actually affects
so it is NOT limited to events whose reminders are in previous month. In my case, I quickly found out that also other recurring events in the middle of the month were affected, e.g. an event recurring monthly on 10th day of month with reminder one day before the event. I’m not sure if I correctly understand what Damien means as “strictly before the time of the event” but it probably affects your events, too. But it’ll only manifest itself after the event correctly occurs once, as only then its alarm won’t be re-registered and won’t appear the next time.
@wetab73 I referred to your question, also to the thread title and only wanted to report. I wish you good luck for solving your problem.
Well, I only wanted to let know that all recurring events are affected, so the thread title actually isn’t precise. Merely an information.
1 Like
I use recurring events a lot, @dcaliste thanks for the fix. Can I use this patch for Gemini PDA as well? The calendar is arranged a little differently there - landscape mode - than on the Xperia 10III.
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.