luke/esp32-poe-scrypted-viewport/scrypted, branch v1.3.1

release: v1.3.1

2026-07-16T00:04:56+00:00

Stream throughput tuning, measured on hardware (kitchen panel): wire 53 -> 74 Mbps, per-frame recv 30.5 -> 21.4 ms, painted fps 19.8 -> 23.6, g2g 73 -> 62 ms, sender backpressure 61% -> 47%. - lwip: TCP_WND 5760 -> 23040 (16 x MSS), RECVMBOX 6 -> 32 - eth: EMAC RX DMA pool sized above the TCP window (1600B x 24); below-window pool caused silent burst tail-drop + ~200-400ms sender RTO stalls - stream: TCP-window decomposition instrumentation (wire kbps, hdr_gap, pend_age) in the window log and /state; connect log stamps TCP_WND/MSS/RECVMBOX Set VIEWPORT_VERSION and scrypted/package.json to 1.3.1.

scrypted: stamp SCRIPT_VERSION = 01a588e

2026-07-01T19:33:44+00:00

scrypted: fix stale Streaming header comment (TCP socket, q:v default 1, skip-oldest)

2026-07-01T19:33:44+00:00

release: v1.3.0

2026-07-01T19:23:49+00:00

Unify firmware and plugin versions for the production release. Highlights since v1.1.0/1.2.0: - event wake fixed (self-healing camera-listener re-attach after the reload/ add storage race); doorbell/motion/person confirmed on hardware - stop() fully tears down (stop+start == fresh load); stale childId pruning; live-stream events ignored (no queue/relaunch) - triggers default to person+doorbell; doorbell hidden for non-doorbell cams - cold-start (wake -> live video) ~6s -> ~0.7s: prebuffered substream by id + request >= GOP + burst-friendly ffmpeg flags; snapshot removed - firmware: Loading screen on new stream connection (no stale-frame flash) - logging trimmed for chatty cameras - README/protocol docs rewritten for the TCP-socket streaming model Set VIEWPORT_VERSION and scrypted/package.json to 1.3.0.

scrypted: stamp SCRIPT_VERSION = 0be8f18

2026-07-01T19:19:01+00:00

scrypted: trim stream logging volume

2026-07-01T18:22:05+00:00

A chatty camera keeps a viewport streaming for long stretches, and the old logging emitted ~5 cold-start stamps + a 10s window line per ~10s per stream. Cut it down: - keep a single cold-start stamp (first ffmpeg frame); drop spawned / first stdout byte / first socket.write. - gate the 10s window line on noteworthy windows only (socket-not-ready drops, a buffer-cap flush this window, firmware shedding >=2fps, or painted <20fps); healthy 24fps windows print nothing — the per-wake lines already show liveness. - log "registered" only when the pushed config actually changes, not on every 5-minute reregister cycle. lastRegisterSig cleared on stop() for fresh-load parity. No behavior change beyond logging.

docs: bring scrypted/README.md in line with current streaming behavior

2026-07-01T02:14:43+00:00

The v1 README still described the old snapshot-poll path. Update to match the shipped script: live MJPEG over a TCP data socket (port 81, ~24fps) via ffmpeg, not ~1fps snapshots. Fixes: - intro + v1 limitations: MJPEG streaming is done, not a v2 "POST /stream" TODO - Settings: replace the removed "Frame push interval" with the real Display fields (JPEG quality, Max Scrypted-side buffer, Stream prebuffer); add the Actions group; correct brightness default (100, was 80) - Wake triggers default is person+doorbell (was "all three"), doorbell only for doorbell-capable cameras - drop the stale snapshot-source / snapshot-interval / POST /frame 409 mentions - host field: no mDNS auto-resolve (was contradictory) - smoke test: Loading -> live video, not "snapshots flowing"

docs: document required Medium-stream prebuffer for fast wake

2026-07-01T02:11:17+00:00

Wake-to-live is ~0.7s only when the streamed substream keeps a rebroadcast prebuffer. Add a "Fast wake — camera prebuffer (required)" section to scrypted/README.md: enable Prebuffer on the STREAM: MEDIUM tab (default only prebuffers High), keep duration >= the detected keyframe interval (~5s), leave the viewport's Stream prebuffer (ms) at 6000, and how to verify via the log.

scrypted: stamp SCRIPT_VERSION = c6610c1

2026-07-01T01:44:00+00:00

scrypted: remove the pre-stream snapshot entirely

2026-07-01T01:43:52+00:00

The prebuffered stream now paints in ~0.7s, so the takePicture→transform→POST first-paint bridge was consistently slower than the video it was meant to cover, while adding camera load and a stale-overpaint risk. Drop it: remove pushSnapshot and its call, the shouldPaint gate, and the firstStreamFrameSeen plumbing. On the slow paths (no/cold prebuffer) the panel holds its prior frame until the stream's first frame lands. buildVf stays (used by the live path).