Two independent live-hardware bugs found testing on real DAB signal
tonight (board reconnected after this session's feature work):
1. Si4684Driver::fetchDabServiceList() double-counted the already-
consumed SIZE field when computing the body offset: it added a
phantom "List Size(2)" on top of the 7-byte STATUS/SIZE header
already stripped out, shifting the service-count byte and every
service entry by exactly 2 bytes. AN649 documents SIZE/DATA_0/
DATA_N generically for GET_DIGITAL_SERVICE_LIST and defers the
actual DAB payload layout to a supplemental "Digital Services
User's Guide" we don't have, so the previous "AN649 Table 14"
citation for that layout was never actually sourced from AN649 —
it was guessed. Re-derived the real layout by cross-checking
hitech95/si468x_dab_receiver's si468x_core_cmd_dab_get_service_list()
(a working Linux driver for the same command), which also shows
the payload is SIZE-2 bytes, not SIZE bytes — fixed the read-length
sizing (payloadSize+5, was +7) to match. This is what made
GET /api/tuner/services always come back empty even with a locked
ensemble.
2. SetupWebServer registers 41 HTTP routes but httpd_config_t::
max_uri_handlers was still 40 (set before several endpoints landed
this session). esp_http_server's httpd_register_uri_handler()
fails silently past the limit, logging only a generic
"no slots left" warning with no indication of which handler was
dropped — the 41st and therefore last-registered route,
POST /api/stations/tune, was silently unroutable (404) on every
boot since whichever commit pushed the count past 40. Bumped to 56
for headroom.
Both confirmed on hardware: fresh flash boots with zero httpd
warnings; DAB service list fix not yet re-verified against a live
ensemble pending user retest (board was between test sessions).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
micheleandClaude Sonnet 5
f9f3e58d64