Resolución de problemas

El panel está en verde pero ningún televisor recibe nada

Todos los canales aparecen en marcha. Las cifras de tasa de bits parecen razonables. Ni un solo televisor tiene imagen. Es, con gran diferencia, la avería más común en una instalación nueva, y casi siempre se debe a la ruta multicast.

Causa probable

La ruta del tráfico multicast apunta a la interfaz de red equivocada, o a una interfaz sin portadora: sin nada conectado, o conectada a un puerto muerto. Los paquetes se generan correctamente y se entregan a una interfaz que no lleva a ninguna parte.

Por qué esto es invisible desde dentro del proceso

Enviar un datagrama UDP a un destino multicast sin ruta tiene éxito. La llamada al socket vuelve sin error. No hay ningún ICMP unreachable que observar, ninguna conexión que falle, ningún reintento que contar. En consecuencia, todos los contadores dentro del proceso de emisión indican un estado perfectamente sano mientras no sale nada del edificio.

Ningún motor de emisión puede detectarlo, y por mucho que se reinicie no cambia nada. Hay que comprobarlo contra la tabla de rutas del host desde fuera del proceso, que es lo que hace Castmux.

Vincular el socket de salida a una dirección de origen no lo resuelve. El kernel sigue consultando la tabla de rutas para elegir la interfaz de salida; la dirección de origen solo determina lo que aparece en la cabecera del paquete.

Cómo confirmarlo

Dos comandos en el equipo. Pregunte al kernel adónde iría realmente un datagrama para el grupo del canal y, a continuación, compruebe qué interfaces tienen portadora:

# Substitute the destination group of an affected channel
ip route get 239.10.0.1

# Which interfaces are actually up, and which are merely configured
ip -brief link

El primer comando indica la interfaz que se usará. Si no es la interfaz orientada a los televisores, ha encontrado la avería. Si es la interfaz correcta pero ip -brief link la muestra DOWN o sin portadora, también ha encontrado la avería.

Las direcciones de enlace local le confundirán

Es habitual que una interfaz tenga a la vez una dirección de enlace local en 169.254.0.0/16 y su dirección real, y ip -brief suele listar primero la de enlace local. Si identifica las interfaces por la primera dirección que aparece, concluirá que la NIC orientada a los televisores es otra distinta de la que es. Lea la línea completa.

Solución

Dirija todo el rango multicast a la interfaz orientada a los televisores y haga que el cambio sobreviva a un reinicio: un comando ip route tecleado a mano se pierde la próxima vez que se reinicia el equipo, y así es como esta avería reaparece semanas después sin que nadie recuerde la primera vez. Instalación describe la unidad de enrutamiento suministrada, que reevalúa la ruta periódicamente para que siga al cable si el enlace cambia.

Corrija el rango, nunca grupos individuales

Añadir una ruta de host para un grupo —un /32 para 239.10.0.1— hace que ese canal funcione y deja 224.0.0.0/4 todavía roto. Todos los canales que se añadan después quedan silenciosamente sin ruta, y no será obvio por qué, porque los canales que funcionaban siguen funcionando.

Ese mismo error ha provocado dos incidentes distintos de varias horas. Uno se presentó como un contenedor que se reiniciaba cada quince minutos durante horas; el otro, como un único canal que se reiniciaba cada treinta segundos. Ambos se investigaron como fallos del motor y del watchdog. No lo eran. Enrute el rango.

Castmux comprueba la tabla de rutas desde fuera del proceso y notifica un destino como sin ruta cuando lo está. Deliberadamente no reinicia el canal en esta situación: un reinicio no puede corregir una avería de enrutamiento, y un bucle de reinicios enterraría la única línea de registro que nombra la causa real. Consulte Monitorización.

Pixelación y tirones en un canal

La imagen se rompe en bloques, o se congela y salta, en un canal mientras los demás están bien.

Lo más probable: dos emisores en el mismo grupo

Dos procesos que transmiten al mismo destino multicast. Los televisores reciben ambos flujos entrelazados y el resultado es una corrupción continua. Lo habitual es que se origine en una migración: un servicio antiguo que sigue en marcha de una instalación anterior, o una unidad del sistema que se deshabilitó pero no se detuvo, junto al despliegue nuevo. Ambos emisores parecen completamente sanos desde su propio punto de vista, porque cada uno produce un flujo válido.

Confírmelo con la alerta de emisor duplicado, que se genera cuando Castmux observa tráfico hacia uno de sus destinos que no ha enviado él, y buscando en el equipo y en la red otro proceso que transmita al mismo grupo y puerto. Corríjalo deteniendo correctamente el emisor antiguo: deshabilitar una unidad no impide que otra cosa la arranque, así que revise también las tareas programadas.

