On Thu, 2011-11-03 at 13:28 +0100, Frederik Elwert wrote: > >On Wed, 2011-11-02 at 15:00 +0100, Frederik Elwert wrote: > >> >On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote: > >Can you try again with "refresh-from-server" for "calendar+todo"? > > I tried again with calendar+todo. > > A subsequent normal sync again did a slow sync.
That shouldn't have happened. The refresh-from-server sync completed without errors, at least as far as the server can tell. But then in the next sync, the N9 sends the old, obsolete anchor as if the refresh-from-server sync had failed. I tried with a Noki N97, which worked fine. As far as I can tell, the N9 Bluetooth SyncML is not working properly when it comes to calendar data. Another reason not to use it is the limitation to vCalendar 1.0. That will be problematic in combination with different time zones and detached recurrences. A better solution is probably to set up SyncEvolution as HTTP SyncML server and use SyncEvolution also on the N9. > I restored, and in a second attempt, I tried an explicit --sync > two-way calendar+todo. That worked for the calendar (two-way, no > conflicts/ERRs), but not for the todo (slow sync, all 15 items in > conflict). After that, a normal sync (no explict sources given, i.e. > all configured sources synced) worked fine. There are still "NON-OK STATUS 500" errors in that last log file. > >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. > > No, the calendar source is disabled, and has no uri. Only calendar > +todo and addressbook is configured. As I thought, "calendar" is used as fallback for the "calendar" source and that happens to be accepted by the N9. One way to avoid this pitfall is to set an invalid URI for the calendar and todo sources. The resulting error is not particularly obvious, but it is better than doing a real sync: [INFO] Server sending SAN [ERROR] OBEX Request 3 got a failed response Forbidden [INFO] Server sending SAN [ERROR] OBEX Request 2 got a failed response Forbidden [ERROR] ObexTransprotAgent: Underlying transport error ... Changes applied during synchronization: +---------------|-----------------------|-----------------------|-CON-+ | | LOCAL | REMOTE | FLI | | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | start Thu Nov 3 14:51:39 2011, duration 0:06min | | external transport failure (local, status 20043) | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ First ERROR encountered: OBEX Request 3 got a failed response Forbidden I'll add that to the Nokia device templates. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
