Welcome to PhotoStructure, @ericb!
Hmm, where 1 is a stubbed toe, and 10 is cosmic calamity, it’s probably a 3.
This setting only comes into play if you are fighting a bug in PhotoStructure’s “opened-by” locking.
Taking a step back: PhotoStructure uses SQLite to persist your library database.
SQLite only supports concurrent read/write on a local filesystem.
If a library is somehow mounted on another computer (either by exporting the local library via SMB/NFS/whatever), or the library was mounted from an external NAS, bad things will happen if PhotoStructure runs
sync concurrently on multiple machines against a single library database (basically it will be a case of random-one-in-wins, and data loss is almost guaranteed).
To guard against this, PhotoStructure writes “opened-by” lockfiles into the
/path/to/library/.photostructure/opened-by directory. They’re just JSON files: you can open them up to see what’s in them:
jq . *.json
Getting back to your actual issue:
You should be able to run 5-10 sync-file processes concurrently against an HDD (but it totally depends on the contents of your library, the speed of your disk, and the speed of each core). Keep an eye on
top or any top-like tool) to see if you’re overwhelming your HDD.
Check the about page (http://localhost:1787/about) to see what PhotoStructure has scheduled by default. If you want to try higher parallelism, you can explicitly set the number of sync-file jobs and image operation threads per job with the
sharpThreadsPerJob settings: either edit your
~/.config/PhotoStructure/settings.toml or use environment variables: both work.
Lots more details about settings are here.
You may be afflicted by some as-yet-undiscovered bug in PhotoStructure, too: if you crank up parallelism and don’t see thumbnails whizzing by, set
LOG_LEVEL=debug and send me your logfiles.