R-1009 closed (estimator live, read back); R-1007: the operator's ruling recorded, and Immich v3.2.4 rebuilds single photos

Read-back: live sizing-data.json?v=4 byte-equal to the commit; the presets keep their verdicts, Immich alone on 8 GB still tight; only the set without Immich changed. Spike B2 on 9202: POST /api/assets/jobs regenerate-thumbnail rebuilt exactly the 10 broken assets (1.55 s, 5.3 s CPU), 0 of the other 20 photos' 40 files rewritten (control: all rewrote 40 of 40); an empty file maps to its asset by the first 36 characters of its name. Immich removed through the product, no leftovers. Register 134 -> 133 (opened 0, closed 1). STATUS D9/D10 ruled. Claude-Session: https://claude.ai/code/session_012qRErfCoiTkvDK9N5XHbzb
2026-10-14 15:40:23 +02:00
parent 541129542d
commit 3e2bdda721
8 changed files with 125 additions and 8 deletions
@@ -0,0 +1,29 @@
+assets: 30
+== path layout (one asset):
+thumbs/8b6e9d61-4727-4f6f-acc8-9cbd34b9e17c/b6/43/b6439ff3-bf84-4a36-abea-83be61c39ceb_thumbnail.webp
+thumbs/8b6e9d61-4727-4f6f-acc8-9cbd34b9e17c/b6/43/b6439ff3-bf84-4a36-abea-83be61c39ceb_preview.jpeg
+   thumbs files: 61; kinds:       1 .immich      30 preview.jpeg      30 thumbnail.webp 
+== 13:35:43 damage: assets 1-5 thumbnail -> 0 B, assets 6-10 preview -> 0 B
+== 13:35:45 found from the DISK only (zero-byte files -> asset id = the first 36 characters of the name):
+   250f3daa-97cd-4995-8e36-4106a000ee97_thumbnail.webp
+   3bf485a3-ce9c-4a97-a403-d79d28f01d73_preview.jpeg
+   7cc1da19-4414-4ccf-9625-1193ddcdb050_preview.jpeg
+   85552913-9900-487f-84eb-fe5839cc7df9_thumbnail.webp
+   a57b10e1-a7b1-474f-8782-462b747228c1_thumbnail.webp
+   ad2c19a0-26b3-4a26-8291-00a375f98515_preview.jpeg
+   b6439ff3-bf84-4a36-abea-83be61c39ceb_thumbnail.webp
+   ca86f976-4624-42c0-b800-34e8372f485f_preview.jpeg
+   f807f803-2042-46cc-ae47-e8a27277f022_preview.jpeg
+   fc6ca10a-e9ee-45dc-ac4a-73de7db40bac_thumbnail.webp
+   broken assets: 10
+   API before: 0/208760 5630/0 5856/0 0/194665 0/194607 6246/0 0/203683 5720/0 6022/0 0/198427 
+== 13:35:48 POST /api/assets/jobs regenerate-thumbnail for the 10 broken assets -> 204 
+   zero-byte files left: 0; all files non-empty after 1.55 s; queue idle after 16.85 s; CPU (all immich containers) 5340 ms to non-empty, 5828 ms to idle
+   API after: 6698/208760 5630/197443 5856/193665 5858/194665 5882/194607 6246/201464 6398/203683 5720/199228 6022/204622 5964/198427 
+   files of the 10 broken assets: 20, rewritten 20, empty after 0
+   files of the other 21 assets: 41, rewritten 0  <- must be 0
+   new files: []; gone: []
+== 13:36:05 positive control: thumbnails ALL (force=true) must rewrite the other assets' files
+   PUT -> 200
+   files of the other assets rewritten by ALL: 40 of 41
+   ALL: queue idle after 18.21 s; CPU 16488 ms (30 assets)
@@ -0,0 +1,8 @@
+15:37:20   immich: stop 200, remove 200, deployed=False, leftovers=''
+True
+left: 0 dirs
+containers: felhom-controller paperless-webserver paperless-postgres paperless-redis filebrowser traefik 
+immich volumes: 0
+immich images: 0
+
+["15:37:20   immich: stop 200, remove 200, deployed=False, leftovers=''"]
@@ -116,6 +116,34 @@ hook and CPU in proportion to the library; a missing original then needs a resto
 done: broken previews stay until someone forces a regeneration by hand; a lost original stays unnoticed.


