SyncInterval settings for Raspberry Pi

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.

The only time sync will take that long is on the inital sync. Subsequent syncs will only be for new or changed files, so will take MUCH less time.

That said, you can schedule the sync to run with a cron-like setting described here: PhotoStructure | 2024 PhotoStructure release notes

Thank you! That’s exactly what I was searching for.

1 Like

Hi tkohhh

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
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
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).

I’m not qualified to answer this question, but @mrm can chime in… he’s the head honcho here!

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.

Here’s what noop looks like in my most recent scan:

Thanks again, tkohhh.

It seems I’d correctly understood the sync reports. Should I maybe start a new thread with this issue as a bug report?

To do so, please could you let me know if you need any further information about my installation for mrm to investigate?