1.0.0-beta.4 is ready!

Update: 1.0.0-beta.4 was released on 8 June, 2021

Display improvements

  • :sparkles: Tag gallery thumbnails now have a captured-at title (hover over photos to
    see when they were taken).

  • :sparkles: Video assets in galleries now show a duration (the video icon wasn’t added in the final version, though, in an effort to reduce the number of DOM elements on the page and get Firefox to render faster)

  • :bug: Mobile displays sometimes showed blank grey rectangles at the bottom of child tag galleries:

    This was due to both incorrect algebra (apologies to my junior high school math teachers), and an incorrect media query (remember to wrap matchMedia in parenthesis!), and is now fixed:

Other updates:

  • :sparkles: JSON Takeout sidecars for images ending in -edited or -1 are now paired properly.

  • :sparkles: Better crash recovery: irreparable SQLite replicas found in the cache directory are now replaced with the primary database automatically.

  • :bullettrain_front:/:package: Tag asset counts in prior versions were updated monolithically (every tag’s asset count was recomputed every 5 minutes during syncs). This approach is reasonably fast for smaller libraries, but for larger (200k+ asset files) libraries (especially not stored on SSDs), these queries could take > 30 seconds, which had a large performance impact on filesystem synchronization.

    Tag asset counts are now updated incrementally, and the update query itself has been improved as well (even with very large libraries, incremental tag counts take under 1 second with the new code).

  • :bullettrain_front:/:package: Images on all browsers that aren’t Safari now use lazy loading. This helps improve the page load time on full-screen 4k displays, but Chrome is still instantaneous, and Firefox takes seconds (at least on Linux).

  • :sparkles:/:package: De-duplication improvement by adding MetadataDate to the default set of captured-at tags.

  • :bug: Restored PhotoStructure’s periodic sync job

  • :bug: Docker license validation errors and should be fixed now. Apologies if you saw this!

  • :bug: PhotoStructure no longer looks for sidecar metadata for files within .photostucture directories

  • :package: SQLite backups now try to use the backup API, and if that fails, tries the new VACCUM INTO command.

  • :package: Docker users: A UMASK environment variable, if set, will be given to umask during startup. The default is 0022 which removes “group” and “other” write permissions. You may want a more restrictive 0027 which removes read access to “other”.

1 Like

Great! Nice work. Love the frequent releases. Don’t burn yourself out :wink:

Assuming github will be updated soon with beta 4

1 Like

When will it be pushed out to the app “Check for updates” utility? Should it be there by now? I’m on beta3 and it says I have the latest version. (Super excited about this update!)

I mentioned this on Discord, but I’m embarrassed to admit I published this topic as “unlisted,” thinking “unlisted” meant “draft”.

beta.4 needs more tests and then I have to fight the Continuous Integration Monsters to get all the lights back to green, and then I’ll release.

Sorry for the pre-emptive post!

1 Like

Haha, no problem! I don’t have the time to be on Discord, otherwise I would’ve caught that. I figured something was up. Thanks!

Monsters: vanquished

1,426 fe tests
4,219 core tests
853 library tests


1.0.0-beta.4 (PhotoStructure for desktops) is installed and working for me on Windows 10 (10.0.19043) on x64.

At first it said I was running the lite version after the upgrade. I requested a verification code, but it still said I was running lite version. I restarted photostructure and now it’s working great.

I like the new “hover over photos to see when they were taken” feature. Great job!

Sorry about that licensing hiccup: if you still have debug or info logging enabled, can you send me your logs?

Also, just saw that the file drop-down in the info panel isn’t rendering, so I’ll get that fixed and push beta.5 shortly.

I’m excited for you that 1.0.0 is imminent!

in 1.0.0-beta.4, when I display the info panel for an asset (screenshot 01) and click on the three-dots button for an asset, the three-dots turns into an “x” and I don’t get the menu to have any options like “download asset” (screenshot 02).

Oh crap, I see that. I’ll get that fixed asap.

OK, just released beta.5 with that bug fixed.

Note that I’ll be offline for the next several days.

