On Wed, 2013-04-03 at 03:02 +0200, Christof Schulze wrote: It probably sents the first message, then waits for the server responds. It times out because the server response depends on reading all WebDAV data first. I'm afraid there is no easy solution. As a stop-gap measure you could set up a two-step synchronization: - sync WebDAV with a local directory - sync the phone with the local directory The syncing between WebDAV and local directory will not time out, no matter how slow WebDAV is. The syncing between phone and local directory might still time out, but because reading files should be faster, hopefully that is less likely. I assume you have configured the "calendar" source in your @default context to use CalDAV. Replicate that same source in a @dav context: syncevolution --configure \ --template WebDAV \ username=... \ password=... \ database=<URL of CalDAV calendar> \ target-config@dav calendar Change the @default calendar to use a directory: syncevolution --configure \ backend=file \ database=file:///<path to empty directory> \ databaseFormat=text/calendar \ @default calendar Set up syncing between the two: syncevolution --configure \ syncURL=local://@dav \ peerIsClient=1 \ uri=calendar \ davlocal@default calendar Note that I am leaving dumpData and printChanges enabled in that "davlocal" sync config. This will allow you to watch out for unexpected data changes, something that you had to disable for performance reasons when syncing directly with the phone. Now populate the local dir with data from WebDAV: syncevolution davlocal When you sync with your phone now, it'll use the data from the directory. Run "syncevolution davlocal" again to get changes imported from the phone into WebDAV. You could use time-based auto syncing for that step (autoSync=1). Auto syncing based on monitoring for changes has been a long standing feature idea, but no-one had time to work on that. Alternatively (or in addition), SyncEvolution should be changed to run syncing multithreaded. As Lukas explained, in that mode the main sync thread would send regular pongs to the phone while the preparation of the data source still runs. -- 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.