Calendar alarms don't work for recurring events since SFOS 4.5.x.x [Solved]

Bug Reports
#1

REPRODUCIBILITY: 100%
OS VERSION: 4.5.0.19
HARDWARE: 10 III, XA2 Ultra
UI LANGUAGE: Polish
REGRESSION: Yes (compared to 4.4)

DESCRIPTION:

If calendar event has an alarm / reminder time set so that it is in previous month (e.g. the event is a full day event on April 1st and the reminder is scheduled for 1 hour prior to the event, i.e. March 31st at 23:00) there is no alarm/reminder whatsoever. Absolutely nothing happens.

[EDIT] As it turned out, this issue affects all recurring events, not just those with month transition. Please see the discussion below.

PRECONDITIONS:

None.

STEPS TO REPRODUCE:

  1. Set e.g. a full day event on the first day of month, e.g. April 1st.
  2. Set a reminder to go off an hour before the event, which means that it should go off on March 31st at 23:00.

EXPECTED RESULT:

The alarm/reminder should go off on March 31 at 23:00.

ACTUAL RESULT:

There is no reminder whatsoever. Nothing at all.

MODIFICATIONS:

None.

ADDITIONAL INFORMATION:

It is not limited to full day events only. Same thing applies to an event set for April 1 at 1:00 with a reminder set to go off two hours before the event, i.e. on March 31 at 23:00. It clearly applies to all events whose alarms are to go off on a previous month.

9 Likes
Sailfish Community News, 20th April, Sandboxing
Community meeting on IRC 12th October 2023
#2

Reported 5 days ago and not even tracked? I thought that reliable Calendar reminders are the LEAST one could expect, but clearly not even that.

1 Like
[Clock app] Scheduled alarms fail
#3

There are over 800 open bugs report. I invite you to join our efforts to clean up this mess if you’d like to see a fast bug triage.

#4

Actually, I only expected to see merely a confirmation that it was noticed. That because there are many bug reports which haven’t been touched for years, and - IMO - broken Calendar reminders are an issue serious enough not to miss. As opposed to many bugs of much lower importance.

Also, please, do not refer to me as to a person who just demands something. I think I do my part, too. Even just (properly) reporting a bug often involves work and time, as I never report anything without thoroughly testing it first, and then also actively supporting the process of fixing it (see e.g. my involvement in fixing the ofono bug with rejected calls coming back, or MMS issues, or ambience sounds bug, and more) - hours of tests, videos illustrating the problem, multiple logs provided, etc. I also contribute to this ecosystem in other ways, e.g. recently I spent days on reviewing the entire Polish localization and providing hundreds of corrections and suggestions, most of which were accepted and already included in the OS. So there are multiple ways one supports this platform, not just the way you do it.

#5

Don’t get hot. I’ve seen your thread and bookmark it for further investigation. Sadly time is running for everyone and I can’t stop what I’m doing for a bug report as interesting as it can be like this one. I guess it’s the same for other people too.

So thanks for the report and the interedting finding. I’ll enjoy investigate it if no one do it before I do. But it may take tiiiiime :wink:

2 Likes
#6

Thank you!
(20 characters)

1 Like
#7

Looking quickly at it, and trying to reproduce, I did the following:

  • setup an event on May, 1st at 1.00 am, put an alarm 2 hours before,
  • check with timedclient-qt5 -L that my test event has registered an alarm,
  • go to the date/time settings and uncheck the automatic time, to trick the device to April, 30th at 10.58 pm,
  • wait for two minutes, then the alarm showed on screen with sound,
  • go back to settings and check again the automatic time, which bring me back to present time,
  • check with timedclient-qt5 -L if the event that is now in the future, still has an alarm : result is no (the alarm rung and nothing re-registered it again). Modifying any event in the calendar make the alarms to be reset, and it is listed again.

Can you check that you can reproduce it ? If so, what is your setup (I mean, timezone of the event, timezone of the device, recurring event or not, event created on device or synced from a given account…) ?

1 Like
#8

Thank you for looking into this!

Well, before reporting it as a bug, I did several tests and it was 100% reproducible. And while all alarms which were set to go off in the same month as the event worked fine, alarms that were in the previous month didn’t have any effect.

