Since coming up to 1.9.0 I’ve noticed I seem to get more 95%, 0B issues. I know the cause, I know how to (normally) fix, and I have STRECHECKDBEVERY=1s set. But in all the cases, the sending end’s folders are showing waiting to scan…
Concurrency is either 0 or -1. When the folder is in the above state i’m not able to scan (which makes me wonder if this is tied into concurrency). The watcher is enabled, rescan set to 86400.
But, even restarting with STRECHECKDBEVERY=1s set, doing a scan all, it will drop back to failed
with no option to revert.
In this example, the 429 items are because the folder has been renamed, but I just can’t get St to realise this and ignore / dismiss the missing folder
Nothing in the logs to show any issues.
I’m wondering if I should delete the index database and start fresh, more on the basis that it’s gone through several upgrades.
I am a bit confused as the title is about remote completion but the body about folders that are waiting to sync. For the latter it’s relevant what the concurrency (maxFolderCuncurrency) actually is, as 0 is limited to the number of cpu cores and -1 is unlimited (so you shouldn’t see any waiting for statuses). Setting STRECHECKDBEVERY=1s is not something that you should do regularly for any kind of problem. It’s a debugging tool that tackles some problems that should only be used if you expect to have those problems (e.g. sequence inconsistencies, incorrect meta states). From what you posted here I don’t yet see any problems, just folders waiting to sync (which is a normal state in general, though on send-only folders could indeed be circumvented as it’s not going to do any disk io).
The title is the receive end issue which is caused by the sending end.
I tried the recheckevery based on a recent threads, and offered it as something I have already tried. It’s not a permanent setting
On the sending end, they were set to 0, but I also tried -1 and also higher numbers.
“From what you posted here I don’t yet see any problems” So really I was questioning how I can force a scan on the sending end in order to correct the ‘out of sync items’ It seems that when the ‘waiting to sync’ appears, I lose the ability to do a rescan unless I rescan all, restart St or make changes to the folders settings
For example, once it knows it’s out of sync I get to override changes
but on waiting to sync, I have to wait
which makes me wonder if it was somehow tied to concurrency as this is something I would like to override https://github.com/syncthing/syncthing/issues/6881 but your comment -1 is unlimited (so you shouldn’t see any waiting for statuses suggests a bug as this is happening when set to -1 on the send only end.
Right. So unless https://github.com/syncthing/syncthing/issues/6881 gets addressed, it is indeed the case that while in any waiting state, you can’t trigger a scan immediately, i.e. there’s nothing you can do but wait.
As to folders being in waiting state while max folder concurrency is set to -1: That should not happen as you say. I unfortunately can’t reproduce that. And don’t really have any idea what to debug. You could check the config file on disk if the setting there is the same.
Actually I believe I know what the error is: It isn’t actually waiting, it just never reverted to idle after it’s finished waiting. The PR I posted above already fixes that (as it never goes into a waiting state). As a workaround you can pause and unpause the folder to get it into idle again (which is ugly I know, but I don’t think there’s another way).
