mitchell/hamlab
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 14 Wiki Activity

PLAN.md: previews are cached in thumbs.db

Browse Source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Mitchell-Johnson
2026-10-11 16:05:17 -07:00
co-authored by Claude Fable 5.1
parent e198471f8c
commit e5d3fb2afd
1 changed files with 14 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PLAN.md
+14 -7
View File
@@ -652,16 +652,23 @@ something long in one, switch away and back, refresh — it's all still there.
0.7 s on the CPU; the 8K Osmo HEVC 1.0 s against 2.9 s. `grid`'s two GPUs are listed in 0.7 s on the CPU; the 8K Osmo HEVC 1.0 s against 2.9 s. `grid`'s two GPUs are listed in
node order and both decode the same set (h264, hevc, vp9, mjpeg, mpeg2 — **no AV1 on node order and both decode the same set (h264, hevc, vp9, mjpeg, mpeg2 — **no AV1 on
either**, per vainfo, so AV1 is dav1d on the CPU). either**, per vainfo, so AV1 is dav1d on the CPU).
- **Cached under the machine's data dir**, `<data dir>/thumbs/<xx>/<sha256>.jpg`, keyed by - **Cached in one database file under the machine's data dir**, `<data dir>/thumbs.db`
path, size and mtime — a changed file gets a new preview, an unchanged one is never (bbolt — pure Go, so the binary stays static; v0.1.0-202, the first build kept them as
decoded twice, and the URL carries `v=<mtime>-<size>` so the browser's own cache is a tree of hash-named JPEGs under `thumbs/`, replaced the same day when Mitchell asked
right too (7 days, ETag, 304). A file ffmpeg could not decode is remembered beside the where they were kept: "stored in hamlab, maybe under a DB, up to you"). An entry is
JPEGs as `.err` with ffmpeg's reason, answered as 422, and retried only when the file keyed by path, size and mtime — a changed file gets a new preview, an unchanged one is
changes; a timeout is not remembered. Nothing expires: a preview is a few KB, and only never decoded twice — and carries the engine, codec, source size and time beside the
picture; a count rides in the file so the previews button's tooltip can say "N kept
(M MB)" without walking anything. The URL carries `v=<mtime>-<size>` so the browser's
own cache is right too (7 days, ETag, 304). A file ffmpeg could not decode is kept with
ffmpeg's reason and no picture, answered as 422, retried only when the file changes; a
timeout is not kept. A miss never creates the file, so a machine nobody browses with
previews on never has one; a cache that cannot be opened is logged and previews are
still made and served, just not kept. Nothing expires: a preview is a few KB, and only
files somebody scrolled past are ever made. At most 2–4 ffmpegs at once per machine files somebody scrolled past are ever made. At most 2–4 ffmpegs at once per machine
(half the cores, clamped), one per file however many rows ask, and a preview's work (half the cores, clamped), one per file however many rows ask, and a preview's work
runs on a clock of its own so the row that asked first leaving does not cancel it for runs on a clock of its own so the row that asked first leaving does not cancel it for
the rest. Each ffmpeg runs under `nice -n 10`. `hamlet`'s backup job skips the folder. the rest. Each ffmpeg runs under `nice -n 10`. `hamlet`'s backup job skips the file.
- **Root mode makes them as root** (`hamlab thumb`, the sibling of `hamlab fs`, caps on - **Root mode makes them as root** (`hamlab thumb`, the sibling of `hamlab fs`, caps on
stdin, JSON out), so a file only root can read gets a preview, and the probe runs as stdin, JSON out), so a file only root can read gets a preview, and the probe runs as
root too — root opens every render node whatever groups the daemon has. Which matters: root too — root opens every render node whatever groups the daemon has. Which matters: