admin
3e2bdda721
gates / gates (push) Successful in 6m46s
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
3.2 KiB
3.2 KiB
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 --checkOK;test_build_sizing_web.py14/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=4is 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, runsintegrity-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.