Slow directories (those that don’t readdir in less than readdirCacheSlowMs) are now automatically excluded from tag inference to prevent sync from bogging down on slow/huge directories.
Tag inference can now be completely disabled with the new setting, enableSiblingInference=false.
beta.10 didn’t properly migrate libraryPath, and for docker users, the prior behavior defaulted writing settings directly into /ps/config, but beta.10/11 wanted to write to /ps/config/PhotoStructure, which resulted in people unexpectedly seeing the welcome page or Error: code ENOENT: ENOENT: no such file or directory, open '/ps/config/PhotoStructure/settings.toml'. The old and new configuration directories will be automatically merged the first time beta.12 runs.
Large library databases will automatically increase maxMemoryMb and maxRssMemoryMb values to accommodate larger SQLite caches. If non-default values have been set by the user, though, they will be respected.
Upgraded all outdated dependencies, including SQLite 3.36.0
If a file is missing a value for metadata, like the captured-at time, and enableSiblingInference is true (which is the default), PhotoStructure will look for “nearby” files, and if they seem like they were taken by the same device and around the same time, it can infer Make, Model, and captured-at from those “siblings”. For more detail, see https://photostructure.com/faq/captured-at/#step-4-infer-a-date-interval-from-siblings
How would this be determined? Are you analyzing photo contents in some way? Or is it done by analyzing whatever metadata does exist?
OK, I actually read the blurb now. Sounds like it’s just looking at file name and filestamp (what is that?).
So, if you have photos from two different devices but with similar names in the same folder, there’s a risk that you’re going to infer data that isn’t correct. Do I have that right?
A file is “contemporary” with another if the birthdate, mtime, or ctime are within a day of each other.
Yeah, without the “contemporary” check, you’d be correct: files that shouldn’t be used for inference would be eligible.
However, by only considering the files that were taken within the same 24-hour period, and if there’s a “trustworthy” captured-at time from a sibling before and after a given file, I’m hoping the date interval should be fairly safe to infer.
Gotcha. I assume the birthdate is synonymous with “date created” in Windows, and the mtime is synonymous with “date modified”?
Perhaps it’s just me, but I’ve always found those values to be HIGHLY unreliable. For instance, if I copy files from one computer to a thumb drive, and then place them in my main photo directory, the Date Created seems to be set as the current date/time. Date Modified may be “correct”, but even then it would only be the last time the file was edited, not necessarily the date the photo was taken.
Maybe I’m doing something wrong?
All this to say, I think for now I will turn off sibling inference. Most of my files that are missing EXIF dates are older photos or scans, and they all live in a “date unknown” directory until I can figure out a proper date and update the EXIF appropriately!
I’m seeing a weird maybe-issue when I click “Folder”, it only shows the first 4 folders, no more.
I’ve tried rebuilding the library.
To replicate. I click “Folder”, and it very kindly jumps straight to the path “Folder > {VolumeLabel} > {LibraryName}” which is great.
Then I see:
“Folder > {VolumeLabel} > {LibraryName} > 2008”
“Folder > {VolumeLabel} > {LibraryName} > 2011”
“Folder > {VolumeLabel} > {LibraryName} > 2012”
“Folder > {VolumeLabel} > {LibraryName} > 2013”
And that’s it. Thumbnails appear I guess correctly under each folder in this view. (NB- 2009 and 2010 don’t have a folder in this library.)
If I click on {LibraryName} in the breadcrumb, then I see all the other folders I’d expect to see, such as the ones listed above, plus -
“Folder > {VolumeLabel} > {LibraryName} > 2014”
“Folder > {VolumeLabel} > {LibraryName} > 2015”
… and so on - the normal full list.
Should I raise a separate bug - this isn’t by design right?
Slow directories (those that don’t 
beta.10 didn’t properly migrate 
macOS now has