Re: [SyncEvolution] N9 Bluetooth sync incomplete, 500 status for Delete (was: Re: syncevo-dbus-server dies - SIGPIPE)

On Wed, 2011-11-02 at 15:00 +0100, Frederik Elwert wrote: > >On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote: > >> There is just one issue that I could not yet identify: There is always > >> a number of calendar entries in ERR state, which get re-submitted with > >> the next sync, and then again be rejected. On the N9, at a first > >> glance no recent entries seem to be missing, so I did not do too much > >> to triage this issue. On the other hand, this probably makes each sync > >> use more time than necessary. Any ideas where these errors might sttem > >> from? I’ll send you a loglevel=4 log in private, maybe you can make > >> more sense of it than I can. > > > >The failures are all for item delete requests. The N9 returns a very > >uninformative 500, which is usually about an internal error. Because the > >Synthesis engine doesn't know what to do about that, it keeps trying. > > > >Can you do a refresh sync? I assume your desktop has all your events, so > >do a '--sync refresh-from-server' on the desktop (which is the server in > >this case). > > I did a refresh-from-server for the calendar, and then a normal sync > (no sync mode given). During that normal sync, syncevolution also did > a slow sync for the calendar (while doing a two-way sync for the > address book), which lead to various conflicts. The slow sync was caused by doing the refresh-from-server with the "calendar" source, while during a normal sync "calendar+todo" is used. The Synthesis engine cannot reuse the anchors from one real source ("calendar") in a sync with a virtual source ("calendar+todo"). Can you try again with "refresh-from-server" for "calendar+todo"?

I wonder why that worked. Has the "calendar" source any URI configured? It could be that it used the "calendar" source name as fallback. That wasn't the intention when adding that fallback; the goal was to simplify SyncEvolution<->SyncEvolution syncs.