On Wed, 2012-07-11 at 18:24 +0200, Justus-bulk(a)Piater.name wrote: when a phone connects, a helper session is set up to parse the incoming SyncML message. That session gets aborted to start the real one with the identified server-side config. I bet that this is where the error message comes from. The "Rejected with error" was retrieved from stdout of libsynthesis and considered a potential problem because of the "error" keyword. SyncEvolution 1.2.99.x no longer shows it. As a first step, run the "--sync refresh-from-server" with "loglevel=4", to get the actual data dumped into the N9's syncevolution-log.html file. Look for a problematic event. Is it in the file? The "Generated" text/calendar is what gets passed to the N9's calendar backend (KCal). My guess is that the import fails, triggers a bug in the backend and/or storage. Not as far as I know. But why did you only update these libs and not the rest of SyncEvolution? Are you perhaps on Debian Wheezy, which now has the more recent libs but not yet SyncEvolution (currently triggers a compiler bug on MIPS and thus is prevented from entering Wheezy)? You could rule out this mismatch as the root cause by installing 1.2.99.2 from syncevolution.org. Deinstall the system's libsynthesis0, libsmltk0 and syncevolution packages if apt[itude] doesn't do it automatically. -- 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.

Thanks, Patrick, for your help. 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 https://iis.uibk.ac.at/public/piater/syncevo/client_+for_+laptop-2012-07-.... 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? The terminal output did not indicate any errors, but the event does not show on the N9 (neither before nor after the sync). My experience tells me that such is probably the case, caused by a bogus event somewhere, which I may not be able to get around hunting down the hard way. Precisely. I was hoping this version would enter sid one of these days, but maybe I should not hold my breath and install from source. Thanks, Justus

Patrick Ohly <patrick.ohly(a)intel.com&gt; wrote on Fri, 13 Jul 2012 14:00:40 +0200: So this means my disappearing-event problem is unrelated to this "error" message? I'm running Ove's latest version (1.2.2-1) from http://people.debian.org/~ovek/harmattan/, where both the .deb and the source tarball can be found. Let me know if I can be of further help. And thank you for your help :-) Justus

On Fri, 2012-07-13 at 18:59 +0200, Ove Kåven wrote: I still care, but I can't test it myself and thus rely on your help. That matches my theory. It should return ITEM_OKAY unless it does something special: /** * item added or updated as requested */ ITEM_OKAY, /** * When a backend is asked to add an item and recognizes * that the item matches an already existing item, it may * replace that item instead of creating a duplicate. In this * case it must return ITEM_REPLACED and set the luid/revision * of that updated item. * * This can happen when such an item was added concurrently to * the running sync or, more likely, was reported as new by * the backend and the engine failed to find the match because * it doesn't know about some special semantic, like iCalendar * 2.0 UID). * * Note that depending on the age of the items, the older data * will replace the more recent one when always using item * replacement. */ ITEM_REPLACED, /** * Same as ITEM_REPLACED, except that the backend did some * modifications to the data that was sent to it before * storing it, like merging it with the existing item. The * engine will treat the updated item as modified and send * back the update to the peer as soon as possible. In server * mode that will be in the same sync session, in a client in * the next session (client cannot send changes after having * received data from the server). */ ITEM_MERGED, /** * As before, a match against an existing item was detected. * By returning this state and the luid of the matched item * (revision not needed) the engine is instructed to do the * necessary data comparison and merging itself. Useful when a * backend can't do the necessary merging itself. */ ITEM_NEEDS_MERGE I need to check why ITEM_MERGED doesn't work. Either way, avoiding it should solve the problem. -- 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.

On Fri, 2012-07-13 at 21:39 +0200, Ove Kåven wrote: But these aren't changes which need to be sent back (which ITEM_MERGED is meant to request form the engine). The old "updated" boolean flag matches the new ITEM_REPLACED. It was meant to tell the engine that instead of adding a new item, an existing one was updated. But the semantic of that was too coarse (is the result different enough to be sent back?), thus the new enum. ITEM_OKAY if add or update worked as requested, ITEM_REPLACED if the engine asks for adding the item (luid empty) and the incoming item has a UID/RECURRENCE-ID property which matches an existing item, in which case the backend has to turn the "add" into an "update" to avoid UID/RECURRENCE-ID conflicts. -- 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.

On Sat, 2012-08-04 at 02:22 +0200, Ove Kåven wrote: How does the backend detect duplicates? I thought it didn't support UID +RECURRENCE-ID. Some heuristic? Use ITEM_REPLACED and return the ID of the existing item, regardless whether the item was stored or not. ITEM_MERGED would mark the existing item data for later transmission (well, if it worked on the client side...), which should not be necessary in this case because the add/update of that item should have been reported already earlier. -- 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.