Yeah, agreed, and if we had the option to delay scans like that it should be on by default when not running with the watcher at least. Honestly I can’t imagine it should be particularly difficult to implement, we have a general key-value database, we already do the same thing for scheduling database maintenance for example.
2 Likes
I think the two are basically the same and share the same drawbacks. For me, suspending is useful, e.g. when the phone isn’t used, with the screen turned off (and possibly even only when in doze mode, if you wanted to be extra safe). There shouldn’t be any events happening that need watching at that time anyway.
There is an issue on GitHub about disabling the initial scan, but as far as I remember, it’s mainly about Receive Only folders, which aren’t supposed to change locally anyhow, so it shouldn’t matter if Syncthing wasn’t running for a while.
2 Likes
Clever thought, but in my opinion isn’t right.
Sure, the user won’t shoot a new photo (file) when the screen is off. But another app like WhatsApp (or messenger in general) might save a new media file meanwhilst. 
Thank you all for taking part in this discussion. 
It really enriches my view atm and keeps me from doing anything silly with the wrapper. 
That’s why I mentioned doze mode for extra safety, as that ensures the device is sleeping with no activity 
. At least as far as I understand, Android will escape doze briefly if a priority notification arrives (like the one from WhatsApp). No solution is perfect, so I’m sure there will still be some edges cases though.
1 Like
Btw how does Syncthing react to an overflow event on the inotify watch queue? Does it trigger a rescan if missing some event?
if (event->mask & IN_Q_OVERFLOW) { rescanFolder(); } ?
Agreed, but the trick it does in this case is not super advanced, and could be done with the REST API as well. The iOS app simply pauses all devices when the system is about to put it in the background, then unpauses them all when the app is activated again (foreground or background). Reconnection is typically very fast. See here.
The actual trickery is with telling iOS to give us as much active time as possible We tell it to schedule hourly jobs to run when connected to the charger, for instance, and we try to stretch the time we get after the user switches to another app as much as possible. Then we have ways for the user to trigger the app to sync in the background (through Shortcuts) when e.g. some other app is opened or closed.
With phones reaching laptop specs and performance (mine has an NVMe drive apparently..), the only real issue imo is battery drain. (There are also OS limitations to consider, but in the case of iOS these mostly pertain to reducing battery drain again.)
Syncthing may not be optimized for power efficiency right now, but it is actually doing a very decent job (especially on high-performance phones, where rescanning a big folder with 100.000+ files can be a matter of seconds) and it can really work, especially if some other measures are taken as well (i.e. the on-demand and selective sync features in Synctrain are not just convenient, they also help keep the size of the local folder copy down, which reduces the need for scanning and actual syncing.). Mobile may be challenging but at the same time, file synchronization is very relevant there.
7 Likes
@pixelspark Pausing devices might be the best power saver then, thanks for pointing it out 
.
Does pausing a device also drop relay tcp connections?
According to this feedback, I think the relays are most “power consuming”: Still high battery drain · Issue #1172 · Catfriend1/syncthing-android · GitHub
Is there a way offered by the IOS app to the user to manually be able to pause devices or is this only up to the wrapper and users can pause folders as they like?
As far as I know it drops all connections for a device, which include relays. Discovery etc. is not stopped but also much less battery-intensive (you could toggle these as well of course, changes seem to take effect immediately). Actually I might add this
Some more background; when iOS backgrounds an app it doesn’t appear to close any sockets. So in some cases the app would wake up after a while and try to talk to a socket that really doesn’t work anymore. Pausing and then unpausing forces the app to make new connections which may seem inefficient, but in practice makes it work much better because the app doesn’t hang while trying to communicate with closed sockets.
Users can pause devices as well as folders at their discretion from the UI or through shortcuts. The app will always pause all devices on suspend (and hence has to remember the devices the user explicitly disabled, so they don’t get unpaused again later).
Well if this is the case, you could consider disabling/enabling relaying from the wrapper based on certain circumstances. Another idea would be to limit the number of parallel connections and/or try to influence which connections Syncthing makes. (The iOS app exposes an option that exists in Syncthing config that tells it to connect to a single peer only - that works great if all your non-mobile peers are interconnected and have all the same folders).
1 Like
Just for the record, I used to pause remote devices before moving to my current approach of suspending the whole process. It didn’t really help much though, because with discovery, relays, etc. running, the other devices were still trying to connect constantly, which led to high battery drain on the device in question 
.
1 Like
I’ve tested discovery activity today and found out it’s not doing much. It announces the current device id+ips and then gets a “reannounce-after: …” 58 minutes in the future answer from the discovery server. I don’t think it will cost much juice. So we are in the wrong place here to look for issues.
Hmm, so trying to connect to a listening socket with paused instance behind it won’t help as the app still handles the request “from juice”. The better option might then instead of pausing setting “listeners = none” . Is that a valid cfg option ?
Plus, I wouldn’t have to remember user pauses and wrapper pauses separately.
Hm, on iOS, afaik the app will not wake up if someone connects to a socket it used to listen to before being backgrounded, so it’s not a problem. If it does on Android then disabling listeners before app suspension seems to be the solution. Disabling listeners does not prevent outgoing connections I think (so that’s why you’d also pause the devices).
Agreed, however it could still be useful to pause then unpause discovery again to force a re-announce on app forgrounding.
1 Like
I am not sure that I understood the problem.
I you want to dynamically update 2 different sites, both sides will need to contact each other - as it seems every 90? seconds. That’s to be expected.
But when both sides are paused, should that not stop any traffic for good?
If not, closing the Syncthing instances should do the thing, or not? I mean, for situations like over night.
And personally, I have one site reveive-only and the other send-only. If I pause the send-only side, I would also expect zero traffic.
Is that NOT the case?
The other side will still keep trying to reconnect, as it has no other way to know whether you have unpaused the device or not. With cloud-based solutions this wouldn’t be necessary, as the central server could simply manage the connections, but with Syncthing, which is peer-to-peer, this isn’t possible.
I don’t believe specific folder types have any relevance in this matter.
1 Like
In fact you may get more traffic for a paused device - a full TLS handshake every 60 or so seconds, instead of a small ping message on an established connection every 90 seconds. (Assuming they can reach you and are not also paused)
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.