Closed Bug 356382 Opened 18 years ago Closed 17 years ago

Import from Palm Pilot (jpilot export)

Categories

(Calendar :: Import and Export, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 187177

People

(Reporter: mjanich, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061004 Fedora/1.5.0.7-6.fc6 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061004 Fedora/1.5.0.7-6.fc6 Firefox/1.5.0.7

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
Whiteboard: [qa discussion needed]
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.

Keywords: qawanted
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:1.8.1.2pre) 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
Closed: 17 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.