Programación Radial Basada en Reglas y NO en Horarios

Cuando montamos la estructura de La MIX Radio, cometimos el error clásico de diseñar una parrilla rígida.
Teníamos bloques fijos: Deep House de 10 a 12 y Electro Swing de 12 a 14.
El problema es que la radio no es un reloj suizo y la vida real interfiere.
Si un set se alargaba o queríamos cambiar el ánimo según el clima o la hora del día, el sistema de horarios nos obligaba a editar manualmente cada evento.
Fue ahí donde decidimos migrar hacia una programación radial basada en reglas.

Por qué importa para una radio independiente

Operar una radio las 24 horas del día nos enseñó que el horario es una cárcel para el contenido.
En una emisora independiente, no tenemos un equipo de diez personas coordinando cada entrada y salida.
Somos nosotros, el servidor en Proxmox y los scripts de Python.
Si dependemos de un calendario estricto, cualquier fallo en la carga de un archivo o un corte de luz en la VM deja un hueco negro en la emisión.

Al cambiar la lógica, dejamos de pensar en «qué suena a las 15:00» para pensar en «qué debe sonar si es lunes por la tarde».
Esto nos da una flexibilidad enorme. Si decidimos que el Electro Swing debe sonar más tiempo los viernes, no cambiamos el calendario de todo el mes.
Simplemente ajustamos una regla de prioridad en el sistema.
Esta libertad permite que la radio se sienta orgánica y no como una lista de reproducción pregrabada que se repite mecánicamente.

Además, este enfoque reduce el estrés técnico.
Ya no tenemos que preocuparnos por si el script de automatización se desincronizó por cinco minutos.
Las reglas se evalúan en tiempo real, por lo que el flujo musical siempre es coherente con el contexto actual, sin importar los retrasos técnicos que puedan surgir en el homelab.

Cómo lo aplicamos en la práctica

En nuestro caso, dejamos de usar el programador tradicional y empezamos a usar scripts de Python que consultan variables de entorno y el estado del servidor.
En lugar de una tabla de horarios, creamos un sistema de «etiquetas de contexto».
Por ejemplo, definimos etiquetas como #energia_baja para las mañanas y #energia_alta para el prime time de Deep House.

Para gestionar esto, integramos n8n en el flujo. n8n actúa como el cerebro que evalúa la regla: si es fin de semana y la temperatura en Madrid supera los 25 grados, el sistema prioriza el Electro Swing más rítmico.
Esta información se envía a través de un webhook al gestor de playlists que corre en nuestra infraestructura.
Así, la música se adapta al entorno sin que nosotros tengamos que tocar un solo botón.

Otro ejemplo concreto es la integración con Emily, nuestra voz sintetizada mediante gTTS en la VM.
En lugar de programar la cuña de «estás escuchando La MIX Radio» cada hora exacta, creamos una regla de frecuencia.
La regla dice: «insertar identificador cada 4 canciones, siempre y cuando no haya pasado menos de 30 minutos desde la última vez».
Esto evita que el oyente escuche el mismo anuncio dos veces si el set musical es muy corto.

La programación radial basada en reglas nos permite pasar de ser operadores de un reloj a ser curadores de una experiencia sonora que reacciona al entorno.

Lo que funciona y lo que NO

No todo fue sencillo en este proceso.
Al principio, cometimos el error de crear demasiadas reglas contradictorias. Teníamos una regla que decía «poner Deep House los martes» y otra que decía «si es tarde, poner Electro Swing».
El resultado fue que el sistema entraba en un bucle o elegía siempre la misma canción porque ambas reglas tenían la misma prioridad.
Tuvimos que implementar un sistema de pesos numéricos para resolver los conflictos.

Lo que realmente funciona es mantener las reglas simples y jerarquizadas. Primero evaluamos el día, luego la franja horaria y finalmente el género.
De esta manera, el sistema siempre tiene una respuesta clara.
También aprendimos que es fundamental tener una «regla de emergencia» o fallback.
Si ninguna de las reglas complejas se cumple, el sistema debe recurrir a una carpeta de música general para que la radio nunca se quede en silencio.

Por otro lado, descubrimos que confiar ciegamente en la automatización es peligroso.
Aunque las reglas funcionan, dejamos un margen para la intervención manual.
A veces, queremos romper todas las reglas para hacer un especial en vivo.
Para eso, creamos un «interruptor de prioridad» en nuestro panel que desactiva las reglas automáticas y nos da el control total del stream de Icecast.

Herramientas que usamos

Para llevar a cabo este sistema, no necesitamos software costoso, sino herramientas que se hablan entre sí.
El corazón de todo es nuestro homelab en Proxmox, donde aislamos los procesos para que un fallo en la automatización no tire el servidor de streaming.

Usamos Python para la lógica de selección de archivos y la gestión de etiquetas. Para la orquestación y los disparadores externos, n8n es la pieza clave, ya que nos permite conectar datos externos (como el clima o la hora) con la radio.
El audio final se distribuye mediante Icecast, mientras que nginx gestiona las peticiones web y el acceso a las interfaces de control.

Para las voces automáticas, dependemos de gTTS ejecutándose en la VM, lo que nos permite generar anuncios dinámicos basados en las mismas reglas que rigen la música.
Todo esto se monitorea mediante un bot de Telegram que nos avisa si el sistema de reglas ha fallado y ha tenido que saltar al modo de emergencia.

Para cerrar: qué hacer esta semana

Si sientes que tu parrilla de horarios es una carga, no intentes cambiar todo de golpe.
Esta semana, elige un solo bloque de tu programación y conviértelo en una regla.

Por ejemplo, en lugar de programar una lista fija para los lunes, crea una carpeta de «Lunes Motivadores» y configura tu sistema para que elija canciones al azar de esa carpeta siempre que sea lunes entre las 8 y las 10.
Verás que la fluidez mejora y el trabajo manual disminuye.