ST 1.5.0 - constantly flickering status


I’ve setup two test nodes and - just for test purposes - tried to sync one of the useless’d folders ever: %LocalAppData%.

Here are the screenshots of the “localapp” folder in question.

Node A:

Node B:

On both nodes, the sync status flickers. It fastly changes between the following texts:

Node A: Out of Sync > Preparing to Sync > Syncing 99% > (… the same again …)

Node B: Scanning > Failed Items > (… the same again …)

It takes approx. 50 msecs until the states change. I constantly see some ~2 to 3 KB/sec transfer rate on the Web UI (counting up).


Logs of both nodes: 2020-05-12_log_of_both_nodes.txt (67.0 KB)

I expected Syncthing would handle this more gracefully instead of retrying every milliseconds again to pull the file.

I think this is a bug in the handling files that have changed on disk and needing rescan. There’s a constant stream of failed requests from A triggering constant rescans on B causing constant updates to A which retries and requests from B… Maybe the rescan never happens.

There was a fix for something similar in 1.6.0. You might try that.

1 Like

And model debug logging (especially on A) would have the interesting bits (though if Jakobs suggestion works that’s moot).

1 Like

Just to follow up: I’ll try to fresh-setup this test scenario again with v1.6.0 when it’s out.

@imsodin As I’ve stated on my other topic I’ve re-setup the test scenario with the LocalAppData sharing “A to B” like its described above and hit the same issue.

A - SR Sender of LocalAppData - v1.7.0-rc.1 B - SR Receiver of LocalAppData - v1.6.1 stable

The fast and endless flip flop outofsync>preparing>sync>… reoccurred. I’ll send the logs on request via G-Drive and pre-emptively to you as PM. This time, I had model debug facility also enabled.

Thanks for your assistance.

Ah okay, I think I’ve solved this riddle. It was unwise of me to make a test sync scenario with my localappdata folder AND using chrome on the same user profile to look at the web ui how syncthing does it. As soon as I close Chrome on device A (sender) the flickering stops. So I think Chrome is writing to files at a high frequency and this causes Syncthing to never finish up pulling from the sender from device B’s (receiver) view.

Only one thing I’d wish to see improved inspired by this scenario would be that Syncthing starts to back off syncing the same file over and over at “millisecond” frequency if it fails more than X attempts one after another (thus assuming the file is in use and being constantly written to by another application). The “flickering” of the sync status choke a lot of CPU on both machines, triggering rescans all the time on A.

I know, for example, the puller currently should have some back-off mechanism if pulling fails and I wish for that to kick in after certain time of “failing”.

One side requesting a constantly changing file means it gets rescanned as often as it’s requested, i.e. as fast as the ping-pong goes (50ms is quite impressive). Not sure whether there’s anything for Syncthing to do here, syncing a moving target won’t work anyway.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.