User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061004 Fedora/220.127.116.11-6.fc6 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20061004 Fedora/126.96.36.199-6.fc6 Firefox/188.8.131.52 I exported my palm database with jpilot-0.99.8-7.1 from FC6-test3 into one iCal file and imported that into sunbird-0.3 (needed to install "compat-libstdc++-33" first). The import took about 30 minutes (3GHz proc, 1GB RAM) for 2384 entries of a 700kb file. The CPU load was 100% during that time. Every entry spits out a "alarm in the past and not acknowledged, firing NOW", about one entry per second. At the end I get ONE long request box with all the missed appointments. This is EXCELLENT. Good work! But now I get one beep for each missed appointment (takes about another 15 minutes, need to switch off speaker, too anoying), then the request box goes away. At the end I get: :flushItem DB error: unable to open database file Don't know where that comes from. So what I recommend: * Importing must be done with 100 entries per second, not with one per sec. How long can it take to parse ONE ENTRY? * Only one beep, even for 1000 missed appointments. * not sure what the "flushItem DB error" is - why don't you have a look. Reproducible: Always Steps to Reproduce: 1. see in details 2. 3. Fedora Core 6-test3 kernel 2.6.18 AMD 3000+ 1GB RAM
Reporter, Can you attach a scrubbed subset of the iCALENDAR file that you attempted to import? This will help us track down these three issues easier. Marking as QAWanted, contingent on getting that file.
Whiteboard: [qa discussion needed]
I got only one beep for multiple missed alarms with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20070209 Calendar/0.4a1. Somebody else should re-check this. The code in http://lxr.mozilla.org/seamonkey/source/calendar/base/content/calendar-alarm-dialog.js#37 suggests it is played for every alarm added to the alarm window.
We know that importing events is slow. One reason for the incredible slowness you saw is that it appears you're running in debug. We are working on the performance problem in bug 187177. I tested this using a 284Kb ICS file with 745 events in it and several missed alarms. I only got one alarm beep for all the missed alarms, so I believe that issue is WFM. Martin, I think we should follow up with jminta or lilmatt about that code segment. It seems that there are several ways we might be adding an alarm: http://lxr.mozilla.org/mozilla1.8/search?string=addAlarm I added jminta to the CC list of this bug. I tested this with the latest Sunbird nightly and a current version of Lightning (in debug). Here are my times: Sunbird, Month View -> 3 minutes from import to populated view -> 1 beep for all alarms Sunbird, Week View -> 3 min 15s from import to populated view -> 1 beep for all alarms Lightning (Debug, Month View) -> 6 or 7 min from import to populated view (I got tired of timing it and stepped away) -> 1 beep for all alarms So, I think the "multiple beep" problem is WFM. I think the "takes a long time to import" problem is a duplicate of the issue reported in bug 187177. So, I am going to mark this as a duplicate of 187177. Reporter, if you can ever get us a copy of that ICS file you used for import, that would help us resolve the performance issues (and the multiple beep issues, if those are somehow caused by the ICS).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 187177
You need to log in before you can comment on or make changes to this bug.