TVHeadend a escala: captación DVB-S2 y DVB-T con tarjetas TBS multi-tuner

Por qué esta capa importa más de lo que parece

En un post anterior describimos la arquitectura completa de una cabecera IPTV/OTT con redundancia entre dos continentes: captación, procesamiento en Flussonic, distribución vía portal Stalker. Ese post se quedó a nivel de diagrama. Este va un nivel más abajo, a la capa que casi nadie documenta bien: cómo se configura la captación real, con TVHeadend corriendo sobre tarjetas TBS multi-tuner recibiendo satélite (DVB-S2) y terrestre (DVB-T).

Es la parte menos vistosa del sistema. Nadie enseña una demo de captación en una reunión comercial. Pero si esta capa está mal configurada, todo lo que viene después —transcodificación, EPG, portal, STB— hereda el problema. Un mux mal escaneado o un tuner saturado no se resuelve reiniciando Flussonic; hay que bajar hasta aquí.

Elegir hardware: por qué TBS y no otra marca

Existen varias familias de tarjetas sintonizadoras DVB compatibles con Linux (Hauppauge, Sundtek, DVBSky, TBS). En una operación con múltiples servidores dedicados a captación, tres criterios pesan más que el precio:

1. Drivers mantenidos. TBS publica y actualiza sus propios drivers para kernels recientes de Linux, en vez de depender solo de lo que llegue a media_tree upstream. Eso importa cuando el servidor corre una distro con kernel que se actualiza cada pocos meses.
2. Soporte multi-tuner real en una sola tarjeta. Modelos con 4 u 8 sintonizadores DVB-S2 en un solo slot PCIe reducen la cantidad física de servidores necesarios para cubrir N transpondedores en paralelo.
3. Compatibilidad USB para nodos secundarios. Para servidores más pequeños o de respaldo, los adaptadores TBS por USB permiten sumar capacidad de captación sin abrir el chasis, lo cual es útil cuando el nodo vive en un rack compartido o en una ubicación con acceso físico limitado.

Estos tres factores importan más en el día a día que las especificaciones de papel. Un sintonizador "mejor" en benchmark pero con drivers abandonados es una fuente constante de tickets.

Instalar los drivers en Linux

El flujo general para poner un adaptador TBS a funcionar en un servidor Linux dedicado a captación es, en líneas generales:

apt update
apt install -y build-essential linux-headers-$(uname -r) git dkms

# Clonar el repositorio de drivers del fabricante y compilar contra el kernel activo
git clone <repo-de-drivers-tbs>
cd media_build
make dir DIR=v4l
make
make install

# Recargar los módulos y confirmar que el adaptador aparece
reboot
dmesg | grep -i dvb
ls /dev/dvb/

El paso que más falla en la práctica no es la compilación — es el desfase entre el kernel del servidor y la versión de drivers. Un apt upgrade de rutina que actualiza el kernel sin recompilar los módulos DVB deja al adaptador invisible después del reinicio. Por eso conviene fijar la política de actualizaciones del kernel en los nodos de captación a ventanas controladas, igual que se hace con Flussonic, y no dejarlas correr por cron automático.

TVHeadend: instalación y red

Con el adaptador reconocido por el sistema, TVHeadend se instala como servicio systemd estándar sobre la mayoría de distribuciones basadas en Debian/Ubuntu, y expone su interfaz de administración por HTTP en el puerto por defecto. La instalación en sí es la parte trivial; lo que requiere criterio es la topología de red del servidor:

• Cada nodo de captación necesita salida de red estable hacia los servidores de Flussonic que van a consumir sus streams — latencia baja y sin pérdida de paquetes, porque MPEG-TS sobre HTTP no tolera bien jitter alto.
• La interfaz de administración de TVHeadend no debería quedar expuesta a internet abierto; va detrás de VPN o restringida por firewall a las IPs del equipo de operaciones y de los servidores de procesamiento.
• Si el nodo tiene más de un adaptador físico, conviene fijar cada uno con una ruta de dispositivo predecible (por udev rules) para que un reinicio no reordene qué adaptador es "adapter0" y cuál es "adapter1" — un error silencioso que rompe el mapeo de muxes sin avisar.

Escaneo de muxes: satélite (DVB-S2)

Para captación satelital, TVHeadend necesita tres cosas antes de poder escanear algo: la posición orbital del satélite, la configuración del LNB (banda, oscilador local, polaridad), y la lista de transpondedores (muxes) donde viven los canales que interesan.

El flujo de trabajo real es:

1. Configurar el LNB en la pestaña de red DVB-S del adaptador — universal, monobanda, o circular según el hardware del plato receptor.
2. Cargar la lista de muxes conocidos del satélite y el operador correspondiente, en vez de depender solo de blind scan. TVHeadend trae listas predefinidas para satélites comunes, pero cuando el operador reubica un canal a otro transpondedor —cosa que pasa varias veces al año— hay que actualizar el mux a mano o el canal se cae del escaneo sin ningún error visible.
3. Ejecutar el escaneo mux por mux y revisar que cada uno reporte nivel de señal (Signal) y calidad (SNR) estables, no solo "lock". Un tuner puede reportar lock con señal marginal y perder el servicio en cuanto llueve.
4. Mapear los servicios encontrados a canales lógicos, evitando duplicados cuando el mismo canal aparece en más de un transpondedor (algo común que los operadores hacen a propósito como redundancia propia).

Escaneo de muxes: terrestre (DVB-T)

El escaneo DVB-T sigue una lógica más simple porque no hay LNB ni polaridad que configurar — solo frecuencia y ancho de banda del canal terrestre. Los pasos prácticos:

