I have been trying out the 2024.3.3 beta version of photostructure for Raspberry Pi. There’s a lot I like about it so thank you for all the work that’s gone into it.
One thing that concerns me is that it takes around 6 hours for my pi to re-sync my library of around 26,000 image files. Because I use my pi to also run other services, I’d like to change the sync interval to weekly instead of daily to conserve resources.
Looking through the guidance, I’ve found posts saying that I can change SyncIntervalHours in the library settings. Yet I’ve found no variable (including commented out variables) for ‘SyncIntervalHours’ or PS_SYNC_INTERVAL_HOURS in my library settings.toml.
Is it safe to simply insert a line that specifies a value for SyncInteralHours into my library settings.toml for the server version for Raspberry Pi, or has the way to configure that setting been changed for that version?
Edit: When I re-checked and realised I’m running the beta version and not alpha.
You answered my first question, but reflecting on the first paragraph of your response, I think I might have asked the wrong question.
To investigate the amount of time taken for the sync, I realise that photostructure is identifying changes in mtime for all photos stored in the directory.
My sync-reports for two syncs of the same directory run shortly after another (without any changes to the files) say this:
1715815872531 2024-05-15T23:31:12.531Z /mnt/Elements/share/pictures/2012-01/Image0006.jpg enqueued AssetFilePrecheck update needed: file mtime changed since last sync http://127.0.0.1:1787/asset/32
...
1715815872780 2024-05-15T23:31:12.780Z /mnt/Elements/share/pictures/2012-01/Image0006.jpg started AssetFileImporter
...
1715815878151 2024-05-15T23:31:18.151Z /mnt/Elements/share/pictures/2012-01/Image0006.jpg synced AssetFileImporter 5371
and, only a minute or so later (when running sync again on the same directory):
1715815976136 2024-05-15T23:32:56.136Z /mnt/Elements/share/pictures/2012-01/Image0006.jpg enqueued AssetFilePrecheck update needed: file mtime changed since last sync http://127.0.0.1:1787/asset/32
...
1715815976383 2024-05-15T23:32:56.383Z /mnt/Elements/share/pictures/2012-01/Image0006.jpg started AssetFileImporter
...
1715815981769 2024-05-15T23:33:01.769Z /mnt/Elements/share/pictures/2012-01/Image0006.jpg synced AssetFileImporter 5386
I’m not using the automatic organization function. Is this expected behaviour where automatic organization is not used?
For what it’s worth, my files are stored on a USB HDD plugged into the pi. I also have a smb share to the same drive, but I’m not aware that any process using the smb share needed to access the relevant directory.
The ‘date modified’ for the image file as shown on my system is 18/01/2012 8:10 PM. There is an associated xmp sidecar, with last modified date of 11/05/2024 11:19 AM (but this was also not modified or accessed between the two sync jobs).
Howdy! I’ve got limited internet access at the moment, so apologies for the latency.
If sync Is behaving as designed, any given files should only require a stat() call to verify that it’s mtime and file size have not changed since the last import. If there are any sidecars for the file, the mtime is the greatest of all sidecars and main file. You can check the sync report to verify it’s properly “no-op”ing any untouched-a-last-sync files.
Sync frequency in newer builds use a crontab entry which may prove much more amenable to whatever preferences you have (say, scheduling sync to only start after your phones run their nightly backup jobs).
Thanks Matthew - no need to apologise, and I can wait for whenever is convenient for you for a response to this one also.
What should I look for in the sync report to verify that it’s properly 'no-op’ing the untouched-a-last-sync files?
I’m a newbie, but my understanding of the sync reports I’ve extracted above is that it’s not properly 'no-op’ing those files - it is identifying them as having a change in mtime between two sync processes run only minutes apart. Perhaps the response to the stat() is getting miscommunicated somewhere in the chain?
Should I be checking anything else in the sync report other than what I’ve extracted?
Edited: to mention that I’ve understood the crontab sync scheduling now - thank you and tkohhh both for answering that one. If I can’t figure out how to get the sync to properly recognise mtime changes, that (which I initially thought was the correct solution) will be my solution of last resort.
