I’ve been successfully using Tasker and Termux to run a cron-like daily Syncthing session with a remote backup server rather than have the app run/sleep all the time.
(This may not be my best/only option, but its worked reliably for a couple of years, so I would reluctant to reimplement across multipe phones without good reason)
Recently, some time after Syncthing-Fork 1.27 (?), my script can no longer start Syncthing-Fork via ‘am broadcast start’, although if I launch the app manually in foreground, that autostarts the syncthing server, which my script detects as before, monitors the session to sync completion, then uses ‘am broadcast stop’ to successfully end the syncthing server as before, but it now leaves the app in ‘sleeping’ mode.
Has anything changed recently in this area that my script needs to adapt to?
I guess my basic problem is understanding the linkage between the android-specific app and the generic backround server.
How is the broadcast start message now intended to work if the app is not already running? Is there any writeup of this anywhere (including any interaction with autostart-on-boot, which I don’t want)
For whats its worth, my current failing version is S-F 1.29.7.4 as installed via F-Droid. Termux and Termux API package versions are current, but I assume those are not relevant given that the ‘am broadcast stop’ works ok?
I considered reinstalling an older version (say 1.27) as an experiment, but didnt want to fall foul of any config changes that are not backwards compatible. Any advice on that would also be helpful
Thanks for the quick reply. I’ll go have a read of the wiki, but I was intrigued by your remark about autostart - has that changed recently? I’m pretty sure I’ve never had that enabled before (or now) because I dont want the app running/sleeping all the time
aha - so someone else has had the same issue!
Maybe autostart is a work around, but I’d like to understand when/why the change happened - may be a bug? Do you know version details or who had the other problem?
Thanks for that. I read the discussion and can well understand the problems. The joy of Android …
(I first thought it was just a problem on my old Android 11 phone, then our other Android 16 phone got the updated syncthing and hit the same problem).
Do you foresee any config issues with me reverting to 1.29.6.2 for the time being?
Idk, but you should avoid importing the database if you use the app’s export/import function.
Better test with an empty install to give feedback and leave your prod instance intact? If you, for example, are on release you can install a second Syncthing app by using the debug build from CI. That requires setting different listen/webui ports. (auto detecting and adjusting ports is also part of v1.29.7.x)
Good advice! Thanks for that. I’ll let you know how I get on, but it won’t be for a day or two - lots of other things going one (and my brain hurts in this heat…)
Sorry for the delay. I took a punt and uninstalled 1.29.7.4, then installed 1.29.6.0 from github catfriend release 1.29.6.0 (rather than try anything clever involving debug builds and parallel installs).
Seems to work ok, and now has the old behaviour (i.e. I can start/stop the service by broadcast). So in the short term I am happy, but of course I don’t want to be stuck on an old build!
Sadly, although I have written a fair amount of Java in the past, I don’t have sufficient Android competence to write and test a fix that includes your enhancement [Issue #1192] and retains basic service control capability [Issue #1435].
From my selfish point of view, if we can’t have both, I would rather have #1435 fixed than #1192, but I would say that, wouldn’t I?