V1.0.0-beta.10 and v1.0.0-beta.11 released 🎉

What’s in v1.0.0-beta.11?

What’s in v1.0.0-beta.10?

tl;dr: way too much

  • :sparkles: Added validationErrorAllowlist to fix false-positive JPEG validation errors from smartphone photos that aren’t correctly encoded

  • :sparkles: Long tag hierarchies automatically collapse in tag gallery views.

  • :sparkles:/:bug: Volume metadata is now multithreaded to scale to systems that have many attached drives and very slow network drives. See the forum for details.

  • :sparkles:/:bug: MacOS and Windows users with tons of volumes: UUID extraction is now done in parallel, which should avoid “Failed to scan system volumes” errors.

  • :sparkles: Added new keyword re-parenting setting, keywordReparenting

  • :sparkles: Image hashing performance has been doubled (!!) thanks to in-memory binary preview extraction.

  • :bug:/:package: Process handling was rebuilt

    • Asset importing rejection reasons are no longer “errors,” which caused the sync-file process to be recycled (and slow down the import)
    • Health checks are now automatically run, separate from file importing. Unhealthy processes could result in files being skipped in prior builds.
    • Raw image and video importing are now more reliable. Previous implementations would make a go/no-go decision based on the first buffer seen on stderr output–but ffmpeg streams warnings and errors throughout the processing of a video, so this go/no-go was based on incomplete data.
  • :bug: Added another swing at fixing file access errors on Desktop on macOS by calling scandir against the library, user directories, and scan paths from the main process.

  • :bug: sync didn’t idle in beta.9.

  • :bug: startPaused now holds true for new libraries.

  • :bug: Tag counts were incorrectly cached, which could prevent new libraries from showing tag counts properly.

  • :bug: Improved docker mountpoint filtering (scans could get “stuck” in /proc/* volumes)

  • :bug: Remote MacOS AFP volume hostnames are now properly parsed.

  • :bug:/:package: Nav menu improvements on mobile: more reliable scrolling on iOS Safari, and the bottom element should now be visible (even when the bottom button bar is shown)

  • :bug: Filepath tags don’t show volume SHAs anymore

  • :bug: File paths in the Asset Info panel could have rendering issues

  • :bug: opened-by lockfiles from prior versions are automatically cleaned up (to avoid these errors)

  • :bug:/:package: macOS Big Sur versions are now rendered properly on m1 machines

  • :sparkles:/:package: The strictDeduping setting now automatically sets 9 deduping settings to “very strict” values.

  • :sparkles:/:package: Root filesystem tags are now configurable. See the new tagDisplayNameFSLabels and tagDisplayNameFSRoot settings.

  • :package: Fixed the progress caret

  • :package: Fixed the nav menu pointer (thanks, Cowherd!)

  • :package: Improved asset deduping when pairs have different captured-at precision

  • :package: --force now re-transcodes videos (handy for benchmarking ffmpegHwaccel)

  • :package: --no-filter now disables all filters (including NoMedia)

  • :package: The server dockerfile no longer specifies VOLUMEs

  • :package: Changed the default for ffmpegHwaccel from auto to disabled. Docs suggested that auto would be safe, but in practice some platforms (like macOS) throw errors. Feel free to try it out on your box, but don’t be surprised when it doesn’t work… :disappointed: (see this forum post)

  • :package: The config, library, and cache dir now remove rwX from Group and Other to help with security.

  • :package: main now runs health checks on the web service every minute, and the sync service every 15 minutes, just to reduce system load.

  • :package: maxSyncFileJobs and sharpThreadsPerJob can be overridden (if cpuLoadPercent doesn’t do what you want).

  • :package: .cache directory cleanup is more efficient now (the prior implementation could get “stuck” if concurrent writes happened during sync)

  • :sparkles:/:package: logcat now reads from stdin when no filenames are provided.

  • :package: The libraryPath/PS_LIBRARY_PATH setting has been renamed libraryDir/PS_LIBRARY_DIR. This matches all other directory settings. An alias was added for backward compatibility.

  • :package: Added new remoteFilesystemTypes that defaults to sshfs and s3fs (note that non-FUSE filesystems are already handled properly)

Installation instructions and other details

Setup instructions are the same as prior beta releases. See:

https://forum.photostructure.com/t/version-1-0-0-beta-3-reporting-for-duty/615

3 Likes

Seems that the tag rendering isn’t quite fixed on my larger test library (note the “/var/var/…” paths:

I’ll fix this asap.

Hooray.

On one of my Macs I’m getting “Cannot set service name twice” on startup of the new app version (manual download from the website, not an update in place from beta.9). I’ve deleted the application and reinstalled. But still getting this. Any tips?

Crap, I’ll try to reproduce this on my mac now. What version of macOS are you running, and is it a intel or m1 box?

Edit: reproduced and fixing it now.

Releasing beta.11 now with this fix.

Note that there’s no substantive difference for server builds between beta.10 and beta.11.

1 Like

OK, verified that beta.11 launches and syncs on macOS, Linux, and Windows.

There are three issues I’m aware of:

  1. There’s an issue with Sentry not initializing properly. This shouldn’t be user-visible, but if there are errors, they don’t get reported

  2. The prior library path isn’t being transferred over. I know what’s going on, and I’m fixing it.

  3. The signal lights on macOS got droopy:

image

On Windows 10 desktop beta 9, I did the check upgrade and it successfully upgraded to beta 11. After the upgrade PhotoStructure did not automatically start; I don’t know if it should.
After starting the program I went to Help/About… and the About window displayed “Error Internal Server Error” I closed the window and opened About again and normal information displayed

Crap. If you restart PhotoStructure, is this reproducible as the first view of the about page?

In first start-up of the program, it automatically started and did some minor syncing but the About window initially displayed with Internal error mentioned above…

I shut down Windows 10 desktop beta 11 and then restarted the program. This time I was asked to login to my account again and select the PhotoStructure library (the default library location was shown and selected and I had to change the library to where my library is located) All photo locations were correctly shown. Once I had logged in and library location selected, it worked correctly with no obvious syncing etc. The About window showed correctly.

Thanks for those details! If you could send me your logfiles, hopefully they’ll have the error from the about page.

Right: I know what’s going on there, and I’ve fixed it in beta.12.

Don’t know if I caused this or not, but figured I would mention it.

Had loaded beta.10… had it rebuilding (slow) my database.

Then 11 came I and I thought “why not”, so I updated to 11.

It went through the “welcome” and “settings” screen instead of just starting. Had all my data and after clicking through it picked up where it had been and seems to have finished just fine.

This is a docker running on unRaid.

So… short version - when should you see the welcome screen?

Had the same (also unRIAD) and it did give me a scare, I am on Plus so needed to get the code but after that all good.

Just another data point… I am on Unraid and went directly from 9 to 11 without the issue you describe.

The welcome screen shows if there isn’t a prior library path set.

Unfortunately, the settings migration script had a bug that didn’t migrate that one setting… I’ve patched it in beta.12: PhotoStructure | 2021 PhotoStructure release notes

:bug: Prior-to-beta.10 library paths were ignored by beta.10 and beta.11. This meant if you upgraded to beta.10 or beta.11 you’d have to re-select your library.

Sorry about that!

I found another bug in beta.10/beta.11: I refactored the settings configuration code in beta.10, which can cause this issue:

Error: code ENOENT: ENOENT: no such file or directory, open '/ps/config/PhotoStructure/settings.toml'

The prior behavior defaulted writing settings directly into /ps/config, but beta.10/11 wants to write to /ps/config/PhotoStructure.

This will be fixed in beta.12: sorry for the inconvenience!

Since latest beta, the new ps gen paths are fine, but source paths have initial slash doubled, like

//[var](http://10.111.10.100:1787/tag/fs/var)/[photos-backup](http://10.111.10.100:1787/tag/fs/var/photos-backup)/[MacPro](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro)/[Pictures](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures)/[macpro.wend](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend)/[Aperture Library.aplibrary](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary)/[Masters](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary/Masters)/[2012](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary/Masters/2012)/[156_PANA_2](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary/Masters/2012/156_PANA_2)/P1560757.JPG

First - thanks for the update!

I am a noob with docker but here is my experience, probably self-inflicted – I edited my run (terminal/cli) bash script from beta 9 to 11, and ran it. it took me thru the welcome and login, verify, then the settings. i was lazy and just clicked ‘manual’ on where to scan but did not fill in all of the various places that I had entered previously… I will check later to see if it actually re-used my previous settings or not.

It did remember my previous file paths, and picked up the new photos I added today. thanks!

Apologies: I’ll get this fixed in beta.12 and try to get that released tonight or tomorrow.

Nope, it was me-inflicted, apologies!