recurring alarms disappear from indicator (but not clock-app) after first kick

Bug #1424924 reported by Charles Kerr
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
indicator-datetime (Ubuntu)
Invalid
Undecided
Charles Kerr
qtorganizer5-eds (Ubuntu)
Fix Released
Undecided
Renato Araujo Oliveira Filho
ubuntu-clock-app (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I'm not sure yet what's causing this, but the symptom is for ~/.local/share/evolution/tasks/${foo}@ubuntu-phablet/tasks.ics to have entries whose rrule looks like this:

> RRULE;X-EVOLUTION-ENDDATE=19700101T000000Z:FREQ=WEEKLY;COUNT=32639;
> BYDAY=MO,TU,WE,TH,FR
> SUMMARY:Weekday wakeup

When is should look more like this:

> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR

Alarms appear / trigger again after manually editing tasks.ics to remove the invalid X-EVOLUTION-ENDDATE and COUNT values, then restarting evolution-calendar-factory and indicator-datetime.

ENDDATE's clearly coming from a (time_t)0. Not sure about 32639, but it's INT16_MAX - 128, so we've got that.

Edit: this doesn't appear to be the full story -- if I create a brand new recurring alarm it works correctly even though the epoch ENDDDATE is present. For me they disappeared later, after a few days had passed and the system had been rebooted dozens of times. I'll see if I can reproduce the bug and, if so, how to reproduce it.

Related branches

Charles Kerr (charlesk)
Changed in qtorganizer5-eds (Ubuntu):
assignee: nobody → Renato Araujo Oliveira Filho (renatofilho)
Revision history for this message
Charles Kerr (charlesk) wrote :

"X-EVOLUTION-ENDDATE" is set only in one place, evolution-data-server/calendar/libecal/e-cal-recur.c's function , e_cal_recur_set_rule_end_date(), which is only called in this block:

> /* Calculate the end date. Note that we initialize end_date to 0, so
> * if the RULE doesn't generate COUNT instances we save a time_t of 0.
> * Also note that we use the UTC timezone as the default timezone.
> * In get_end_date () if the DTSTART is a DATE or floating time, we will
> * convert the ENDDATE to the current timezone. */
> cb_data.count = rule.count;
> cb_data.instances = 0;
> cb_data.end_date = 0;
> e_cal_recur_generate_instances_of_rule (
> comp, prop, -1, -1,
> e_cal_recur_ensure_rule_end_date_cb,
> &cb_data, tz_cb, tz_cb_data,
> icaltimezone_get_utc_timezone ());
>
> /* Store the end date in the "X-EVOLUTION-ENDDATE" parameter of the
> * rule. */
> e_cal_recur_set_rule_end_date (prop, cb_data.end_date);

It looks like somehow e_cal_recur_generate_instances_of_rule() here generated no instances so that end_date became the epoch.

Changed in indicator-datetime (Ubuntu):
assignee: nobody → Charles Kerr (charlesk)
Charles Kerr (charlesk)
description: updated
Charles Kerr (charlesk)
summary: - clock-app alarms' RRULE have unusual X-EVOLUTION-ENDDATE, causing alarms
- to not sound
+ recurring alarms disappear from indicator (but not clock-app) after
+ first kick
Revision history for this message
Charles Kerr (charlesk) wrote :

This repeated for me again overnight in vivid r109 on mako.

1. create recurring mon-fri wakeup alarm
2. wait a day for alarm to kick
3. after alarm kicks, it disappears from indicator (bug)
4. open clock-app, alarm still appears there (???)
5. reboot phone to see if it's an error with indicator's state
6. same results as 3-4

Charles Kerr (charlesk)
Changed in qtorganizer5-eds (Ubuntu):
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtorganizer5-eds - 0.1.1+15.04.20150227-0ubuntu1

---------------
qtorganizer5-eds (0.1.1+15.04.20150227-0ubuntu1) vivid; urgency=medium

  [ Renato Araujo Oliveira Filho ]
  * Use '0' as value for recurrence count if this is unset. (LP:
    #1424924)
 -- CI Train Bot <email address hidden> Fri, 27 Feb 2015 19:51:10 +0000

Changed in qtorganizer5-eds (Ubuntu):
status: In Progress → Fix Released
Charles Kerr (charlesk)
Changed in indicator-datetime (Ubuntu):
status: New → Invalid
Changed in ubuntu-clock-app (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.