@slowcyclist
err, no, my test reconnects to the server.
However there is something of a strange behaviour that I don't understand currently.
When asking for a sync even in test mode from the command line:
syncevolution --print-databases backend=caldav username=<user> password=<pwd> syncURL=http://192.168.20.12:5232
[INFO] start database search at http://192.168.20.12:5232, from sync config '@default', syncURL='http://192.168.20.12:5232'
I often see a block, the connection is not established (nor refused). After some time (a few minutes ?) the reply is sent. I see the log of the server at the same time, it does not receive anything, it's syncevolution that is refusing to send.
When looking at the same behaviour from the phone UI point of view, when clicking on the sync button, it turns in display busy and after some time the server is receiving data and the sync button turns in mode inactive (but with an red error indicator).
Even trying syncevolution --help blocks.
It's as if syncevolution was refusing to work at some moments.
Looking a bit more, it's as if it's the phone UI connection that is blocking itself (and all other operations such as syncevolution --help or the manual sync that I posted above; when the UI phone attempt at connection finishes, I can then do sync tests from the command line without limitation.
It's as if the sync initiated from the phone UI was blocking syncevolution for about 5 minutes, then it deblocks itself (and other syncevolution clients on the phone such as my test sync) , synchronize the events successfully but returns an error.
A bit of testing seems to show that the delay is about 5-6 minutes. Maybe it's actually that syncevolution is setup to sync every 10 minutes and the button has no effect other than to block until the automatic sync does its thing.
If what you see looks like what I see, that would be a pattern and maybe an issue could be created on Gitlab.