• Cargar la red DVB-T correspondiente al país de emisión (los planes de frecuencias terrestres varían por región, y usar el preset equivocado hace que el escaneo tarde mucho y encuentre poco).
• Correr un escaneo completo de la banda UHF/VHF relevante la primera vez, para descubrir todos los multiplex disponibles.
• Una vez identificados los multiplex útiles, fijarlos como muxes conocidos y desactivar el escaneo automático recurrente — reescanear toda la banda periódicamente consume tiempo de tuner que debería estar sirviendo streams.

La ventaja de la captación terrestre sobre la satelital es que es menos sensible al clima; la desventaja es que depende de la cobertura geográfica real del transmisor, así que la ubicación física del servidor (o de la antena que alimenta la señal hasta él) importa tanto como la configuración de software.

Reparto de tuners entre streams concurrentes

Este es el punto donde "multi-tuner" deja de ser una especificación de hardware y se convierte en un problema de configuración. TVHeadend gestiona la asignación de sintonizadores a través de subscriptions: cada vez que algo pide un servicio (un stream HTTP hacia Flussonic, una grabación DVR), TVHeadend decide qué tuner físico usar según prioridad y disponibilidad.

Con varios canales viviendo en el mismo transpondedor, un único tuner sintonizado a ese mux puede servir todos esos canales simultáneamente sin gastar un tuner por canal — es la razón por la que agrupar bien los muxes reduce la cantidad de hardware necesario. Pero cuando dos canales que interesan viven en transpondedores distintos, hacen falta dos tuners distintos sintonizados en paralelo, y ahí es donde la cantidad de sintonizadores por tarjeta se vuelve el límite físico real del sistema.

Configurar bien las prioridades de subscription evita el error más común en producción: que una grabación de baja prioridad ocupe el último tuner libre y bloquee un canal en vivo que un cliente está pidiendo en ese momento. La regla práctica que aplicamos es simple — todo lo que sirve streams en vivo hacia Flussonic tiene prioridad más alta que cualquier tarea de grabación o análisis interno.

Exponer los streams hacia Flussonic

Cada canal capturado por TVHeadend queda disponible como stream MPEG-TS accesible por HTTP dentro de la red interna. Flussonic se configura para consumir esas URLs como fuentes de entrada (input), una por canal. Dos prácticas que evitan dolores de cabeza después:

• Usar nombres de canal consistentes entre TVHeadend y la configuración de Flussonic (mismo identificador, sin depender de que alguien recuerde qué "Channel 14" corresponde a qué canal real).
• Configurar el timeout de reconexión de Flussonic hacia TVHeadend de forma agresiva pero no instantánea — un corte de un par de segundos en el mux no debería disparar una cascada de reconexiones que satura el tuner.

Errores que más tiempo cuestan en producción

1. Tuner en "lock" pero sin datos útiles

Un tuner puede reportar señal bloqueada (lock) y aun así no entregar servicios descifrables, típicamente porque la smart card del operador —montada en su lector USB legítimo— no está autorizando el canal, o porque el CAM (Conditional Access Module) perdió comunicación. El síntoma en TVHeadend es "lock" verde pero cero bitrate útil en el servicio. La revisión va primero al módulo de acceso condicional, no al tuner.

2. Reordenamiento de adaptadores tras un reinicio

Sin reglas udev fijas, el sistema operativo puede asignar /dev/dvb/adapter0 y adapter1 en orden distinto después de cada reinicio. TVHeadend sigue apuntando a la configuración anterior por número de adaptador, y el resultado es que canales que antes venían de satélite de golpe intentan sintonizar por el adaptador terrestre. Fijar las rutas por número de serie o puerto físico del bus elimina esta clase de bug.

3. Muxes que se mueven sin aviso

Los operadores reubican transpondedores. Cuando eso pasa, el canal simplemente desaparece del mux configurado — no hay error explícito, solo un servicio que deja de recibir datos. Vale la pena mantener un monitoreo activo por canal (no solo por tuner) que alerte cuando un servicio lleva más de N minutos sin bitrate, independientemente de si el mux sigue en "lock".

4. Escaneo automático corriendo en horario de producción

Dejar activado el reescaneo periódico de toda una banda en un tuner que también está sirviendo canales en vivo es un error fácil de cometer y caro de sufrir — el escaneo ocupa el tuner completo y corta el servicio en vivo mientras dura. Una vez identificados los muxes útiles, el escaneo recurrente se apaga y se reemplaza por verificación puntual manual o programada fuera de horas pico.

Checklist antes de dar por lista la capa de captación

• Cada adaptador tiene ruta fija por udev, no depende del orden de enumeración del kernel.
• La lista de muxes está actualizada contra la programación real del operador, no solo el preset por defecto.
• Señal y SNR se monitorean de forma continua, no solo durante el escaneo inicial.
• Las prioridades de subscription garantizan que un stream en vivo nunca pierde su tuner frente a una grabación.
• El reescaneo automático de banda completa está desactivado en tuners de producción.
• Hay alertas por canal (bitrate en cero) además de alertas por tuner (lock perdido) — son fallas distintas con causas distintas.

Cierre

La capa de captación no es la parte que se enseña en una demo, pero es la que decide si el resto de la cabecera —procesamiento, EPG, portal— tiene algo confiable con qué trabajar. Configurarla bien es una combinación de conocer el hardware, entender cómo un operador satelital o terrestre organiza sus transpondedores, y construir el monitoreo que avisa antes de que el cliente final note algo.

Si estás evaluando montar o auditar la capa de captación de una plataforma de streaming, hablemos.