I would like to see a run condition that kicks in as soon as the app is opened. “Run while the app is open”.
This way, I don’t have to manually select the force start option. And - more importantly - do not forget to deselect it.
For me, as a techie, this is not so much a problem. But setting it up on my sisters phone it would make things easier if she needs an immediate synchronization.
Maybe syncing newest to oldest would also be a nice default.
I wish this could go into the GitHub issue tracker, but it seems you prefer feature requests in the forum…
I think the run conditions are customized in this case so that some or all of the folders pause most of the time when the app is opened? And that requires you to override by “force start” then, right?
Check out sync for X minutes every hour in the run conditions. Would that fit you as an alternative? Then the quick settings tile could help to start a new sync cycle immediately.
I’m currently my self not interested in developing more run conditions as this opens a can of worms, including the possibility there might be contradicting conditions not easily to understand.
I am using SyncThing Fork. The default is that it runs for 5 minutes, then pauses for 60.
My intend is to easily force a sync now, without having to set “Force start, ignore run conditions”.
Ohh, nice. I missed the quick settings tile. This does the job perfectly.
Thank you.
I guess what I suggested is relatively easy to implement and understand. But with your suggestion above I already found my solution.
Maybe you could add a button within the app that does exactly the same as the quick settings tile. I would place it as a play button in the top right next to refresh or on the status page.
Apparently I do not understand the problem: open app → sync, exit app → stop
Ok, let’s go there.
When I first tried the android app and I saw the UI, what you say is also what I assumed. But the longer I play with it and observe its behavior, the more it seems like the UI is just a “frontend” or “facade” or “view” of the real software which runs in the background, always (although it doesn’t always do any work, that’s what the run conditions regulate). IOW, the android UI plays the same role (in my current understanding) as the web interface in the desktop version.
Now, if this is right – and it may very well be wrong, I’m biased running a Linux desktop after all, with daemons running in every direction – then you wouldn’t expect the Exit menu item in the app to stop syncing, would you? Not any more than closing the web page does that on the desktop.
Of course, the real problem here is that the android app is, ahem, underdocumented.
So, someone who knows the details (and that’s probably someone who’s read the code specifically of the android app) should set me straight about this.
It’s not really the same . If you close the app using the Exit button, the background Syncthing process will also stop. As for the Web GUI, you can access it on Android too, either from the left slide-out menu in the app, or just from a Web browser.
It is true that there is barely any documentation regarding the Android wrapper app itself.
True, my mistake. I use it. Never questioned it, as it was so heavily advertised how much battery it saves.
So what do you click, step by step?
Because I look for a solution that does not require me to override all run conditions. But maybe you do not understand the problem because you do not use timed run conditions.
However I want to note again I was already given a solution with the quick settings tile, which I would like to see within the app, too.
. If you close the app using the Exit button, the background Syncthing process will also stop. As for the Web GUI, you can access it on Android too, either from the left slide-out menu in the app, or just from a Web browser.