[sync] Nokia Kronolith SyncML problem

Wed Dec 16 21:22:05 UTC 2015

On 08.12.2015, at 18:49, Jan Schneider wrote:

> Zitat von Daniel Schaller <temp2 at ichbinweg.ch>:
> 
>> On 30.11.2015, at 18:13, Jan Schneider wrote:
>> 
>>> Zitat von Daniel Schaller <temp2 at ichbinweg.ch>:
>>> 
>>>> Hello,
>>>> 
>>>> I tried hard but don't get an old N97 Nokia phone properly synced with Kronolith through SyncML. My installation is very recent (5.2.11 groupware). There are no issues on the protocol level, the sync succeeds with no errors it's just that not all entries from the phone are in Kronolith afterwards. From the logs I get the following:
>>>> 
>>>> DEBUG: HORDE Handling <Add> sent from client
>>>> DEBUG: HORDE [kronolith] SQL INSERT INTO kronolith_events
>>>> 
>>>> These two lines occur repeatedly, actually as many times as there are calendar entries on the phone. But at one point I see the following:
>>>> 
>>>> DEBUG: HORDE Handling <Add> sent from client
>>>> DEBUG: HORDE [kronolith] SQL DELETE FROM kronolith_events
>>>> DEBUG: HORDE [kronolith] SQL DELETE FROM kronolith_events
>>>> DEBUG: HORDE [kronolith] SQL DELETE FROM kronolith_events
>>>> DEBUG: HORDE [kronolith] SQL DELETE FROM kronolith_events
>>>> .....
>>>> DEBUG: HORDE [kronolith] SQL INSERT INTO kronolith_events
>>>> 
>>>> As an <Add> request from SyncML is processed many previously added events are deleted before the one to be added is put into the database. Anyone any hint on what causes this behavior? To sum up, all events to be synced get into the kronolith_events database but some of them are removed right away during the sync process.
>>>> 
>>>> Any help is most welcome.
>>>> 
>>>> Daniel
>>>> --
>>>> sync mailing list
>>>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>>>> To unsubscribe, mail: sync-unsubscribe at lists.horde.org
>>> 
>>> No idea where those DELETES are coming from, but the only place where this happens is in Kronolith_Driver_Sql::_deleteEvent(), so you might want to start the debugging there, so see where the call originates.
>>> 
>> Hi,
>> 
>> So, I did some digging and traced the DELETEs to be coming from function _process in kronolith/lib/Icalendar/Handler/Base.php (call to function $this->_driver->deleteEvent). It must have to do with recurring events (which I have plenty to sync). Any ideas? Thanks for any support.
> 
> What happens there is that exceptions from events are deleted first, when importing the base event. The exceptions are later added back. This means probably two things in your case:
> 1) All the events that disappear are actually exceptions from recurring events.
> 2) The event exceptions are not provided with the base exception as per the iCalendar standard.
> 
> If you enable SyncML logging, the actual data sent from the client will be logged and you can verify that this is what happens.

I do not have repeating events with exceptions to be synced so none of the two above apply. But I found the following: A yearly repeating event created with Apple iCal (Test iCal below), synced to the phone and then on to Horde does do ok. But a yearly repeating event created on the phone itself (Test N97 below) and then synced on to Horde deletes all events in the database before being added. I noticed that the UID field gets stripped on the conversion for the server. Could this be the reason? Why does the stripping happen?

Input received from client (text/x-vcalendar):
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01
DAYLIGHT:TRUE;+02;20150329T010000Z;20151025T010000Z;;
DAYLIGHT:TRUE;+02;20160327T010000Z;20161030T010000Z;;
DAYLIGHT:TRUE;+02;20170326T010000Z;20171029T010000Z;;
DAYLIGHT:TRUE;+02;20180325T010000Z;20181028T010000Z;;
DAYLIGHT:TRUE;+02;20190331T010000Z;20191027T010000Z;;
BEGIN:VEVENT
UID;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:16122015205501734750=C9=BC
SUMMARY:Test iCal
DTSTART:20151217T210000Z
DTEND:20151217T220000Z
X-EPOCAGENDAENTRYTYPE:APPOINTMENT
CLASS:PUBLIC
SEQUENCE:0
X-METHOD:NONE
RRULE:YM1 12 #0
LAST-MODIFIED:20151216T205501Z
PRIORITY:0
X-SYMBIAN-LUID:1475
END:VEVENT
END:VCALENDAR

Input converted for server (text/x-vcalendar):
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01
DAYLIGHT:TRUE;+02;20150329T010000Z;20151025T010000Z;;
DAYLIGHT:TRUE;+02;20160327T010000Z;20161030T010000Z;;
DAYLIGHT:TRUE;+02;20170326T010000Z;20171029T010000Z;;
DAYLIGHT:TRUE;+02;20180325T010000Z;20181028T010000Z;;
DAYLIGHT:TRUE;+02;20190331T010000Z;20191027T010000Z;;
BEGIN:VEVENT
UID;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:16122015205501734750=C9=BC
SUMMARY:Test iCal
DTSTART:20151217T210000Z
DTEND:20151217T220000Z
X-EPOCAGENDAENTRYTYPE:APPOINTMENT
CLASS:PUBLIC
SEQUENCE:0
X-METHOD:NONE
RRULE:YM1 12 #0
LAST-MODIFIED:20151216T205501Z
PRIORITY:0
X-SYMBIAN-LUID:1475
END:VEVENT
END:VCALENDAR

Input received from client (text/x-vcalendar):
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01
DAYLIGHT:TRUE;+02;20150329T010000Z;20151025T010000Z;;
DAYLIGHT:TRUE;+02;20160327T010000Z;20161030T010000Z;;
DAYLIGHT:TRUE;+02;20170326T010000Z;20171029T010000Z;;
DAYLIGHT:TRUE;+02;20180325T010000Z;20181028T010000Z;;
DAYLIGHT:TRUE;+02;20190331T010000Z;20191027T010000Z;;
BEGIN:VEVENT
UID:c4BfCA4s4F8Lf68DV7Gj80
SUMMARY:Test N97
DTSTART:20151217T210000Z
DTEND:20151217T220000Z
X-EPOCAGENDAENTRYTYPE:APPOINTMENT
CLASS:PUBLIC
SEQUENCE:0
X-METHOD:NONE
RRULE:YM1 12 #0
LAST-MODIFIED:20151216T205743Z
PRIORITY:2
X-SYMBIAN-LUID:1476
END:VEVENT
END:VCALENDAR

Input converted for server (text/x-vcalendar):
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01
DAYLIGHT:TRUE;+02;20150329T010000Z;20151025T010000Z;;
DAYLIGHT:TRUE;+02;20160327T010000Z;20161030T010000Z;;
DAYLIGHT:TRUE;+02;20170326T010000Z;20171029T010000Z;;
DAYLIGHT:TRUE;+02;20180325T010000Z;20181028T010000Z;;
DAYLIGHT:TRUE;+02;20190331T010000Z;20191027T010000Z;;
BEGIN:VEVENT
SUMMARY:Test N97
DTSTART:20151217T210000Z
DTEND:20151217T220000Z
X-EPOCAGENDAENTRYTYPE:APPOINTMENT
CLASS:PUBLIC
SEQUENCE:0
X-METHOD:NONE
RRULE:YM1 12 #0
LAST-MODIFIED:20151216T205743Z
PRIORITY:2
X-SYMBIAN-LUID:1476
END:VEVENT
END:VCALENDAR