Caso real resuelto con la bitácora (23/08, 12:11): tres rellamados de E001,
el del medio no sonó. No fue la voz: la pestaña que anunciaba estaba en
segundo plano —era el Mac de pruebas, no el televisor; lo delata la voz
Paulina— y Chrome frena los relojes de las pestañas ocultas a ~1 tic por
minuto. En ese hueco el llamado intermedio fue invisible: cuando la pestaña
volvió a consultar, el servidor ya solo mostraba el estado más reciente.
Para que ese estado deje de confundirse con un fallo de la voz, la pantalla
registra ahora el evento 'lag' cuando detecta un hueco de más de 10 s entre
tics o cuando pasa a segundo plano, y la tarjeta de Actividad lo traduce como
«Pantalla congelada» con su explicación.
En el televisor real —siempre visible, en primer plano— este estado no debe
aparecer; si aparece, es la señal de que alguien lo dejó oculto o el equipo
se suspendió.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
── Voz que a veces no suena o se corta ──
Dos causas nuevas, ambas intermitentes por naturaleza:
1. Defecto conocido de Chrome: si nada referencia la SpeechSynthesisUtterance,
el recolector de basura puede llevársela A MITAD DE FRASE. El audio se corta
en seco y 'end' no llega. Depende de cuándo pase el recolector, así que
nunca se reproduce a voluntad. Cada locución queda anclada en un Set hasta
terminar (_uttAncladas).
2. Tras un cancel(), en Windows y ChromeOS el motor puede quedar en pausa:
speak() encola y jamás suena, sin error alguno. resume() antes de cada
speak() lo destranca, y sobre un motor sano no hace nada.
Y porque lo intermitente no se depura mirando la pantalla, queda una bitácora:
cada intento de hablar registra voz elegida, si es local, cuánto tardó en
arrancar y cómo terminó — en localStorage.tvVozLog (últimos 200) y en la tabla
turnero_tv_log vía sendBeacon (endpoint log_tv.php, insert-only, eventos de
lista cerrada). La próxima vez que reporten "ayer a las 10 no sonó", se
consulta la tabla y se ve qué pasó exactamente.
── Servicios de RIPS que "se demoran" ──
Medido en datos, no en hipótesis: la facturación en el sistema del laboratorio
ocurre MIENTRAS la recepcionista atiende. La consulta a RIPS se hacía UNA sola
vez, al vincular al paciente — y en 7 días, 547 de 549 registros llegaron
DESPUÉS de esa única consulta. Nadie volvía a preguntar: eso es lo que se
percibía como lentitud de RIPS. (El scheduler en sí tarda segundos; de paso:
el reloj del equipo legado está ~1 hora atrasado, visible en hora_recepcion.)
Ahora la ficha sondea cada 10 s hasta 10 minutos y se detiene al encontrar,
al limpiar la ficha o al agotar los intentos. Si la recepcionista ya marcó
exámenes a mano, no se le pisan: se le ofrece el banner en vez de autocargar.
── Pruebas (22, todas contra el código real extraído de las vistas) ──
scripts/test_tv_voz.js 9 anclaje GC, resume(), bloqueo, voz lenta, bitácora
scripts/test_rips_sondeo.js 7 reintentos, paradas, tope, sin duplicar
scripts/test_rips_ventana.php 6 ventana SQL en tabla TEMPORARY, sin tocar datos
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
