Add a setting to automatically exit the app after a user-defined period of inactivity (e.g., 5, 10, or 15 minutes).
“Inactivity” could be defined as a period with no active file transfers and no user interaction with the app’s interface.
Problem or use case
It is easy to open the app for a quick task and forget to close it, leading to significant and unnecessary battery drain from the app running in the background.
This feature would provide a “fire-and-forget” experience, allowing users to perform a task with confidence that the app will close itself afterward, thus conserving battery. It is best suited for users who prefer to sync files in discrete sessions (ex: once or twice per week) rather than continuously.
Alternatives or workarounds
The main workaround is to remember to manually exit the app after each use, which is an easily forgettable step.
The existing “run on a schedule” feature is not a good fit for this use case, as it forces syncing at fixed intervals (once an hour) rather than simply stopping the app after a specific syncing session is complete.
Is there really much battery drain from Syncthing? I’ve never noticed Syncthing being high in the statistics, and my phones generally have normal battery life.
Yes, we had this discussion recently, but basically, the main culprit is due to Syncthing keeping the connection alive. This is both about connections to other devices, but also discovery server, relays, etc.
@ScarecrowRepair Yes, it drains the phone’s battery really quickly when I forget to exit the app. I notice the battery drain because I usually keep my GPS and mobile data turned off to save power. If I left them on all the time, I probably wouldn’t notice the app’s consumption, but my battery would be dead in less than five hours anyway.
@239 I often use Syncthing when my phone isn’t charging. While the symbol in the top bar is useful for noticing that I’ve forgotten to turn it off (that, or the battery level), it isn’t enough if I don’t interact with my phone for a while.
If this is really originating from the fork app, we should resolve this first. It is much more easy than the other request which requires writing code logic. How is your discovery and device to device set-up?