Not running every hour
hastyeagle opened this issue · 10 comments
I have a folder for DCIM/Camera setup on the app and have it set to NOT watch for changes (I just want to update once an hour, not every time a picture is taken), and have the folder shared with my Syncthing "server". It syncs just fine when I first start up the app, but after that it almost never will see any changes even though I'm taking pictures and deleting them. I took a picture before bed last night to see if it would pick it up, and it did at ~5:00am (so ~6 hours later). If I stop the app and run it again, the new changes will sync immediately.
If I change the folder to enable watching, syncs happen almost immediately after taking a picture or deleting pictures.
I run in airplane mode all the time while at home and I tried enabling the "Run when device is in flight mode", but that didn't help. I even turned off Run conditions and that, too, had no impact. Battery optimizations are unrestricted, and I can see the app running in the background.
What am I missing?
Version Information
App Version: 1.27.3
Syncthing Version: v1.27.2
Android Version: Android 14 (GrapheneOS)
Can you try doing a simple test like this?
- Completely disable run conditions in the app.
- Pause all other folders and devices to avoid unnecessary noise.
- Disable file watching, set rescan interval to 180 seconds.
- Go to Actions → Logs → Debugging facilities and enabled "Scanner".
- Take a photo and wait 3+ minutes for the scan to run.
- Go to Actions → Logs, and copy and paste the output here.
Thanks, @tomasz1986. I'm not sure why, but I'm not seeing a way to set the rescan interval, or even "Actions" anywhere. I installed the APK from https://github.com/syncthing/syncthing-android/releases/tag/1.27.3. What am I missing?
You need to do all this in the Web GUI. You can access the Web GUI from the left slide-out menu.
Nice -- I didn't even realize the Web GUI was available. Now that makes more sense :) I did the test and the new photos synced right over on time. I deleted the picture, and it synced again after ~3 minutes. I changed the rescan interval to 15 minutes and going to see if it still works.
Have you seen issues with a 1 hour scan interval on devices before? It was definitely set to 3600s before, so I'm not sure why it wouldn't work as expected. Once I test 15 minutes I'll go back to an hour with logging enabled and see what it shows.
I had it set to 15 minutes and it synced one time and now it's been ~40 minutes without another sync (with things needing to sync). The logs show the last walk at 18:46 and then a reconnection and the no more walks after that. I readacted some of the log.
2024-02-21 18:46:29 started hashing: File{Name:"IMAGE.jpg", Sequence:0, Permissions:0770, ModTime:2024-02-21 18:33:39.527229715 -0500 EST, Version:{[{M32HJRE 1708559189}]}, VersionHash:, Length:3333393, Deleted:false, Invalid:false, LocalFlags:0x0, NoPermissions:true, BlockSize:131072, NumBlocks:0, BlocksHash:, Platform:{<nil> <nil> <nil> <nil> <nil> <nil>}, InodeChangeTime:1969-12-31 19:00:00 -0500 EST}
2024-02-21 18:46:29 completed hashing: File{Name:"IMAGE.jpg", Sequence:0, Permissions:0770, ModTime:2024-02-21 18:33:39.527229715 -0500 EST, Version:{[{M32HJRE 1708559189}]}, VersionHash:, Length:3333393, Deleted:false, Invalid:false, LocalFlags:0x0, NoPermissions:true, BlockSize:131072, NumBlocks:26, BlocksHash:HASH, Platform:{<nil> <nil> <nil> <nil> <nil> <nil>}, InodeChangeTime:1969-12-31 19:00:00 -0500 EST}
2024-02-21 18:46:29 walker/fak4c-l5gnf@0x4000328790: Walk fak4c-l5gnf [] current progress 3333393/3333394 at 0.0 MiB/s (99%)
2024-02-21 18:46:29 walker/fak4c-l5gnf@0x4000328790 Walk progress done fak4c-l5gnf [] Matcher/[]@0x400337abd0
2024-02-21 18:54:43 Lost primary connection to <ID> at 192.168.10.223:22000-192.168.10.51:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-UUID: reading length: EOF (0 remain)
2024-02-21 18:54:43 Connection to <ID> at 192.168.10.223:22000-192.168.10.51:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-UUID closed: reading length: EOF
2024-02-21 18:54:57 Established secure connection to <ID> at 192.168.10.223:22000-192.168.10.51:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-UUID
2024-02-21 18:54:57 Device <ID> client is "syncthing v1.27.2" named "syncthing" at 192.168.10.223:22000-192.168.10.51:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-UUID
Have you seen issues with a 1 hour scan interval on devices before?
Nothing like that, it's just quicker to test with short rescan intervals 😅.
Can you try doing yet another test with the "Keep the CPU awake while Syncthing is running" option enabled in the Experimental settings?
I enabled "Keep the CPU awake while Syncthing is running" and so far the 15 minute sync interval is now working as expected. It hasn't missed a sync in the few times I tested. I just switched it to hourly now and we'll see if it continues.
Assuming this is the fix, I'm hoping this doesn't impact battery too much. Any idea of the impact that option has? I'll be letting it run in the background overnight as well, so I guess I'll let you know as well.
Honestly, if battery is your main concern, I think it may be better to just keep the file watcher enabled and set the rescan interval to something like once per day only. Depending on the size, scanning the whole folder every hour may be much more battery draining than just scanning and syncing the single pictures every time you take them.
This is what I do personally, and I also keep the app at the "optimised" battery setting in the OS. This way, Syncthing is suspended when Android is in the doze mode. I also keep all run conditions disabled, because I've found out that constantly exiting and restarting the app is also more battery and especially time consuming that just allowing it to run all the time in the background.
Great suggestions, @tomasz1986! It wasn't too bad overnight...while Syncthing contributed to 50% of battery usage, that really only equated to a battery capacity drop of 4% overnight using an hourly scan. I'm backing it off to a 4 hour interval scan to see if it reduces battery usage even more. For me, at least for now, I really only want to backup once or twice a day. So once I see if 4 hours helps to reduce it even further I'll back the interval off to once or twice a day.
I'll keep your suggestions in mind, too. They definitely make sense.
For the "Keep the CPU awake while Syncthing is running" setting. Any idea why that's needed vs. the default behavior of not having it enabled? I'm guessing Android is putting Syncthing in a sleep mode that it then can't start the scan, etc., whereas keeping the CPU awake forces it to not do that. I guess I'm just curious why others don't run into this more often. Type of phone/hardware support?
For me, at least for now, I really only want to backup once or twice a day. So once I see if 4 hours helps to reduce it even further I'll back the interval off to once or twice a day.
I think one possible problem with that is that you cannot schedule a specific scan time, which means that the scan may very well happen, e.g. while you're in the midst of taking a photo 🤪.
If you know what you're doing, you could disable rescan altogether, then install Termux and use curl to control Syncthing via the API. This way, you could force rescan at specific times only.
For the "Keep the CPU awake while Syncthing is running" setting. Any idea why that's needed vs. the default behavior of not having it enabled? I'm guessing Android is putting Syncthing in a sleep mode that it then can't start the scan, etc., whereas keeping the CPU awake forces it to not do that. I guess I'm just curious why others don't run into this more often. Type of phone/hardware support?
Not really sure. Normally, the app should be able to run all the time as long as you set battery optimisation to "unrestricted". I think there may be some quirks because the app is just a wrapper over the standard Syncthing binary, so it's like running yet another program inside the app itself.
I don't think the issue is hardware related at all. Normally, there could be some manufacturer-specific restrictions, as some of them do go out of their way to block apps from running, but you're on GrapheneOS, so I believe it should be fairly stock regarding this aspect.