maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Alarm for a dropped occurrence of a recurring event|
|Product:||[Maemo Official Platform] Synchronization||Reporter:||Loek Engels <loek.engels>|
|Component:||PC Suite||Assignee:||unassigned <nobody>|
|Status:||RESOLVED FIXED||QA Contact:||maesync-bugs|
|Priority:||Low||CC:||alex, andre_klapper, angelo.vals, redex, william.watte|
|Bug Depends on:||5294|
Part of my alarm_queue.ini with 7 occurences of same alarm
Workaround script removing double alarms.
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:22.214.171.124) Gecko/2009102814 Iceweasel/3.0.6 (Debian-3.0.6-3)
*** Bug 6579 has been marked as a duplicate of this bug. ***
(In reply to comment #1 by email@example.com) > *** 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.
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?
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.
*** This bug has been confirmed by popular vote. ***
*** Bug 7213 has been marked as a duplicate of this bug. ***
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.
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/
*** Bug 7442 has been marked as a duplicate of this bug. ***
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.
Created an attachment (id=1952) [details] Workaround script removing double alarms. Carefully read all comments and disclaimers at the start of the script!
By the way, is the behaviour described here still the same problem in version 2.2009.51-1?
(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.
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? ;-)
Internal comment: "Issue not reproducible in internal builds that will become the public PR1.2 release later, PC suite: 126.96.36.199. 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/