Tenga en cuenta también

• Pérdida en la fuente. El origen entrega un flujo dañado y usted lo está reenviando fielmente. Para verlo con honestidad, ejecute el canal con el motor pass-through: conserva los contadores de continuidad originales, así que el análisis aguas abajo muestra la pérdida. El motor de remultiplexado vuelve a numerar los contadores de continuidad, lo que hace que la salida parezca estructuralmente limpia y oculta de dónde vino el daño. Consulte Motores de emisión.
• Un múltiplex sobresuscrito, si el canal se transporta en DVB-C. Si la tasa de bits combinada de los servicios supera lo que admite la portadora, todo lo que hay en ese múltiplex se degrada, no solo el canal del que alguien informó. Consulte Multiplexación DVB-C.
• Switches sin IGMP snooping. Sin snooping, cada flujo multicast se difunde a todos los puertos. Una docena de canales llega entonces a cada televisor y a cualquier otro dispositivo del segmento, y los puertos de acceso se saturan. El síntoma suele ser pixelación en muchos canales a la vez, que empeora a medida que añade canales.

Un canal se reinicia repetidamente

El tiempo en marcha nunca pasa de uno o dos minutos. Empiece leyendo el registro de ese canal en la interfaz: el motivo de cada reinicio queda registrado y distingue la mayoría de las causas siguientes sin más investigación.

Fuente inaccesible o intermitente

El origen corta la conexión o solo está disponible a ratos. Castmux espera cada vez más entre intentos en lugar de acosarlo, y la espera se restablece tras un periodo sostenido de funcionamiento correcto. Revise el origen antes de cambiar nada en el equipo.

El origen publica una dirección IPv6 que el equipo no puede alcanzar

Muy común y rara vez sospechado. Consulte Todo tarda en arrancar más abajo: provoca ambos síntomas.

Latencia SRT demasiado baja

La latencia configurada debe cubrir el tiempo de ida y vuelta del enlace con margen para las retransmisiones. Si es demasiado baja, la recuperación falla y la sesión se corta repetidamente.

Un watchdog basado en una métrica que no existe para el motor

Una monitorización externa que alerte por fotogramas por segundo o velocidad de reproducción reiniciará indefinidamente canales pass-through sanos, porque esas métricas no existen para ese motor. Consulte la advertencia en Monitorización.

Un enlace de subida sobresuscrito al arrancar

Si todos los canales arrancan a la vez, cada uno abre su conexión con el origen simultáneamente y el enlace de subida no puede atenderlos a todos; varios agotan el tiempo de espera, se reinician y vuelven a intentarlo juntos. El escalonado de arranque existe precisamente para evitarlo. Si se ha reducido o desactivado, restáurelo.

Un canal no arranca en absoluto

Compruebe estos puntos por orden. La lista está ordenada según la frecuencia con que cada uno resulta ser la respuesta, no según lo interesante que sea.

1. ¿Está activo el canal? Un canal desactivado no se planifica en absoluto.
2. ¿Es bajo demanda y no tiene espectadores? Es la falsa alarma más común de esta página. Se supone que un canal bajo demanda que nadie está viendo no debe estar en marcha. Confírmelo abriendo su vista previa, que cuenta como espectador y lo arranca. Consulte Emisión bajo demanda.
3. ¿Es accesible la fuente desde el equipo? No desde su portátil: desde el equipo. Otro DNS, otro enrutamiento, otras reglas de cortafuegos, quizá otra VLAN. Una fuente que se reproduce perfectamente en VLC en su máquina le dice que el origen está vivo, y nada sobre si el equipo puede alcanzarlo.
4. ¿Está el destino ya en uso por otro canal? Dos canales configurados con el mismo grupo y puerto es la misma avería de emisor duplicado descrita más arriba, creada localmente.
5. En DVB-C, ¿se pudo sondear el canal? Un servicio que no se ha podido sondear no puede asignarse a un múltiplex. Consulte Multiplexación DVB-C.

Todo tarda en arrancar y las descargas tardan segundos

Los canales tardan un tiempo excesivo en ponerse en marcha, las descargas de listas de reproducción tardan segundos y la lentitud es irregular: a veces la misma petición es rápida.

Causa

El origen publica un registro AAAA de IPv6 y el equipo no tiene ninguna ruta IPv6 operativa. La selección de direcciones prefiere IPv6, así que cada petición HTTP prueba primero IPv6 y solo después recurre a IPv4. El coste de ese recurso depende por completo de cómo falle el intento por IPv6:

Cómo falla el intento por IPv6	Coste por petición
Rechazo inmediato	Unos cientos de milisegundos. Molesto, pero soportable.
Ruta en agujero negro	Un tiempo de espera de conexión completo, sin nada que lo aborte antes. De ahí vienen los bloqueos de varios segundos.

