Thanks for the report and welcome to PhotoStructure, @odd7of8 !
As I was waiting for CI to go green tonight, I thought of a different way to schedule sync jobs and coded it into beta.10, which should resolve this issue.
I’m hoping to release beta.10 late tomorrow or Sunday.
I’ve been wrestling with batch-cluster for the past couple days to ensure sync-file health checks run properly and that stderr/stdout streams are flushed completely before resolving or rejecting tasks. When examining (tons) of people’s logs they send in, if their sync got “stuck” it seemed to be due to this issue.
If you click search, and click the saved “recently updated” search, and no new files are there, that must mean that sync didn’t pick up new files. I’ll look into that.
Actually, I think we’re fine (at least for now). 12 hours and 44 minutes ago was when I updated to beta.15, which would have kicked off a sync manually. New files WERE pulled in at that time. Then, I added some more files to see if they would show up on the next sync, erroneously thinking that would happen overnight. So I need to wait until the last sync was 24 hours ago.
Humbly I’d like to suggest that sync be scheduled absolutely, rather than relative to the last sync. Absolute scheduling produces reliable behavior, while relative scheduling could be affected by upgrades and manual syncs.
I have some pretty big drives that took a long time to import–way longer than 24 hours–so to prevent them from being restarted before they completed, I made the interval count from last-completed, rather than last-started.
Sigh! I’ll check my test libraries and see if they’re misbehaving as well.