From 0d310ab7b0b1126290f51722867213413de2c017 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sat, 29 Aug 2026 01:25:11 +0100 Subject: [PATCH] the file browser draws pictures, in both views MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit images and videos get a thumbnail in grid and list. one , two sizes — two implementations would have drifted the first time one learned something the other did not, and the fallback is the part that would have drifted. FFMPEG FOR BOTH, and no new dependency. a video needs a frame extracted, which only ffmpeg does; an image only needs resizing, which sharp does faster and with better format coverage. sharp is nevertheless not used: it sits in node_modules as somebody else's transitive dependency and is absent from package.json, so importing it is an undeclared dependency — the thing the frozen lockfile exists to prevent — and declaring it is a deliberate --no-frozen-lockfile that belongs to whoever owns the dependency list. ffmpeg is already a hard requirement of this router, so this adds nothing to what the machine must have. the cost is HEIC and a few exotics, which fall back to the icon. THE CACHE KEY CONTAINS MTIME AND SIZE. a path alone would be wrong: replace a photo under the same name and every screen keeps the old picture with nothing to clear it but somebody who knows the cache exists. keyed on content, a changed file is a different key — the old entry is orphaned rather than stale, and the response can be `immutable` honestly rather than as a bet. FAILURES ARE REMEMBERED. the browser retries a broken every time it re-enters the viewport, so without this one corrupt video runs ffmpeg on every scroll, forever. in memory, so a restart gives it another chance after somebody installs a codec. `ls` DECIDES what can be thumbnailed, not the client. the browser's own NATIVE_VIDEO_EXTS is deliberately only what a