Bug 6576 - (int-152175) Alarm for a dropped occurrence of a recurring event
(int-152175)
: Alarm for a dropped occurrence of a recurring event
Status: RESOLVED FIXED
Product: Synchronization
PC Suite
: 5.0/(3.2010.02-8)
: All Linux
: Low normal with 4 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: maesync-bugs
:
:
: 5294
:
  Show dependency tree
 
Reported: 2009-12-04 10:15 UTC by Loek Engels
Modified: 2010-04-09 15:24 UTC (History)
5 users (show)

See Also:


Attachments
Part of my alarm_queue.ini with 7 occurences of same alarm (8.14 KB, text/plain)
2010-01-04 01:01 UTC, William Watte
Details
Workaround script removing double alarms. (5.10 KB, patch)
2010-01-10 16:35 UTC, William Watte
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Loek Engels (reporter) 2009-12-04 10:15:24 UTC
SOFTWARE VERSION:
(Settings > General > About product)
5.0/(1.2009.42-11)

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Create a recurring daily (weekdays) in Microsoft Outlook with an alarm set.
2. Sync with PC suite
3. Drop an occurrence of this event
4. Sync with PC suite
5. Repeat step 3-4 a couple of times 
6. Open the event on the N900, which displays (Complex repeat. Unable to edit)
7. On the days that the occurrence of the repeating event is dropped the alarm
still goes off.

EXPECTED OUTCOME:
No alarms for dropped occurrences of recurring events.

ACTUAL OUTCOME:
The alarm goes off for dropped occurrences of recurring events. Most likely for
recurring events that have become too complex to edit on the N900.

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
Always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.15)
Gecko/2009102814 Iceweasel/3.0.6 (Debian-3.0.6-3)
Comment 1 redex 2009-12-04 14:42:11 UTC
*** Bug 6579 has been marked as a duplicate of this bug. ***
Comment 2 redex 2009-12-04 16:03:09 UTC
(In reply to comment #1 by redex@ich.ms)
> *** Bug 6579 has been marked as a duplicate of this bug. ***

Please IGNORE this post. I've got the wrong Number and don't know how to edit.
I'm sorry.
Comment 3 Andre Klapper maemo.org 2009-12-08 18:00:06 UTC
I think that this depends on fixing bug 5294 first.
Comment 4 Loek Engels (reporter) 2009-12-11 10:18:32 UTC
Can you please check if the dependency on bug 5294 is really necessary. 
It is annoying to receive alarms for deleted instances of a recurring event
(e.g. instance deleted using Outlook). Note that the deleted instance of the
recurring event does not show up in the calendar on the N900, so why is there
still an alarm?
Comment 5 William Watte 2009-12-30 15:33:05 UTC
I think this is the same problem as bug 7213.
Please also have a look at bug 6687 which I think is also related (or maybe
even the root).
Comment 6 William Watte 2009-12-31 13:11:51 UTC
As I commented over there, this does not seem to be related to bug 6687 but in
my case, I had a combination of both, which made my phone to lock up every
hour.
As there is now a workaround for bug 6687, I have moved my vote here.

Please understand the severity of this problem.
I have many recurring meetings, which all get updated regularly (agenda,
meeting room, ... are changed by a secretary per occurrence). For every sync I
do, I seem to now have an alarm created.

So I'm not entirely sure if the problem is really in the Calendar part, rather
than in the Synchronization part (I'm not a developer, the smart people will be
able to find out).

However, I would like to make an urgent call to the developers, to provide at
least a quick workaround for this problem.
Simple solutions I can think of:
+ Provide information on where (Linux/Xterm-level) we can find the list of
Calendar alarms, so we can maybe edit/clean them manually.
+ If that's not possible, maybe there is a way of permanently killing all
Calendar alarms (maybe a service or daemon to be disabled)?

I really need this, otherwise I spend a minute each hour acknowledging the same
alarm over and over again.
Comment 7 Justin 2009-12-31 20:02:42 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Angelo 2010-01-01 00:50:55 UTC
*** Bug 7213 has been marked as a duplicate of this bug. ***
Comment 9 William Watte 2010-01-04 00:59:29 UTC
FYI, I'm not a developer, but this bug is for me annoying enough to continue
digging deeper than your average user.

I found out that the alarm-list is stored in /var/cache/alarmd/alarm_queue.ini
.
On my system, this file has already grown up to 440 kB (which I think is huge
for a simple text file), so I won't attach it completely.
I will add the last block of the file, where you can see no less than 7
occurrences of the same alarm.
That is, the hex-code and the "cookie" increments on each instance, but all the
rest is the same (and especially the alarm_time and trigger).

I don't have time anymore today, but maybe somebody (overnight for me) can
provide an answer to following questions:
+ Would manually editing this file (e.g. removing the double occurrences with
vi) make the system instable?
+ Would we need to restart a service for the changes to take effect?
+ And then finally, for the really motivated, can somebody please write an
intelligent script to clean-up the file? ;-)

I know this will only be a work-around, but as mentioned before, it's urgent to
find a solution, and this seems to me to be the fastest way around.
Comment 10 William Watte 2010-01-04 01:01:23 UTC
Created an attachment (id=1907) [details]
Part of my alarm_queue.ini with 7 occurences of same alarm

As explained in previous remark.
The full file is located in /var/cache/alarmd/
Comment 11 Andre Klapper maemo.org 2010-01-04 17:31:03 UTC
*** Bug 7442 has been marked as a duplicate of this bug. ***
Comment 12 William Watte 2010-01-10 16:34:01 UTC
Finally, I managed to get a workaround script working. I will attach it here.

Before using it, carefully read the comments and disclaimer at the start!

And especially: don't laugh at the way I solved a couple of things. I'm not a
programmer and have no real experience with scripting. Next to some basic Linux
knowledge, I visited a whole lot of internet resources to get this working.

So if you can improve it: be my guest, but please let me know.
Oh, and if somebody has the time and motivation to test this ON the phone (I
copy the ini file to my Mac, perform the script in an Xterm and then copy it
back to my phone), please do so.
Comment 13 William Watte 2010-01-10 16:35:33 UTC
Created an attachment (id=1952) [details]
Workaround script removing double alarms.

Carefully read all comments and disclaimers at the start of the script!
Comment 14 Andre Klapper maemo.org 2010-01-23 19:21:17 UTC
By the way, is the behaviour described here still the same problem in version
2.2009.51-1?
Comment 15 William Watte 2010-01-24 23:09:33 UTC
(In reply to comment #14)
> By the way, is the behaviour described here still the same problem in version
> 2.2009.51-1?
> 

Sorry, had a very busy week. Will test again next week.
Comment 16 William Watte 2010-02-02 22:55:47 UTC
Sorry guys, bug is still present in 2.2009.51-1.
I tried to change the Version on top but I don't have the rights to do this. A
real developer can maybe update? ;-)
Comment 17 Andre Klapper maemo.org 2010-04-09 15:24:17 UTC
Internal comment:

"Issue not reproducible in internal builds that will become the public PR1.2
release later, PC suite: 7.1.46.1. Changing the status to resolved FIXED."


This has been fixed in the next public update (PR1.2).

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/