firmware: revert lwIP window bump — broke the stream accept path

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).

1 files 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