The first time that I noticed this problem was due to no alarm from a recurring monthly event that I’ve had configured for more than a year, and which always worked fine until this occurence (i.e. the first after the series of 4.5.x.x updates). Then I tested it by creating several new events, and - as mentioned - while alarms which were to go off in the same month always worked, those to go off in a previous month never did.

Timezone of all the events was the same as timezone of the device (manually set to Warsaw/Poland, automatic timezone update not enabled), I checked it with both a recurring and a one-time event, both full-day and normal (i.e. lasting an hour or two), events created on the device only and not synced from/with anything (I only use my Calendar locally).

I will thoroughly test it once again tonight on both the 10 III and XA2 Ultra, and I’ll report it here.

1 Like
#9

Seems reproducible for ‘full day events’ as in OP, set for 1st april 1h reminder, disable auto, set date to 31st march 22:59, nothing goes off

1 Like
#10

Thanks for reproducing it. I guess this confirms that it is not my unique problem…

Anyway, I’ve taken a closer look at timedclient-qt5 -L output and it turns out that something must be very wrong with registering alarms. A newly created event was not listed at all (which - obviously - resulted in no alarm), and only re-editing it twice caused that it was finally listed in timedclient-qt5 -L output, and only then the alarm went off as it should.

It’s even worse with all my long-time existing recurring events (which all did work just fine until the last month). It looks that alarms of most of those monthly ones weren’t re-registered after the last occurence, as most of them are not listed by timedclient-qt5 -L. Editing them still doesn’t make them listed, and even deleting such an event and creating it from scratch still didn’t make it listed.

@dcaliste, can you please re-do your test but with a recurring full-day event on May 1st? Please check if you can make it at all listed by timedclient-qt5…

#11

Ok, thanks @wetab73 for your investigations. They helped me to find the issue. It’s impacting all recurring events with alarms strictly before the time of the event.

The issue has been introduced in 4.5.0 series by myself. In 4.4.0 and previous versions, there was an issue with alarms and exceptions for recurring events (alarm was ringing for deleted occurrences for instance). I fixed it by changing the code for setting alarms for recurring events and created a dedicated test for such cases in the automatic tests for mKCal. This test is quite extensive in term of situations:

  • testing simple recurring event,
  • testing a start time modification on the next occurrence,
  • testing to delete the next occurrence,
  • testing cancelling the next occurence,
  • testing adding an exception for an occurrence strictly later than the next occurrence.

Well, I thought, I covered most of the cases. Except that I made a mistake in the alarm defintion in the test : it is fired at the time of event, and not strictly before. And when setup up for a time strictly before : the test is failing, highlighting the bug.

The fix is trivial. I’ll submit a merge request soon and will discuss with @pvuorela for what can be done about it.

4 Likes
#12

PR submitted : [mkcal] Fix alarm setting for recurring events. by dcaliste · Pull Request #57 · sailfishos/mkcal · GitHub

4 Likes
#13

Wow! Thank you very much! I’m glad that I could help with finding the issue and that it was easy to fix. It looks that my impatience wasn’t that bad afterall :slight_smile: Thank you Damien for fixing yet another very important thing. I marked your post as Solution.

#14

Yeh, but a bit sad that it was a major regression I introduced : /

1 Like
#15

Like they say: “The only people who don’t make any mistakes are those who don’t do anything”. Or something like that :wink: Thank you for all your hard work!

1 Like
#16

Oh, one more thing: you said that

Does it mean that non-recurring events are not affected? Because I had problems with a non-recurring event, too. It took several attempts to make it register an alarm.

Should I further test it?

#17

Yes, the above fix is only for recurring events (irrespective of all day or not, or month transition or not) as soon as the reminder is set strictly before the time of event.

Non recurring events (or recurring events with a reminder on time of events) are not impacted. If you can reproduce an issue in that case, I’ll check it.

#18

OK, I will further test it later today.

1 Like
#19

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
#20

Hey @wetab73 and @dcaliste, I just love what you do in this thread. Thank you for your efforts!

3 Likes