On Fri, 2012-07-13 at 12:41 +0200, Justus-bulk(a)Piater.name wrote:
Thanks, Patrick, for your help.
> As a first step, run the "--sync refresh-from-server" with
> to get the actual data dumped into the N9's syncevolution-log.html file.
> Look for a problematic event. Is it in the file?
I have three calendards totaling many hundreds of events (for 2012
only), so I'm shying away from this for now... But I did something
simpler: I changed the description of an event with summary "Test" on
the laptop, and synced (two-way) with loglevel=4. The result is in
The log contains the following lines:
[2012-07-13 12:15:17.788] cannot update record in database (sta=207)
[2012-07-13 12:15:17.789] Database Error --> SyncML status 207
[2012-07-13 12:15:17.789] - Operation replace failed with SyncML status=207
Might this be related?
After looking further into this problem I'm no longer convinced that it
is the database which is at fault here. The 207 status is not really an
error, it tells the Synthesis engine that the item was merged fine with
an existing item.
The Synthesis engine running as client should be able to handle such a
status code, but apparently treats it as a failure instead.
But the main question is why you are getting this in the first place.
Which version of SyncEvolution are you running? Where is its source?
I changed the backend API in the 1.2.99.x releases, and it seems that
this (or attempts to adapt the code) broke the backend. In a nutshell,
KCalExtendedSource::insertItem() should return an InsertItemResult with
ITEM_OKAY if it was asked to replace an item and did so. Currently it
seems to return ITEM_MERGED.
I've probably let down Ove here by not updating the backend code while I
made the API change :-/
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.