[sync] Nokia Kronolith SyncML problem

Jan Schneider jan at horde.org
Thu Dec 17 09:14:33 UTC 2015 

Zitat von Daniel Schaller <temp2 at ichbinweg.ch>:

> 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?

This is for historical reasons, and because of the way how importing  
works via SyncML. Obviously this still shouldn't delete other events,  
so please create a ticket.

> 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
> --
> sync mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: sync-unsubscribe at lists.horde.org



-- 
Jan Schneider
The Horde Project
http://www.horde.org/

More information about the sync mailing list