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
It’s documented on the wiki (part of the GitHub repo).
It works on my Android emulator tests, but I recall a ticket those days a user claimed it not working after precisely following the steps. So maybe a bug is in there…
Make sure, broadcast option is enabled in App>Behavior and that you have ticket the autostart option as well.
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
Not by my intention, but someone reported it didn’t work without autostart after one of the latest app updates. So this would be your first try .
And yes, there were a code change but as far as I recall I did only attach the intent broadcast handling to the force start/stop/follow. Reason behind was, that code did not exist in the early times of this app and is much better integrated than the old RunConditionMonitor bypass code.
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?
.