Detección automática de caídas de audio en streams Icecast

Quienes llevamos más de tres décadas viendo cómo la radio evolucionaba desde las bobinas abiertas y los cartuchos hasta el streaming digital, sabemos que hay algo que no cambia: el pánico al silencio. En mis años de oficio, he aprendido que el aire es sagrado.
Pero en el mundo del audio IP, el enemigo es más traicionero que un transmisor de válvulas; a veces el servidor parece estar vivo, pero el audio simplemente no fluye.

En este artículo, no te voy a contar una teoría de manual. Te voy a mostrar cómo implementar un sistema de monitoreo proactivo para Icecast, nacido de la necesidad de no tener que estar pegado al monitor para saber si tu radio está sonando.

El engaño del «Servidor Online»

Uno de los mayores dolores de cabeza que he enfrentado es el «falso positivo». Icecast es una roca, un software muy estable, pero es solo un transporte. El problema suele estar en el Source (el codificador).

He visto decenas de veces cómo el proceso icecast2 sigue corriendo perfectamente en Linux, pero el flujo de datos desde el estudio se ha cortado o el codificador se ha quedado en un bucle infinito de silencio. Para el servidor, «todo está bien».
Para el oyente, la radio ha muerto. Por eso, no nos basta con saber si el puerto 8000 está abierto; necesitamos verificar el payload, el contenido real.

Estrategia de detección: El enfoque de la vieja escuela en el código moderno

En la radio tradicional, usábamos un «pisasilencios» físico conectado a la salida de la consola. Aquí vamos a hacer lo mismo mediante un script que actúe como un centinela.

1. La lógica del chequeo (Check-Sum técnico)

La forma más robusta de hacer esto sin cargar la CPU del servidor es realizar una descarga parcial real del stream. No queremos descargar todo el contenido constantemente, sino capturar los primeros kilobytes de datos: si llegan bytes del audio, el stream está vivo.
Un simple chequeo de cabeceras HTTP con curl -sI no es suficiente; Icecast puede devolver 200 OK incluso cuando el source se desconectó, dependiendo de la versión y configuración. Necesitamos verificar que hay payload real fluyendo.

2. Implementación del Script de Vigilancia

Aquí te comparto la lógica que yo utilizo. Es un script ligero, diseñado para ser ejecutado mediante un Cron Job cada minuto. La veteranía me ha enseñado que lo más simple es lo que menos falla cuando las papas queman.

#!/bin/bash

# Configuración: Aquí defines tu realidad técnica
URL_STREAM="http://tu-servidor.com:8000/tu_punto_de_montaje"
TIMEOUT=15
INTENTOS=3
BYTES_MINIMOS=4096  # Si no llegan al menos 4KB, el stream no está fluyendo

# La lógica: No basta con una caída momentánea, buscamos persistencia
for i in $(seq 1 $INTENTOS); do
    BYTES=$(curl -s --max-time $TIMEOUT -r 0-8191 "$URL_STREAM" 2>/dev/null | wc -c)
    if [ "$BYTES" -ge "$BYTES_MINIMOS" ]; then
        # Los datos fluyen, el aire está vivo
        exit 0
    fi
    sleep 5
done

# Si llegamos aquí, el silencio es real. Es hora de actuar.
BOT_TOKEN="tu_token_aqui"
CHAT_ID="885663435"
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id="$CHAT_ID" \
    -d text="⚠️ El stream $URL_STREAM no entrega audio después de $INTENTOS intentos."

La diferencia clave respecto a un simple curl -sI es que aquí pedimos los primeros 8KB del stream con -r 0-8191 y contamos los bytes que llegaron. Bitrate de 128kbps significa que en 15 segundos deberían llegar varios megabytes; si solo llegaron 0 o unos pocos bytes, el source está muerto aunque Icecast siga respondiendo.

3. El ajuste del «Timeout»: Donde manda la experiencia

Aquí es donde se nota quién ha estado en la trinchera y quién no. Si pones un tiempo de respuesta de 2 segundos, internet te va a volver loco con falsas alarmas. En mis pruebas de campo, he determinado que 15 a 20 segundos es el margen de seguridad ideal.
Es el tiempo que permite que un micro-corte de red se recupere solo sin despertarte con una notificación innecesaria a las 4 de la mañana.

Notificaciones inteligentes: Tu centro de control en el bolsillo

En mis inicios, si una repetidora se caía, la única forma de saberlo era que alguien en el pueblo llamara a la estación. Hoy, la automatización nos permite ser los primeros en enterarnos.

Integrar este script con un bot de Telegram o un webhook de Discord no es un lujo, es una necesidad profesional. Te permite ver la trazabilidad: ¿Se cae siempre a la misma hora? ¿Coincide con el backup del servidor? Esa información vale oro para diagnosticar problemas crónicos de estabilidad que un novato pasaría por alto.

¿Cómo configurarlo?

El script ya incluye el envío por Telegram directamente. Solo necesitás crear un bot con @BotFather, obtener el token y reemplazar los valores. El CHAT_ID es el identificador de la conversación o grupo donde querés recibir las alertas. Con eso, mientras estás cenando o en otra actividad, sabés que el «ojo» técnico está vigilando el aire por vos.

Escenarios de fallo que solo la experiencia te enseña

A lo largo de estos 30 años, he aprendido que el audio IP puede fallar por motivos absurdos. Este script te protegerá contra:

• Zombificación del Source: El codificador parece enviar datos, pero el socket está roto. El script lo detecta porque los bytes no llegan al umbral mínimo.
• Saturación de oyentes: Cuando el ancho de banda del servidor llega al límite y empieza a rechazar o entregar datos truncados.
• Fallas de DNS: Cuando el servidor está vivo, pero el dominio no resuelve correctamente. curl retorna 0 bytes y el script dispara la alerta.
• Source desconectado silencioso: El caso más traicionero. Icecast responde 200 OK pero no hay audio. Un chequeo de cabeceras lo pasaría por alto; este script no.

El siguiente nivel: El Auto-Healing (Autocuración)

Si querés llevar tu blog y tu radio al nivel máximo de profesionalismo, no te quedes solo en la alerta. Un administrador veterano sabe que si algo se puede arreglar solo, debe hacerse.

Podés ampliar el script para que, tras detectar la caída, intente reiniciar el servicio automáticamente antes de notificarte:

# Intento de autocuración antes de alertar
systemctl restart icecast2
sleep 10

# Verificamos si se recuperó
BYTES=$(curl -s --max-time $TIMEOUT -r 0-8191 "$URL_STREAM" 2>/dev/null | wc -c)
if [ "$BYTES" -ge "$BYTES_MINIMOS" ]; then
    # Se recuperó solo, notificamos con menos urgencia
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="✅ Stream $URL_STREAM tuvo una caída pero se recuperó automáticamente."
    exit 0
fi

# No se recuperó: alerta crítica
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id="$CHAT_ID" \
    -d text="🚨 CRÍTICO: Stream $URL_STREAM caído. Reinicio automático fallido. Intervención manual requerida."

Eso es lo que garantiza un 99.9% de uptime.

Reflexión Final

La radio es magia, pero la magia requiere una ingeniería invisible que la sostenga. Automatizar la detección de silencios en Icecast es honrar el oficio. Es asegurar que el esfuerzo que ponés tras el micrófono llegue siempre, sin interrupciones, al oído de quien te escucha.

Si este script te ahorra una sola noche de insomnio, habrá valido la pena escribir esto.
Si tenés una configuración específica o un error que te está sacando canas verdes, contámelo en los comentarios; después de tantas décadas, es probable que ya me haya peleado con ese mismo problema antes.