On Di, 2012-01-24 at 21:27 +0100, Martin Ott wrote:
I'm trying to sync several CalDAV calendar to my phone and would
reuse the peer/accounts. If I use the general syncURL and use specific
databases, only the initial sync for the calendar is working. But when I
use the path to the database on the server as syncURL and leave the
database-param empty, initial and normal synchronization is working. Am
I missing something in my syncevolution config?
##configuration for default calenar
syncevolution --configure --template webdav
#explicitly configure addressbook source on CardDAV-Server
#explicitly configure calendar source on CalDAV-Server
syncevolution --configure --template SyncEvolution_Client
syncURL=local://@sogopersonal username= password= n900personal@default
#calendar initial sync works
syncevolution --sync slow n900personal calendar
That looks right.
When "database" is not set in the target-config, the "syncURL" is
to find a suitable collection. Once a sync completes, the chosen
collection URL is recorded in the "database" property, to avoid
accidentally picking a different collection the next time. So setting
the "database" manually should just provide a shortcut for the initial
At least that's the theory. Practice seems to disagree with theory, as
it is wont to do ;-}
#, but not normal sync after delete of event (path to ics file
syncevolution n900personal calendar
"DELETE /735.ics HTTP/1.1" 405 378 "-
#addressbook sync does not work
syncevolution --sync slow n900personal addressbook
[INFO @sogopersonal] @sogopersonal/addressbook: starting first time
[ERROR @sogopersonal] @sogopersonal/addressbook: error code from
SyncEvolution object not found (remote, status 404): GET: bad HTTP
status: <status 1.1, code 404, class 4, Not Found>
Can you send the output of "SYNCEVOLUTION_DEBUG=1 syncevolution
--daemon=no --sync slow loglevel=4 n900personal addressbook"?
I tried to reproduce the issue here, but it work fine for me.
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.