Pagado en cada petición de lista de reproducción y de segmento, basta para que un canal pierda su temporización y se reinicie. En un caso provocó que un canal se reiniciara 765 veces en un solo día.

Esto se diagnostica mal con frecuencia, así que mídalo bien

Ese mismo incidente se atribuyó inicialmente a un origen lento a partir de una sola descarga cronometrada que tardó 10.8 segundos. Las repeticiones de la misma descarga tardaron 0.59 segundos. Una sola muestra de una avería que solo a veces provoca un tiempo de espera le dirá lo que ya creía. Ejecute la descarga diez veces y observe la distribución.

Solución

Configure el equipo para que prefiera IPv4 sobre IPv6 en la selección de direcciones. Hágalo en ambos sitios: en el host y dentro del contenedor, que tiene su propia copia de la política de selección de direcciones. Corregir solo el host deja sin cambios el proceso de emisión —el que hace las peticiones— y el síntoma no cambia en absoluto, lo que suele interpretarse como que el diagnóstico era erróneo.

El canal se reproduce pero no hay sonido, o el idioma es incorrecto

La imagen es correcta, pero falta el audio, o solo hay un idioma disponible cuando la fuente transporta varios. Tres causas distintas:

• El motor de remultiplexado reenvía una sola pista de audio. Su selección de flujos por defecto toma un flujo de vídeo y uno de audio y descarta el resto. Si la instalación necesita varios idiomas, ejecute el canal con el motor pass-through, que transporta cada PID de audio junto con el mapa de programa original y sus descriptores de idioma, para que el televisor pueda ofrecer la elección. Consulte Motores de emisión.
• Una escalera HLS demultiplexada. Cuando el origen publica el audio como versiones separadas en lugar de multiplexado en las variantes de vídeo, seleccionar una única variante de vídeo pondría en antena vídeo sin sonido. La protección del perfil de resolución lo detecta y conserva la URL maestra precisamente por ese motivo, y lo indica en el canal. Si ha sustituido a mano la URL de la fuente para que apunte a una variante de vídeo de una escalera así, ahí es donde se fue el audio. Consulte Perfiles de resolución.
• La fuente transporta realmente una sola pista. Ningún ajuste del motor crea una pista de audio que la entrada no contenga. Compruébelo en el origen antes de investigar cualquier otra cosa.

Un interruptor de la interfaz no coincide con la insignia que tiene al lado

Un conmutador muestra un estado mientras que el estado representado a su lado, a partir del mismo valor subyacente, muestra el otro.

Es un comportamiento del navegador, no un estado de la aplicación. En una recarga suave o al volver atrás, los navegadores restauran los controles de formulario al estado que tenían antes e ignoran el estado que el servidor envió en la página. La insignia es texto plano y refleja el servidor; el interruptor es un control y refleja lo que su navegador recuerda de la página anterior.

Fuerce una recarga completa y ambos coincidirán. Si esto aparece siquiera en un producto como este es porque los identificadores de canal se reutilizan tras una eliminación: cree un canal, elimínelo, cree otro, y el nuevo ocupa el identificador antiguo, así que el navegador restaura alegremente el conmutador del canal eliminado en su sustituto.

Los televisores perdieron su numeración de canales tras un cambio de parrilla

En DVB-C, los televisores guardan los canales asociados a las identidades de servicio transportadas en el múltiplex. Cambiar el orden de las posiciones cambia esas identidades, de modo que los televisores ya no reconocen lo que tenían guardado y deben volver a sintonizarse, en todo el edificio, que es precisamente el trabajo que nadie quiere.

Hasta que la identidad de servicio pueda fijarse con independencia del orden de las posiciones previsto, evite reordenar un múltiplex en servicio. Añada los servicios nuevos al final en lugar de intercalarlos, y planifique el orden antes de sintonizar la instalación, no después. Consulte Multiplexación DVB-C.

Qué enviar a soporte

Lo siguiente convierte un intercambio de varios días en una sola respuesta. Recópilelo antes de escribir el mensaje, no cuando se lo pidan.

• El nombre del canal, su URL de fuente y su grupo y puerto de destino.
• El registro de ese canal, desde la interfaz.
• La salida de ip route get <group> para el destino afectado.
• La salida de ip -brief link.
• El archivo de configuración, sin credenciales.
• Si la avería afecta a un canal o a todos: esto por sí solo separa un problema de la fuente de un problema de la red.
• Si ha cambiado algo en la red. Un switch sustituido, una VLAN modificada, un cable movido, una actualización de firmware. La respuesta es sí más a menudo de lo que se espera.