j,dZddlmZddlZddlZddlZddlZddlZddlZddl Z ddl Z ddl Z ddl m Z mZddlmZddlmZmZddlmZmZmZmZddlmZmZddlZdd lmZdd lm Z ejBd Z"e#Z$ee%jMjNjNZ(d Z)d Z*dZ+dZ,dZ-dZ.dZ/dZ0dZ1dZ2dZ3dZ4dZ5dZ6e(dz dz dz Z7ejBdZ8dZ9dZ:dZ;d Zd#Z?d$Z@d%ZAd&ZBd6d'ZCd7d8d(ZDd9d)ZE d: d;d+ZFeGhd,ZHd*dd- du Live feed server — §6 seam #3: engine → renderer (SSE, stdlib-only) The demo serves the feed as static JSON consumed by core/web/feed.js `FileFeed`. Production pushes the same payload live; the renderer switches to it purely via config (core/web/config.js `feed:'live'` → app.js lazy-loads live/web/live_feed.js `LiveFeed`). The renderer is otherwise unchanged — both sources honour the one BroadcastFeed contract. Transport = **Server-Sent Events** over the Python stdlib threading HTTP server (no extra deps): broadcasting is one-way (server → many renderers), which is exactly SSE's shape, and the browser's `EventSource` gives auto-reconnect for free. This server also serves the static broadcast files (from the v3/broadcast root) so the page and the `/events` stream share one origin — no CORS, one command. Wire messages (SSE `event:` types; `data:` is JSON — mirror the file feed's shape, sent as deltas): init : {meta, course, teams, params, media, video} # static race header (also the backlog head) delta : {sec, standings, positions, events, ais, program} # one tick, from StreamingScorer.push_frame stale : {stale, reason, sinceS} # ON AIR but publishing nothing (or recovered) result: {winner, winnerName, winnerSec, ...} # once the race finishes `program` (when the driver computes it — `program_state()`) is the explicit presentation phase (countdown / racing / result), so a client never infers liveness from standings alone. Late joiners (e.g. OBS reconnecting) get the full backlog — the latest `init` plus every `delta`/`result` so far — before live deltas resume, so a fresh client renders the whole race-so-far. Sub-phase: B-B (live feed transport). Drive it with live/serve_live.py (replays the demo race through StreamingScorer); the bounded-LLM editor (B-C) edits each delta's newly-finalised colour beats first. ) annotationsN)SimpleHTTPRequestHandlerThreadingHTTPServer)Path) HTTPErrorURLError)parse_qsquoteunquoteurlsplit)Requesturlopen)control_enabled)RendererRegistryz^bytes=(\d*)-(\d*)$z/eventsz /client-statsz/commentary-playbackii z/control/excursionz/control/course-guidez/control/camera-slotz /stats.json)z/healthzz/livezg@gK@z/core/web/cesium-config.jscorewebzcesium-config.jsz/^/v3/view/([^/]+)/boats/([^/]+)/playlist\.m3u8$VR_PRODUCER_READ_BASEVR_PRODUCER_READ_TOKENzX-VR-Producer-Tokeng@g$@z/standings.jsongf@VR_STANDINGS_URLVR_STANDINGS_SOURCEVR_STANDINGS_TEAM_LABELScZd|dtj|ddjS)z#Encode one Server-Sent Event frame.zevent: z data: F) ensure_asciiz )jsondumpsencode)eventdatas C/srv/vr/releases/25f455cc4e75/v3/broadcast/live/live_feed_server.py_sser s, UG8DJJt%$H#I N U U WWc g}|xsgD]y}|jdxsgD]_}|jd}|r|jdr(|||vr/|jd} |jdt|df|fa{|j |Dcgc]\}}| c}}S#ttf$r&|jddt |xsdf|fYwxYwcc}}w)uWhich boats stand in camera slots A, B, C … — the RACE PLANE's answer, published in the header. A camera slot is a POSITION an operator learns ("bottom-left is slot C"), so what fills it has to be stable for the whole heat: ORDERED BY SAIL NUMBER, ascending. Sorting by deviceId puts `boat:10` ahead of `boat:9`; sorting by anything that moves — place, distance to finish — would have boats swapping tiles under the operator's eyes while the race is sailed. Spectators never take a slot. They are on the water but not in this race, and a panel showing them is showing the wrong four boats. `camera_boats` restricts the order to hulls with a camera the picture can actually use; None means "every boat racing". boatsdeviceId spectatorsailIdr)getappendint TypeError ValueErrorstrsort)teams camera_boatsrowsteamboatdidsail_keys rcamera_slot_orderr8s46D  <XXg&," --!Z JH 6 L),r1A/BM.R& 66FsA?C*C/C/8C: /C48C:DD4C::DD>rTrPrSrR)r[r\c x|||dzzz dz }|rd}n |dkDrd}nd}|||t|dt||||dS) uThe feed's EXPLICIT presentation phase for one tick — `{"state": "countdown"|"racing"|"result"}`. Clients must never have to infer "is this race live?" from standings alone: a stale finished leaderboard is visually identical to a live one (the "presentation stopped while the boats keep sailing" bug class, found 2026-07-09). Publishing the phase on every delta makes the distinction part of the wire contract: `result` = the shown race is decided (anything static on screen is intentional), `countdown` = pre-gun (the race clock counts down to the start), `racing` = live. The THIS-tick gun/track-start ride along so the client's race clock counts from the CURRENT race's gun. On a single race this equals the header gun; in a continuous pipeline (one fixed session gun so the client never reloads) each heat has its own gun, and the clock resets to it at each hand-over. `toGunS` and `signal` are what let the broadcast say WHERE IN THE RACE it is — "two minutes to the start", "the preparatory signal has gone". Every consumer used to re-derive the time to the gun from the two timestamps, and none of them could name the signal at all. rMresultr countdownracingr()stategunUtcMstrackStartUtcMstoGunSrK)roundrf)r]track_start_utc_mssecfinishedr[r\rZrls r program_statertsb$03:=>&HH A GYHa('+w S UUr!ceZdZdZfdZdZfdZdZfdZdZ fdZ dd Z dd Z dd Z dd Zdd ZddZddZddZddZddZddZdZxZS)_HandlerzIServes static broadcast files; intercepts GET /events for the SSE stream.cBt||dtti|y)N directory)super__init__r._BROADCAST_ROOT)selfargskwargs __class__s rrzz_Handler.__init__s $I#o*>I&Ir!cyNr<)r|r}s r log_messagez_Handler.log_messages r!cbd|_|j}|turt|S|S)uStatic files revalidate — a broadcast asset is EDITED IN PLACE under a fixed name. The bib atlas, a sail texture, the J/80 maps: the artwork changes, the URL never does, so a browser has nothing to tell one version from the next. `SimpleHTTPRequestHandler` sends `Last-Modified` and no `Cache-Control`, which is an invitation to HEURISTIC caching — a browser treats such a response as fresh for ~10% of its age, so an atlas last touched a fortnight ago is served from cache for a day and a half **without ever asking us**. Repaint a team's bib, reload, and the old one is still on the boat: it looks exactly like a broken renderer, and the OBS Browser source has no operator to press Ctrl+Shift+R. `no-cache` keeps the copy and forces a conditional request, which 304s until the bytes actually change — the cost of one round-trip per asset, in exchange for the picture always showing what is on disk. It also answers a byte RANGE, which `SimpleHTTPRequestHandler` does not: it ignores `Range` and replies 200 with the whole file. Most clients cope. Chromium's MEDIA stack does not — it range-requests every `