Update: the update doesn’t have seem to have fixed the bug (I’d reproduced it on my own library running node, changed the dropdown slot rendering, rebuilt, and it worked, honest, so… there’s something else going on here). I’ll fix this next week.

I was running Windows 10 Desktop 1.0.0-beta 3. I used the"Check for updates" in the right click of the system tray icon. This said there was an update available which I accepted. It seemed to download and PhotoStructure closed but the program was not automatically updated and started.

I could not easily find the beta 4 version. I then finally downloaded the program from PhotoStructure | Install PhotoStructure which I guessed from an earlier “alpha” bookmark. (BTW I did find another copy of the beta 4 on my computer downloaded from the "check for upgrades”)

When I ran the beta 4 install program, everything went to plan and no obvious re-sync/rebuild was undertaken.

I believe it the install upgrade for the Windows Desktop should install and then run PhotoStructure.

Upgraded to beta5 (sorry, posted to beta.4 thread by mistake). Initial (re)scan after startup is still going on, but i see that logs have a rather high number of these errors, all alike:

2021-06-09T22:40:54.308Z sync-519 warn  Error onError(): Error: DbRequest {"method":"all","sql":"WITH RECURSIVE ancestors(id) AS ( SELECT tagId FROM ChangedTag UNION SELECT Tag.parentId FROM Tag, ancestors WHERE Tag.id = ancestors.id ) SELECT id FROM ancestors"}: DbRequest {"error":{"stack":["SqliteError: no s…
Error: prep() failed
    at Object.t.asError (/ps/app/bin/sync.js:9:566668)
    at v.throw (/ps/app/bin/sync.js:9:340010)
    at t.DbRequest.prep (/ps/app/bin/sync.js:9:651968)
    at /ps/app/bin/sync.js:9:652112
    at Function.<anonymous> (/ps/app/bin/sync.js:9:672996) { event: 'nonFatal', message: 'unhandledRejection' }

I trust that it is “nonFatal” - UI is definitely not complainint about anything. This is just something I havent seen before

Also spotted this (sorry, this is also beta.5, not beta.4 - i missed the right place to post this):

2021-06-09T23:59:59.494Z sync-25340 error DbRequest Error: DbRequest {"error":{"stack":["SqliteError: no such table: ChangedTag","    at Database.prepare (/ps/app/node_modules/better-sqlite3/lib/methods/wrappers.js:5:21)","    at /ps/app/bin/sync.js:9:651814","    at p.getOrSet (/ps/app/bin/sync.js:9:4925…
Error: prep() failed
    at Object.t.asError (/ps/app/bin/sync.js:9:566668)
    at v.throw (/ps/app/bin/sync.js:9:340010)
    at t.DbRequest.prep (/ps/app/bin/sync.js:9:651968)
    at /ps/app/bin/sync.js:9:652112
    at Function.<anonymous> (/ps/app/bin/sync.js:9:672996) { method: 'all',
   'WITH RECURSIVE ancestors(id) AS ( SELECT tagId FROM ChangedTag UNION SELECT Tag.parentId FROM Tag, ancestors WHERE Tag.id = ancestors.id ) SELECT id FROM ancestors' }

I had many issues getting PS for Docker Compose to work reliably - when creating the initial library or doing upgrades it would miss running one or other migration sql script, causing the database to have missing tables or foreign keys and such. Tried a number of times and it was inconsistent, like the sqlite database didn’t like being mapped through to the underlying host disk.

Not saying this is the cause of that problem necessarily but just my experience.

Gave up on Docker and went to Node, no problems like that since.

At least on linux, there is really no IO mapping, right? Containerized process runs directly on the host (under restricted capabilities), so there is really not that much real difference between running a container and running Node version.

I’m afraid I broke the docker image for a bunch of functionality due to a mistake I made that caused libc tools to get cooked into a musl image. I’ll be back at my desk tomorrow and fix this issue first this in the morning.

Sorry to you both (and anytime else) for the bother!

This has been fixed in beta.6

@wooskey is this still an issue for you with beta.9?

(My personal library that had this issue was fixed with beta.8, but I didn’t want to assume we were suffering from the same issue)