PhotoHub - v0.16.13

PhotoHub 0.16.13

• Resync the vendored morfUpdate (0.8.6).

PhotoHub - v0.16.9

PhotoHub 0.16.9

• Vendored morfDeploy 0.21.0. An update now brings the installed config fully up to the example: new keys also reach modules already present (matched by id), documentation comments follow the example, and keys a version declares in removed_keys (service.json) are deleted after a backup.

PhotoHub - v0.16.8

PhotoHub 0.16.8

• scripts/sync-morf.sh / .ps1 no longer resynced morfBeacon. Their header still said PhotoHub embedded only morfUpdate, although it vendors morfBeacon since it announces its presence; morf doctor then reported a drift the script could not repair. The shell script is now the parc's generic one (beacon, update, morfdeploy) and the PowerShell one syncs beacon and update.
• Re-vendored morfBeacon to 0.7.2 (documentation-only release; include/ and src/ unchanged).
• Re-vendored morfUpdate to 0.8.2 (vendoring-only release; include/ and src/ unchanged).

PhotoHub - v0.16.5

PhotoHub 0.16.5

• Resynced vendored morfUpdate to 0.8.0 (opt-in self-update, stage 2). No behaviour change in this application: the affected code is the update agent, which desktop apps do not run.

PhotoHub - v0.16.3

PhotoHub 0.16.3

• Resynced vendored morfUpdate to 0.6.0. The "Check for updates" dialog now picks the release asset matching the running OS and CPU architecture (the Windows .zip, the arch-matched Linux .deb/.AppImage) instead of the first asset, which was often checksums.sha256. No API change.

PhotoHub - v0.16.2

PhotoHub 0.16.2

• Resync vendored morfBeacon to 0.7.1. Picks up the async /status reply fix: the beacon status server no longer blocks the event loop draining a reply to a slow client, so the heartbeat can no longer be starved (which produced false "service down" alerts across the parc). No API change.

PhotoHub - v0.16.1

PhotoHub 0.16.1

• The folder preview now shows a representative sample. It asks morfPhoto for a spread, RAW/JPEG-deduplicated sample (&sample=N) instead of the first N photos (&page_size=N). The first photos of a folder often follow one another - the same shot's RAW and JPEG, or a burst - which made the preview repetitive and unrepresentative. The sampling itself lives in morfPhoto (0.14.0).

PhotoHub - v0.16.0

PhotoHub 0.16.0

• The network assistant now generates share commands that match the "Source qualifiable" choice. Previously it always produced a read-only share (net share … /GRANT:<user>,READ … "lecture seule", and New-SmbShare -ReadAccess), which made qualification impossible even after checking the box. When the source is qualifiable, the assistant now:
• the manual net share line grants CHANGE (and its comment notes it must run in an elevated prompt - the cause of the "erreur système 5" when run un-elevated);
• the one-click "Créer le partage" elevated script grants Change (or creates the share with -ChangeAccess) and also grants NTFS Modify to the account (share and NTFS rights are ANDed; both must allow writes);

PhotoHub - v0.15.0

Source release for PhotoHub 0.15.0.

PhotoHub - v0.12.0

PhotoHub 0.12.0

• Folder preview in the context qualification screen: selecting a day shows a few thumbnails from that folder, so you can see what it actually contains before choosing the context. Thumbnails are served by morfPhoto (GET /api/v1/thumbnail, embedded preview via exiftool, JPEG and RAW) after fetching a sample of the folder's files (GET /api/v1/photos?directory=…). PhotoHub stays a pure client - it never reads the photo files itself, so the preview also works when morfPhoto and the photos live on another machine. Stale async responses are dropped when the folder changes.