[kronolith] How to debug the import of ics calendars?

[Sebastian Arcus]

On 01/04/12 21:50, Sebastian Arcus wrote:
> I have Kronolith 3.0.16 installed and working fine with SQL backend. I
> am trying to import a large (over 4000 appointments) iCal/ics file which
> was exported from Thunderbird/Lightning. The import fails silently. When
> I query the SQL back-end - I can see that 157 appointments have been
> imported - no matter how many times I repeat the process. I need to find
> out a bit more about what is going on, so that I can amend the .ics file
> and fix whatever is stopping the import.
>
> I've enabled logging in Horde -> Logging, set the priority to "Debug"
> and type to "File". However, there doesn't seem to be anything in the
> resulting log relating to the import. Maybe the import module doesn't
> log to the main log? Any other way that I can extract some useful
> information as to what is going on?

OK - I'm replying to my own post in case it helps somebody out there. 
After re-reading carefully the PostgreSQL documentation (that's what I 
use in the back end) I reconfigured again logging and I started to see 
some useful messages. They were mainly similar to:

ERROR:  character 0xe2809a of encoding "UTF8" has no equivalent in "LATIN1"

On further investigation it turns out that the database (and database 
cluster) has been created with the Latin1 encoding. I followed the 
instructions below (which apply only to Postgresql):

http://archives.postgresql.org/pgsql-novice/2006-03/msg00210.php

to dump the database contents to a file, drop the database (I also 
deleted the database cluster actually), recreate the database cluster 
with UTF-8 encoding this time, recreate the database, and import back 
all the data.

After this I could import 2002 events - but it would still stop. After 
looking at error logs some more, it turns out that Thunderbird is a bit 
more generous than Turba with the size of event_title field - and some 
of them were overrunning the 255 max size. I went in the back end and 
amended the even_title (and alarm_title) field size both in 
"kronolith_events" and in "horde_alarms" - and lo and behold - all the 
4819 events have been imported!

Some errors about character set persisted in the error log - until I 
discovered that the connection used by the psql command line client was 
still using the Latin1 encoding for the session - which can be corrected 
(temporarily) with "SET character_encoding = 'UTF8';" once connected to 
PostgreSQL.

I still think that the lack of feedback from the iCal/.ics import 
process in the Kronolith interface is a major drawback and would make it 
impossible for any user without direct access to the SQL backend to 
troubleshoot the import process. I'm off to the bugtrack to file it as a 
feature request - maybe it will be considered at some point in time by 
the developers.