From 6e36cbc14a06b8c0e15bfe78afb8adb43f8909ba Mon Sep 17 00:00:00 2001 From: Luke Hoersten Date: Sat, 20 Jun 2026 10:38:46 -0500 Subject: firmware: revert lwIP window bump — broke the stream accept path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hypothesis confirmed by the symptoms: with WND_DEFAULT=65535, SND_BUF=65535, RECVMBOX=16, the firmware boots fine and the stream server logs "listening on tcp/:81", but Scrypted's first SYN never produces a "client connected from ..." entry. The script-side socket stays stuck in pending-connect — neither a connect nor an error event fires — and every ffmpeg-emitted frame gets dropped. Root cause is almost certainly lwIP's PBUF / MEMP pools not being scaled to back the 64KB windows on multiple sockets (httpd has 4, stream has 1, that's 5 × 64KB = 320KB of buffer commitment from a heap that's also feeding PSRAM-backed framebuffers, JPEG scratch, and Ethernet DMA). lwIP doesn't surface the allocation failure as an accept error — it just refuses to complete the handshake. Backing off the changes for now. The streaming path already hits ~14-20 fps at our measured 5.3 MB/s ingest ceiling under the lwIP defaults — that's plenty above the 12-fps goal. Revisit window tuning later by also bumping CONFIG_LWIP_PBUF_POOL_SIZE and MEMP_NUM_TCP_PCB so the buffer commitment is actually allocatable. Keeping the FIONREAD skip in stream_server (it's orthogonal to lwIP buffer sizes and only helps). --- sdkconfig.defaults | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/sdkconfig.defaults b/sdkconfig.defaults index 1ba8375..9e8c9e8 100644 --- a/sdkconfig.defaults +++ b/sdkconfig.defaults @@ -29,18 +29,14 @@ CONFIG_LWIP_IPV4=y CONFIG_LWIP_IPV6=y CONFIG_MDNS_MAX_INTERFACES=1 -# TCP receive-window + buffer tuning. Earlier attempt under HTTP -# regressed because every /frame opened a fresh socket and we ate -# the slow-start cost repeatedly. Under the streaming pivot the -# socket is long-lived: slow-start happens once, then we run with -# the full window for the rest of the session — which is exactly -# the workload these knobs are designed for. Larger WND lets the -# sender keep more bytes in flight per ACK and pushes our recv -# throughput ceiling up from ~5.3 MB/s. -CONFIG_LWIP_TCP_WND_DEFAULT=65535 -CONFIG_LWIP_TCP_SND_BUF_DEFAULT=65535 -CONFIG_LWIP_TCP_RECVMBOX_SIZE=16 -CONFIG_LWIP_TCP_SACK_OUT=y +# TCP tuning attempted (WND=64k, SND_BUF=64k, RECVMBOX=16, SACK on) +# after the streaming pivot landed. The accept path then silently +# failed — Scrypted's SYN was acked but no client-connected log +# fired, and the stream never moved a byte. Almost certainly lwIP's +# PBUF / MEMP pools weren't scaled to back the larger windows on +# multiple concurrent sockets (httpd has 4, stream has 1). Revisit +# with PBUF_POOL_SIZE + MEMP_NUM_TCP_PCB bumps next time, but for +# now ride the lwIP defaults which sustain ~5.3 MB/s ingest. # HTTP server CONFIG_HTTPD_MAX_REQ_HDR_LEN=1024 -- cgit v1.2.3