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,42 @@
+# REPORT — 2026-10-14: the estimator's raised figures published (R-1009 = A); Immich can rebuild single photos (R-1007)
+
+Times UTC. Baseline felhom.eu `65493fc4`. Read first: `audits/sizing-2026-10-13/SIZING.md` §5 and
+`audits/sizing-check-2026-10-14/CHECK.md` (the estimator); `audits/power-cut-fixes-2026-10-14/README.md` F (Immich).
+No release; no controller, agent, hub or catalog change. No key, token or password in any file.
+
+## 1. The page — live
+
+- The tool change applied as its own commit (`3f7f26a7`, the waiting patch unchanged). Data rebuilt (`54112954`):
+  23 figures up, none down; `build_sizing_web.py --check` OK; `test_build_sizing_web.py` 14/14 after its expected values
+  moved with the rule (the one verdict, the household peak 6,021, the bar).
+- **The one stricter answer:** the household set without Immich on 8 GB — fits well → fits, but tight (2,731 × 1.5 =
+  4,096.5 > 4,096 MB). `SIZING.md` §5 table, bullets, memory table and the dated line updated; the five largest peaks too.
+- Lede, meta description and method note (HU + EN) name both machines (N100 and HP t740, 13–14 October 2026). Data `?v=4`.
+- **Read-back** (live files; verdicts by the test's copy of the page rule — no browser on DooPlex): the live
+  `sizing-data.json?v=4` is byte-equal to the commit. „Family starter set" (no / tight / well …) and „Just files and
+  passwords" (well everywhere) keep their verdicts; Immich alone on 8 GB is still „tight"; only the set without Immich
+  changed (`audits/sizing-check-2026-10-14/live-readback.txt`).
+- https://felhom.eu/gepigeny and https://felhom.eu/en/sizing. R-1009 closed.
+
+## 2. Immich — yes, it rebuilds single photos
+
+- Ruling recorded in R-1007: after an unclean boot, rebuild only the broken photos, run the missing-files check, tell
+  the operator about lost originals; no „thumbnails: all".
+- The running v3.2.4 answers `POST /api/assets/jobs {assetIds, name: "regenerate-thumbnail"}` (read from its own 400
+  reply and its server code).
+- 10 broken assets (5 empty thumbnails, 5 empty previews), found from the disk alone; repaired in **1.55 s, 5.3 s CPU**.
+  The other 20 photos: **0 of 40 files rewritten**; the positive control („all") rewrote 40 of 40.
+- An empty file maps to its asset: the first 36 characters of `thumbs/<user>/<aa>/<bb>/<asset id>_thumbnail.webp`.
+- **Next step (R-1007):** build a per-app after-unclean-boot hook that finds the zero-byte files under `thumbs/`, calls
+  that endpoint for those ids only, runs `integrity-missing-files`, and tells the operator about lost originals.
+- Counts note: the task named „5+5", „10 assets" and „the other 25"; with 30 photos those do not all hold. I damaged 10
+  different assets, which left 20 as the control.
+- Teardown: Immich removed through the product on 9202; no folder, container, volume or image left; 9202's standing apps
+  untouched. Nothing on 9201, Tester 1 or the N100. Host and hub: nothing made.
+
+## 3. Record
+
+- Commits: felhom.eu `3f7f26a7`, `54112954`, and this one.
+- Register: **134 before → 133 after; opened 0; closed 1** (R-1009). R-1007 updated (ruling + answer + next action).
+- STATUS.md: 45 lines; D9 and D10 left the decide table (both ruled).
+- Fixed without a row: none. System poster: no listed fact changed.
@@ -9,7 +9,7 @@
 - A power cut in the middle of a backup no longer blocks later backups: the box removes the half-written backup at start-up (proven with a real cut on demo-hp, on all three boxes now).
 - A household can switch the machine off; the hub holds alarms for 14 days and clears the state by itself (N100).
 - A real power cut on demo-hp: it started by itself after all 8 cuts of the night (with the BIOS set), every app back in ~4 min; stale and recovered mails true and paired.
- The machine estimator is public (/gepigeny, /en/sizing); sizing measured for 61 apps on the N100.
+- The machine estimator is public (/gepigeny, /en/sizing), with figures from two machines (N100 and HP t740; raised only, 2026-10-14).
 - 62 apps in the catalog, the Usenet and torrent clients included. OS updates, the kernel lane too, run at night.
 - The hub is closed again after the 2026-10-12 security review; one box cannot read another's data.

@@ -18,10 +18,10 @@
 - DooPlex: a failed disk with its alarms silenced (R-934); CI jobs still get lost (R-887); something sets the shared
  checkout to „bare" (R-935); a Longhorn volume at 91 %.
 - Tester 2 has never made an off-site check (R-862). The scratch box cannot read the drill catalog (R-992).
- After a power cut: Immich keeps photos with empty previews or no original until its own repair job runs (R-1007, your decision).
+- After a power cut: Immich keeps photos with empty previews or no original; your ruling „fix only the broken photos" is shown to work (Immich rebuilds single photos) — the build is a later task (R-1007).

 ## What we work on
- The power-cut findings still open (R-1004, R-1005, R-1007, R-1010, R-1012, R-1013) and the estimator figures (R-1009, your choice).
+- The power-cut findings still open (R-1004, R-1005, R-1007, R-1010, R-1012, R-1013) and the Immich repair build (R-1007).

 ## Waiting on you — decide

@@ -35,8 +35,6 @@
 | D6 | R-992 | The scratch box cannot read the private drill catalog: give it a read-only login, or make that copy readable? | **A read-only login** | Readable copy: the drill catalog becomes public | every new-app test needs hand-staging | new-app tests |
 | D7 | R-990, R-989 | Rule yes / no / later on the forum ideas (`audits/forum-research-2026-10-12/FELHOM.md` §5) and the selfh.st ideas (`audits/selfhst-survey-2026-10-12/FELHOM.md` §6) | — | — | nothing changes; the research ages | — |
 | D8 | R-206 | Install DooPlex's Docker settings from git (restarts Docker), and prune the build cache weekly: yes or no? | **Yes, in a quiet window** | — | a rebuild of DooPlex still has the settings in git | — |
-| D9 | R-1007 | After an unclean boot, should Immich run its own repair: the „missing files" check (report a lost photo) and „thumbnails: all" (fix empty previews) in the night window? | **Yes** | CPU in proportion to the library (a big one: hours, at night) | broken previews stay; a lost original stays unnoticed | — |
-| D10 | R-1009 | The „raise only" estimator update changes ONE verdict: 5 apps without Immich on 8 GB, fits well → tight (0.5 MB over). Publish anyway (A), round down first (B), or keep today's figures (C)? | **A** — the page stays truthful, one line reads stricter | B: one rule sentence, may still flip; C: nothing | the page keeps today's figures; Immich, Jellyfin, Home Assistant, Paperless read low | — |

 ## Waiting on you — do
 - **N100 BIOS:** read „After Power Loss" (the HP's „Previous State" made it start after 8 of 8 cuts). **HP BIOS:** „Bypass F1 Prompt on Configuration Changes" → Enable.
@@ -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 |