120 mule-images: Phase 3 — extract_metadata via Memories HTTP API
Tries Memories /api/image/info/{fileid} first (OCS-APIRequest header
bypasses CSRF), falls back to ExifTool on 404 / non-NC / errors.
Kept the full date-fallback chain because 35% of the library uses
filename-encoded dates that Memories doesn't recover.
This commit is contained in:
@@ -120,7 +120,9 @@ Verified end-to-end on `Photos/MuleTestFolder/{test1,test2,nested/test3}.jpg`: `
|
||||
|
||||
**asyncpg gotcha**: the original implementation of `handle_directory_rename` used raw SQL with `SUBSTRING(filepath FROM LENGTH(:old_prefix) + 1)` so the offset would be computed server-side. asyncpg's type inference miscategorises the `LENGTH()` result and rejects the parameter as "$2: int (expected str)". The fix iterates in Python (same pattern as the existing PATCH endpoint). Lesson: avoid passing `LENGTH(:x)+1` as an argument to `SUBSTRING(...)` via asyncpg + sqlalchemy `text()`.
|
||||
|
||||
**Open: Phase 3.** Enable the Nextcloud Memories app (currently installed but disabled) and read `taken_at` / `lat` / `lon` / `w` / `h` from `oc_memories` instead of running mule's own `extract_metadata`. Keep pHash + file_hash for dedup. When that lands, the vision worker can also stop needing on-disk medium thumbs and the whole `/data/thumbs` pipeline retires.
|
||||
**Phase 3 — Memories-backed `extract_metadata` (commit `2a5759c`).** Memories app re-enabled on NC. `extract_metadata` now tries `GET /index.php/apps/memories/api/image/info/{fileid}` (auth: Basic + `OCS-APIRequest: true` header to bypass CSRF) before falling back to ExifTool. Replaces ~80 ms of subprocess with ~1-2 ms HTTP for ongoing imports. New helpers: `nextcloud_dav.fetch_memories_info_async()` + `metadata._apply_memories_metadata()`. We kept mule's full date-fallback chain (SubSec → DateTimeOriginal → CreateDate → MediaCreateDate → TrackCreateDate → filename heuristic → mtime) because 35% of the library (`taken_at_source='path'`) depends on the filename heuristic, and Memories alone would silently mis-date those photos to mtime. PhotoInfoPanel reads `exif.Make/Model/ISO/FNumber` from `photos.exif_json` — Memories' `exif` blob uses those exact plain key names, so no frontend adapter was needed. ExifTool subprocess is still in place as the fallback for brand-new photos racing the NC scan, non-NC photos, and any NC HTTP failure.
|
||||
|
||||
**Remaining open: vision worker still on disk.** It still loads `medium.webp` from `/data/thumbs/{user}/{photo_id}/`. Once vision moves to NC previews (or decodes `/proxy` in-memory), `WORKER_THUMB_SIZES` drops to empty and the local thumb pipeline retires entirely.
|
||||
|
||||
### 2026-05-11 — Duplicates view shows parent folder + full-path tooltip
|
||||
|
||||
|
||||
Reference in New Issue
Block a user