+## B2 — can Immich rebuild single photos? (R-1007, after the operator ruling „fix only the broken photos", spike only)
+
+Immich v3.2.4 on scratch guest 9202, deployed and removed through the product; 30 bench photos (`B2/`).
+
+**What the running server answers** (asked, not remembered): `POST /api/assets/jobs` with a bad body → 400 listing the
+names `refresh-faces`, `refresh-metadata`, `regenerate-thumbnail`, `transcode-video`; body `{"assetIds": [<uuid>…],
+"name": "regenerate-thumbnail"}`, permission `AssetUpdate` (an admin or the owner's key). In the server code
+(`dist/services/asset.service.js` `run()`): one `AssetGenerateThumbnails` job per id given — nothing else is queued.
+
+**Path layout:** `<upload>/thumbs/<user id>/<a[0:2]>/<a[2:4]>/<asset id>_thumbnail.webp` and `…_preview.jpeg` (+ one
+`.immich` marker file). **Mapping an empty file to its asset:** the first 36 characters of the file name ARE the asset
+id. A box finds the broken photos from the disk alone: `find <upload>/thumbs -type f -size 0`, cut the names to 36
+characters, unique.
+
+| Step | Result |
+|---|---|
+| damage | assets 1–5: thumbnail → 0 B; assets 6–10: preview → 0 B; the API served the 0-byte files |
+| found from the disk | 10 zero-byte files → 10 asset ids (the mapping above) |
+| `POST /api/assets/jobs regenerate-thumbnail` for those 10 | **204**; no zero-byte file left after **1.55 s**; queue idle after 16.9 s (5 s polling); **CPU 5.3 s** (all Immich containers, cgroup `usage_usec`) |
+| the 10 assets | all 20 files rewritten (the undamaged sibling too), none empty; the API serves real thumbnails and previews |
+| the other 20 assets | **0 of 40 files rewritten** (mtimes before/after) |
+| positive control: thumbnails „all" (`force=true`) | rewrote **40 of 40** of those same files (the 41st counted file is the `.immich` marker); CPU 16.5 s for 30 photos |
+| teardown | Immich removed through the product; no folder, container, volume or image left; 9202's standing apps untouched |
+
+**Answer:** yes — v3.2.4 rebuilds single photos. Cost ≈ 0.5 s CPU per photo here (a family library with 80 broken photos,
+like the night's R2: well under a minute) against „all" in proportion to the whole library. A lost original is still
+found only by `integrity-missing-files` and restored only from a backup.
+
 ## E — the live proof on demo-hp (agent 0.156.1 + bundle, delivered by signed jobs)

 Vouched by the operator 2026-10-14 (read back from `/configuration`): agent 0.156.1 `83c7da27…`, golden 0.310.0 `2110d5e4…`,
@@ -0,0 +1,7 @@
+Live read-back 2026-10-14, https://felhom.eu/gepigeny and https://felhom.eu/en/sizing; data sizing-data.json?v=4 (sha256 equal to the commit).
+Presets read from the live page; verdicts by the page rule (scripts/test_build_sizing_web.py estimate(), mirrors sizing.js).
+Columns [8, 12, 16, 24, 32, 48, 64] GB
+Family starter set: peak 5515 -> 6021 MB | before ['no', 'tight', 'well', 'well', 'well', 'well', 'well'] | now ['no', 'tight', 'well', 'well', 'well', 'well', 'well'] | SAME
+Just files and passwords: peak 1094 -> 1094 MB | before ['well', 'well', 'well', 'well', 'well', 'well', 'well'] | now ['well', 'well', 'well', 'well', 'well', 'well', 'well'] | SAME
+Immich alone: peak 3531 -> 3760 MB | before ['tight', 'well', 'well', 'well', 'well', 'well', 'well'] | now ['tight', 'well', 'well', 'well', 'well', 'well', 'well'] | SAME
+Family set without Immich: peak 2454 -> 2731 MB | before ['well', 'well', 'well', 'well', 'well', 'well', 'well'] | now ['tight', 'well', 'well', 'well', 'well', 'well', 'well'] | CHANGED
@@ -26,6 +26,12 @@

 ---

+## 2026-10-14 — the estimator takes the second machine's figures, raise only
+
+| Row | What | Closed | Evidence |
+|---|---|---|---|
+| **R-1009** | **Operator: decide whether the machine estimator's figures move with the 2026-10-14 check on a second machine** (P3) | CLOSED 2026-10-14 — operator ruling A: raise only. 23 figures up, none down (Immich peak 3,061 → 3,290; Jellyfin, Home Assistant, Paperless-ngx, Grimmory, 18 small). One verdict stricter: the household set without Immich on 8 GB, fits well → fits, but tight (2,731 × 1.5 = 4,096.5 > 4,096 MB). Live on https://felhom.eu/gepigeny and https://felhom.eu/en/sizing (data `?v=4`, byte-equal to the commit); read back: „Family starter set" and „Just files and passwords" keep their verdicts, Immich alone on 8 GB still tight. **Reasoning kept:** the second machine can only raise a figure, never lower one (operator ruling) | felhom.eu `3f7f26a7` (tool), `54112954` (data + pages); `audits/sizing-check-2026-10-14/live-readback.txt` |
+
 ## 2026-10-14 — a box clears up after a power cut mid-backup

 | Row | What | Closed | Evidence |