Sync problems still happening in DT3

DEVONthink
#1

With DT2, I would sometimes get a sync issue where sync (via Dropbox) would stop working. Each of my two Macs would report that it was synced, but files added on one would not appear on the other. Nothing showed in the log and there seemed to be no way of kicking them back into action. In the end I would have to pick one database, move all its contents into a new DB and restart the whole thing.

This has just happened again with DT3. It’s a massive issue for me, because I rely heavily on what – when it doesn’t suddenly completely stop working like this – is indeed reliable. By the time it suddenly stops (somehow managing to pick the worst time) the database is very large and so restarting the whole exercise wastes a huge amount of time.

Before I do it again this time, can I do anything to help you fix this bug (without sending you details of the contents of the DB, which are legally privileged …)?

#2

Are you able to successfully verify the sync store in case of such issues (see contextual menu in Preferences > Sync)? Is anything logged to Windows > Log?

#3

In the end I would have to pick one database, move all its contents into a new DB and restart the whole thing.

That is definitely not required (nor advocated).
From the built-in Help > Documentation > Troubleshooting > Sync Issues…

image
image1586×1750 580 KB

Also, there is a very sporadic and unreproducible issue some people have reported with Dropbox.

If the sync location verifies successfully… In DEVONthink’s Preferences > Sync, click the plus button under the Locations list and choose Add Dropbox Sync Store. Give it a new name and enter an optional encryption key, if desired. Choose the smallest database and sync to this new location.

Then add the location to DEVONthink To Go’s Settings > Sync: Edit Locations and/or the sync locations in DEVONthink on other Macs. Sync to the new location, then make some minor changes, like changing a label color on some files to see if it syncs correctly between the Mac and mobile.

#4

This is a big problem for me as well, which I reported separately. This work-around does work, but it’s an enormous PITA to make the transfer, and then update 3 different DTP installations and 2 different DTG apps to use the new sync location. It ends up taking some hours to resolve.

#5

Thanks for the reply.

The sync location does verify successfully.

The description of the workaround seems to be incomplete. Once I have created a new sync location and synced the smallest database to it, and linked it up in DTTG or DT3 on another Mac … then what do I do?

#6

You would touch the new sync location in DEVONthink To Go and sync with the database.

Note: If you are using Download Files: On Demand for your databases in DEVONthink To Go, leave the old Dropbox sync location enabled and click Proceed when you see the warning.

#7

This seems to be a problem that is reported more often these days. And they I experienced myself.
The personal answer I got contained some pretty wise words that I was unable to extract all their wisdom from, my bad…

42
421564×342 65.2 KB

1 Like
#8

This sounds like an excuse to me. This has happened multiple times to me, multiple times to my wife, across multiple versions and computers over more than two years. I have spent probably close to 40 hours resolving the issue.

I’ve been building software and leading software teams for almost 30 years. I would never accept this reasoning from my team.

#9

Sorry, I’m still having trouble understanding. If you mean:

[a] Leave big database that is failing to sync without errors in existing Dropbox sync store
[b] Create new Dropbox sync store and add small db
[c] Sync to new Dropbox sync store from DTTG, make a change, resync

Then I have done all that, and it does not kickstart the failed sync on the problematic database.

#10

Then I have done all that, and it does not kickstart the failed sync on the problematic database.

It’s not supposed to. It’s to ensure the new location is syncing. If so, sync the problematic database to the new location.

#11

Ah, OK. So I do have to re-upload a huge database. I misunderstood your first reply as suggesting that wouldn’t be necessary.

#12

And so I repeat my original question: Before I do it again this time, can I do anything to help you fix this bug (without sending you details of the contents of the DB, which are legally privileged …)?

#13

Yes, you’d need to reupload the database.

When you start a support ticket, there is no information about the actual contents of the database shared. Just name, size, word counts, and size of largest item.