3 Commits

Include renames

Author	SHA1	Message	Date
tfaour	c6dad191fb	Fetch headless Chromium at container startup instead of build time ... build-and-push failed on the last deploy: chromium-headless-shell's single ~181MB binary can't be split across Docker layers the way this project's pip/npm installs were (those are many independently- installable smaller packages; this is one file), and confirmed-failed to push past the registry's per-layer size limit. Moves the `playwright install chromium-headless-shell` step from the Dockerfile to start.sh, caching into PLAYWRIGHT_BROWSERS_PATH on the /data volume -- only the very first boot on a fresh volume downloads it, every boot after that is a no-op check. The image itself no longer grows by ~262MB, so nothing new gets pushed to the registry at all.	2026-07-31 02:18:36 +00:00
tfaour	1c67dd20d7	Auto-restart the whiteboard render sidecar if it crashes ... Root cause of "whiteboard stuck on old content, no errors anywhere": the Node sidecar had crashed at some point and, since it was just a bare backgrounded process with nothing supervising it, stayed dead permanently. Every refresh since then hit connection-refused, which get_or_refresh_whiteboard treats as a soft failure and falls back to the last successfully cached image -- so it looked exactly like a caching bug from the outside, silently, forever, with no error visible anywhere except a crash trace that had already scrolled out of the log buffer. Wrap it in a restart loop instead of a bare `&` so a future crash (a still-unknown third jsdom/Excalidraw edge case, most likely) is a few-second hiccup instead of a silent permanent outage.	2026-07-23 21:22:17 -04:00
tfaour	644fdefa66	Add whiteboard frame mode (Nextcloud Whiteboard / Excalidraw over WebDAV) ... New third mode alongside photos/calendar: fetches a .whiteboard file over plain WebDAV (Basic auth -- generic, not Nextcloud-specific) and renders it via a small Node.js sidecar using Excalidraw's own real export code (@excalidraw/utils + @resvg/resvg-js, no headless browser), since a .whiteboard file turns out to be Excalidraw scene JSON, not an image. The sidecar runs as a second process inside this same container (Dockerfile installs Node, start.sh backgrounds it before exec'ing uvicorn) rather than a separate docker-compose service -- lightweight, stateless, reachable only at 127.0.0.1 from the Python process, nothing worth independently scaling. The rendered PNG is treated exactly like a photo from there on -- composed/quantized through the existing image_pipeline (letterboxed, never cropped) rather than a second parallel rendering pipeline. WebDAV credentials support the common "it's actually the same Nextcloud account as my CalDAV" case (an explicit opt-in checkbox, not silently inferred) while still working with any WebDAV server generically. Frame-level source (URL + owning account) follows the same owner- controls-their-own-data permission split as calendar sources and the week view's task list: only the account owner can point a frame at it, anyone linked can clear it. Honest limitation: this environment has no Node.js/npm, so render-service/ is written carefully against each library's documented API (verified via the npm registry, including transitive dependency licenses after the CalDAV/AGPL surprise earlier this session) but has never actually been executed. First real docker build is the first true test -- see render-service/README.md.	2026-07-23 17:02:08 -04:00