El watcher F3 posteaba UN snapshot de speed= al arrancar y moría: un encoder
sano en el minuto 1 que se ahoga en el minuto 20 (escena compleja, GPU robada
por otro proceso) era invisible para el triage de stalls del player, que
decidía con el dato de arranque.
- monitorSessionHealth: ticker 5s el resto de la sesión; re-postea al cambiar
el bucket ok/marginal/struggling (con histéresis de 2 ticks — una EWMA
bailando sobre 0.95 no puede webhookear cada 5s) o al derivar el ratio
≥0.15. Un POST fallido NO avanza el baseline: el tick siguiente reintenta
(perder el único webhook de la transición a struggling cegaba al player
justo en el caso que esto existe para cubrir).
- resetTranscodeStats() en restartFromSegment: el ffmpeg nuevo de un seek
re-arma el warmup y resiembra la EWMA — sus frames fríos (speed=0.0x)
hundían la media curada a <0.75 y el monitor habría posteado un
"struggling" falso que pausaba el player en pleno seek. Verificado e2e:
dos restarts (seek a 1200s) con health estable en ok.
- inputBound ventanado (30s) en vez de pegajoso: un blip de lectura
transitorio ya no reclasifica como input_bound/struggling cada dip <0.95
durante el resto de una sesión de horas.
- Heartbeat copy (F2): las sesiones -c:v copy postean una vez
{ok, 1.0, "copy"} tras el ready — la web ya distingue "sesión copy" de
"agente viejo sin telemetría" (ambos eran null). Segundo POST deliberado:
un 400 de una web vieja (enum sin "copy") jamás debe bloquear el ready.
- Logs de fallo etiquetados por tipo de POST: un heartbeat fallido ya no se
lee como "mark-ready failed" (el ready SÍ aterrizó).
Requiere web con session-ready/SSE actualizados (desplegar web primero;
contra web vieja todo degrada a best-effort con log).
f0c51c5d90