ESP32-POE Scrypted viewport (private) https://src.nth.io/luke/esp32-poe-scrypted-viewport/atom?h=v1.0.0 2026-06-20T15:31:32+00:00 2026-06-20T15:31:32+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:31:32+00:00 urn:sha1:79d3e379c6c5f9a465c9333410830e9037c6a1c7 2026-06-20T15:30:24+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:30:24+00:00 urn:sha1:496da49dd5ce4a3bfc4b5df84ce5c7f7bdbcf504 Three changes that work together to make the stream "always paint what's freshest, never sit on a stale frame": #1 — Firmware FIONREAD skip in stream_server Right after the body of frame N comes off the wire (and before we unlock the decoder + spend ~6ms on decode + paint), check the kernel receive buffer with ioctl(FIONREAD). If at least one more header (8 bytes) is queued, frame N is no longer the freshest possible — skip its decode + paint and loop back to read frame N+1. The TCP recv cost is unavoidable (bytes still have to cross the wire) but the decoder + paint cost is saved on every superseded frame. Glass-to-glass latency on the latest frame drops by however many frames had backed up. #2 — Scrypted: keep writing past kernel-buffer backpressure Previously: when sock.write() returned false we dropped the next ffmpeg frame at source. New: we keep writing through. Node buffers internally; under our load (~16 MB/s ffmpeg → ~5-7 MB/s firmware) the buffer rarely exceeds a frame or two. With the firmware now silently skipping decode on backed-up frames (#1), excess frames get shed for free on the device side. Scrypted's job is just to hand the firmware the freshest bytes as fast as possible. socketBackpressured is still tracked for the diagnostic log. #3 — lwIP TCP window bump (revisiting earlier regression) The previous attempt at LWIP_TCP_WND_DEFAULT=32k regressed under HTTP because every /frame opened a fresh socket and we paid the slow-start cost repeatedly. The streaming pivot eliminated that: the socket is long-lived, slow-start runs exactly once, then we ride the full window for the rest of the session. Bumping to 65535 (max for stock lwIP), SND_BUF to match, RECVMBOX to 16, SACK on. Expected: recv throughput ceiling moves up from ~5.3 MB/s, which directly raises the fps ceiling (recv is currently 37ms of the 43ms per-frame total). 2026-06-20T15:12:10+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:12:10+00:00 urn:sha1:cebd60d4be74ddac9c18a7b08eef9ec00cbc31f5 2026-06-20T15:11:57+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:11:57+00:00 urn:sha1:521de7ef844a4b5c1eb660ff54382b958fb62bd7 #1 — Wake triggers in the new-device dialog The "+ Add Device" form was missing the Wake triggers multi-select, so a new viewport defaulted to the per-getter fallback of all three (doorbell + motion + person) silently and the user only saw the field after first edit. Now the dialog includes it up front with all three pre-selected, and createDevice persists whatever the user ticked into storage in the same JSON shape Viewport.putSetting uses for subsequent edits. #2 — Stop leaking the periodic re-register interval Why the user was seeing the "registered ..." log line repeat 14 times in steady-state with nothing happening: Scrypted's Scripts sandbox does NOT garbage-collect setInterval handles when a script is re-pasted/reloaded. Every re-paste left an orphan interval running against the previous Provider instance, accumulating one extra timer per reload. Every 5 minutes (REREGISTER_INTERVAL_MS), all N timers fired at once, producing N "registered ..." log lines in rapid succession. Fix: keep the timer handle on globalThis under a well-known key. At script start, clearInterval the previous one (if any) before arming the new one. Idempotent across reloads. 2026-06-20T15:07:15+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:07:15+00:00 urn:sha1:f93179d9d1cd9e2f2b3977cd7020e13f133588b2 2026-06-20T15:06:58+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:06:58+00:00 urn:sha1:f982b88d447f265f9847a48946a9903d1faebf49 Reverts the per-viewport "Camera substream" UI added in 6d74d02 — having a knob the user has to find and tune is the wrong shape. The goal is "best quality, highest fps that's actually achievable" and that's a deterministic walk, not a user choice. New walk: medium-resolution → local → remote → camera-default. Explicitly NOT in the list: - low-resolution: the camera's preview substream, capped at the ~5-8 fps that's been bottlenecking us. - remote-recorder: has the camera's ~10s prebuffer baked in (we'd display the past rather than the present). Wire cost is unchanged: every input resolution is re-encoded to panel-native 800x480 mjpeg q:v 1 before going to the device. The only tradeoff for picking the main stream is Scrypted-side ffmpeg CPU, which is plentiful. Throughput to the firmware is the same; upstream camera fps is what changes (5fps → 15-30fps typical). 2026-06-20T15:02:48+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:02:48+00:00 urn:sha1:aa1ce70d546355997c58488fc409767d1dc8088f 2026-06-20T15:02:38+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T15:02:38+00:00 urn:sha1:6d74d02acf3a544617fce1291ad22a87624aceee Three independent improvements landing together because they all target the post-streaming-pivot "where do we spend the wall clock?" question. #1 — Snapshot: sharp → mediaManager native → ffmpeg cascade pushSnapshot now tries three transforms in order of cost: - sharp (~5-15ms, libvips bindings, handles resize + rotate) - mediaManager.convertMediaObjectToBuffer with image/jpeg;width=W ;height=H mime hint (~10-30ms, Scrypted's native converter, used only for landscape since rotation isn't standard) - ffmpeg one-shot (~500-700ms cold start, the old slow path) A `path=...` field in the snapshot log identifies which transform actually ran so the user can confirm the fast paths are reachable in their Scrypted runtime. takePicture, transform, and POST timings are each broken out so we can see exactly where the snapshot wall goes. #2 — Firmware: windowed min/avg/max breakdown + idle-gap Stream server replaces the per-frame single-sample log with a 30- frame window summary: N frames over Xs: Yfps Z MB/s avg-jpeg=KB | lock min/avg/max | recv min/avg/max | dec min/avg/max | paint min/avg/max | idle min/avg/max - lock = mutex acquire time (sanity check; should be ~0us with one client owning the decoder) - recv = body bytes off the wire - dec = HW JPEG decode - paint = backbuffer flip + DMA queue - idle = gap between previous paint completing and next header landing (= upstream slack). Large idle means we're waiting on ffmpeg/network; near-zero means we're the bottleneck. #3 — Camera substream picker "Stream-source choice drives end-to-end latency more than anything else" — the existing hardcoded low-latency-first walk lands on the camera's preview substream which is typically capped at 5-8 fps. Adds a per-viewport setting under Display: Camera substream: auto | low-resolution | medium-resolution | local | remote | remote-recorder auto keeps the current behavior; the pinned options let the user force a higher-fps source when they want stream rate > preview rate. The chosen destination is logged at stream start. 2026-06-20T14:49:48+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T14:49:48+00:00 urn:sha1:72639d47771dbcf3f83360536431beff7d7e2243 2026-06-20T14:49:36+00:00 Luke Hoersten luke@hoersten.org 2026-06-20T14:49:36+00:00 urn:sha1:d8d9a662f045aca6b0bf1f0e0494f9034ec54a80 Two settings cleanups now that streaming has landed: - frame_interval_ms removed entirely. Under the TCP streaming data plane ffmpeg emits at the camera's native rate and TCP backpressure naturally caps us when the firmware can't keep up. The setting, the getter, the UI field, and the -vf "fps=N" filter argument all go away. Net: a few fewer questions to answer on every viewport, and one fewer place for the user to misconfigure latency. Existing storage values are silently ignored on next render. - Default brightness 80 → 100. The panel is dim enough at 80 that the change in ambient lighting can wash it out; 100 is a better default. Users who want lower can still set it in the UI; this only affects newly-created viewports (existing ones keep whatever was last saved).