Versioning certainly hasn’t gone as smoothly as I’d prefer.
In my testing, v1.1 is stable on all platforms for small (sub-25k) libraries, but some people’s configurations (especially on Windows and macOS) may prove to be less stable.
I found that when the v1.1 library database got larger than 100-200 MB (tracking 100k+ files), SQLite updates could timeout or fail, especially when running under heavy concurrency (10+ threads), or when stored on a slow (HDD) disk.
I rewrote how PhotoStructure does parallelism and database persistence from v1 to v2, and that meant larger libraries (350k+) were handled gracefully, but there were show-stopping issues on macOS and Windows that meant I couldn’t promote v2.0 to :stable
. I felt that the new workarounds for macOS and Windows were sufficiently different enough to warrant not being :beta, so I “skipped” v2.0:stable and re-characterized the release as a v2.1 alpha build.
The latest :alpha
build, v2.1.0-alpha7, is actually quite stable on Linux and Docker. There are still some bugs (like failures with rebuild
, timezone parsing for more exotic filetypes, and some image hash deduping errors), but those shouldn’t impact daily use.
In an effort to help stabilize the next build, I’ve made a (quite large) change to how PhotoStructure handles errors: previously, if “bad things” happened, I would emit an error log message, and shut down.
In this next build, the webserver will try it’s best to stay running, and if there is an issue, will redirect the browser to a new “health check” page. I’ve written a couple handfuls of “repair jobs” that are then suggested (when appropriate) to remediate whatever is making PhotoStructure grumpy.
This approach also means people don’t have to
a) know that PhotoStructure has error logging
b) figure out how to find and read those logs