You could try running badblocks on the external drive: https://en.wikipedia.org/wiki/Badblocks
I usually run lsblk to find the device name first, so something like this:
badblocks -s /dev/sdb
should scan the entire disk regardless of the filesystem.
Thanks, I ran that:
For /mnt/Red 1TB:
sudo badblocks -s /dev/sdb1
Checking for bad blocks (read-only test): 0.00% done, 0:00 elapsed. (0/0/0 err103486176one, 16:49 elapsed. (0/0/0 errors)
103486177one, 16:52 elapsed. (1/0/0 errors)
103486178one, 16:56 elapsed. (2/0/0 errors)
103486179one, 16:59 elapsed. (3/0/0 errors)
103487252one, 17:06 elapsed. (4/0/0 errors)
103487253one, 17:10 elapsed. (5/0/0 errors)
103487254one, 17:13 elapsed. (6/0/0 errors)
103487255one, 17:17 elapsed. (7/0/0 errors)
done
For /mnt/DATA:
sudo badblocks -s /dev/sda5
Checking for bad blocks (read-only test): done
What I don’t understand is that in the log file above it appears to me that the troublesome .db file is on /mnt/DATA:
05-31 21:04:54:293 7527 OCC::SqlDatabase::openOrCreateReadWrite: Consistency check failed, removing broken db "/mnt/DATA/._sync_b233c4bbec31.db"
I then ran
fsck -a /dev/sda5
fsck -a /dev/sdb1
And then checked using gparted (which I think is the same thing)
For the sdb1 Red 1TB externals disk an error came up about cluster mismatches, NTFS is inconsistent and it told me to run chkdsk /f on Windows and reboot twice (I couldnt copy paste these errors) and doing this removed this gparted error and check worked.
So it looks like I solved my latest problem about the crash but now I am back to the behaviour in post 14 above 
Directly after reboot (step 1 in post 14 above) I ran the client from a terminal with logfile and the error in the terminal when it stopped (step 2 in post 14 above) was:
ICE default IO error handler doing an exit(), pid = 1524, errno = 32
And the last bit of the log was:
06-02 06:16:24:049 1524 OCC::SyncJournalDb::commitInternal: void OCC::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit "checkConnect End"
06-02 06:16:24:102 1524 unknown: QString::arg: Argument missing: "https://docs.nextcloud.com/desktop/2.2/" , 2
06-02 06:16:24:102 1524 unknown: QString::arg: Argument missing: "https://docs.nextcloud.com/desktop/2.2/" , 3
06-02 06:16:24:125 1524 OCC::Account::resetNetworkAccessManager: Resetting QNAM
06-02 06:16:24:125 1524 OCC::ConnectionValidator::checkServerAndAuth: Checking server and authentication
06-02 06:16:24:125 1524 OCC::ConnectionValidator::checkServerAndAuth: Trying to look up system proxy
After this has stopped and I restart the client successfully (step 3 in post 14 above) the log continues:
06-02 06:28:58:814 1884 OCC::ConnectionValidator::checkServerAndAuth: Trying to look up system proxy
06-02 06:28:58:818 1884 OCC::ConnectionValidator::systemProxyLookupDone: No system proxy set by OS
06-02 06:28:58:818 1884 OCC::AbstractNetworkJob::start: !!! OCC::CheckServerJob created for "https://ubuntu-standard.local" + "status.php" "OCC::ConnectionValidator"
06-02 06:28:59:223 1884 OCC::AccountManager::saveAccount: Saving account "https://ubuntu-standard.local"
06-02 06:28:59:224 1884 OCC::AccountManager::saveAccountHelper: Saving 1 unknown certs.
etc etc
Does this mean the client is initially having difficulty connecting with the Box?
The problem is with the external NTFS Red 1TB disk - if I remove that the client opens at startup or manually, giving the red cross (source missing) icon. Then, when I plug in the external disk the client starts functioning normally.
In case this may be of help to someone in the future:
I got a new hard disk and did a fresh install of Xubuntu 18.04 (old one was upgraded from 16.04)
I also reset the Disks (gnome-disk-utility) ‘edit mount options’ back to ‘use session defaults’
Now all works fine - I just have to mount the external disk after startup
Not sure exactly which of above changes did the trick - maybe buying new external disk?