Hi
I know I may be alone in this but for various reasons I cannot add to the overall favorable reception of the new syncing engine. For a long time I have been running my own server using Seafile with no problems whatsoever but DTPO has always been an exception and kept throwing cryptic error messages at me. I tried to find a solution here on the forum and with the support but eventually it was decided to wait until the new sync was rolled out.
Is it possible to setup a Webdav server in the preferences and altering settings in case of difficulties? So far I find myself forced to start from scratch every time because the Webdav server seems to be database or rather syncstore specific and will only stick in case of a trouble-free connection. Sadly, this has never been the case and so I am rather proficient in typing in my server URL, username, password…
I don’t see what I am doing wrong here but this is really annoying.
Also, it would be really helpful if duplication of an existing Webdav connection was possible as a template for a connection to another database at the same location.
Establishing a syncstore from a small newly built database with nothing but a single RTF file in it was eventually possible, but existing databases have been throwing errors at me. Most frequently I am seeing “internal server error (500)”.
But also other, but equally unhelpful error messages, “invalid syncstore version”, “successfully verified” immediately followed by “verification failed”, “invalid encryption key” although I was creating a new syncstore rather than using an existing one.
No other software seems to have problems connecting to or writing to my server using a Webdav connection, neither locally nor over the internet.
Does anybody have a similar problem or better, even a solution?
Thanks
Prion
Sure, just click the Info button or use the contextual/action menu to open a popover to edit a sync location again. However, after changing the encryption key you should clean the location.
You don’t have to create a sync store for each database.
In case of an unreliable server I’d suggest to reduce the maximal number of connections.
I am aware of that but this only works if the connection is accepted so that it “sticks”. If it is refused for whatever reason the entire entry disappears without further notice.
.
Some of the databases are rather large (>1GB) and I would like to isolate problems I might have.
Good point. What might be an acceptable value then? I am not sure what might qualify the server as unreliable but it is not impossible that DTPO is stumbling across a problem that other software are ignoring. Can you suggest a test to get to the bottom of this presumption?
Did you use the WebDAV template by enabling the checkbox? Or did you use the contextual/action menu to add another WebDAV server? The WebDAV template can be edited again after a refused connection. The next version will also support this after using the menu.
I’d suggest the smallest possible value (2).
“Internal server errors (500)” are always issues of the server and can’t be ignored of course. I guess the server can’t handle the amount of traffic caused by the sync and the default value of up to 16 connections. E.g. Dropbox or to box.com locations don’t use more than 8 connections due to their unreliable servers.
I modified the existing one first but thereafter used the Plus sign at the bottom of the pane, which showed the behavior that I described. Since the two appeared identical there was no telling for me which one was which but one indeed remained stable/editable, whilst the other destroyed itself after an unsuccessful connection. Interestingly, deleting the last instance resurrected a stable template that I am now using. Removing this confusing distinction in future versions is a very good idea.
For anyone who is having similar problems: I was very close to giving up and settling on a different solution after extended but ultimately unsuccessful attempts to find a workable solution, by myself, here on the forum, with the support, you name it.
It seems that Christian hit the nail on its head with his diagnosis that the heart of the problem might be the amount of traffic DTPO is creating. Following his advice I did two things to decrease the data traffic: Reduce the number of connections to 8 and enable verification of uploaded items, which greatly increases the duration of the initial sync.
But thereafter…smooth sailing so far and I no longer have to tiptoe out of the room when a sync operation is imminent.
Simple cure but I am now for the first time in the position to evaluate the new DTPO and am carefully optimistic that the new sync may indeed be a breakthrough.
Thanks for restoring DTPO to working condition for me, maybe this helps someone else, too