Si la guía de canales de tu IPTV muestra los programas correctos pero las horas equivocadas —cada emisión desplazada una o dos horas respecto a cuando realmente se emite—, estás topando con uno de los fallos XMLTV más tercos y comunes que hay. El arreglo suele ser un cambio de URL de una sola línea. Diagnosticar en qué dirección desplazar lleva unos cinco minutos.

Esta guía explica dónde está el fallo realmente, cómo averiguar el offset que necesitas y cómo aplicarlo. El desplazador de zona horaria de EPG de este sitio hace el desplazamiento; este artículo explica cómo usarlo bien.

Dos líneas de tiempo: la fila del reloj de pared marca BBC News a las 18:00; la fila de la EPG muestra el mismo programa a las 16:00 y luego anima un desplazamiento de +2 horas para alinearse con el reloj de pared.

Mismo programa, dos relojes: la EPG va dos horas por detrás del reloj de pared hasta que el desplazador la realinea.

Por qué pasan los fallos de zona horaria en XMLTV

XMLTV es un formato con 25 años a las espaldas. Cada programa tiene un atributo start y stop con esta pinta:

<programme start="20260507180000 +0000" stop="20260507190000 +0000" channel="bbc1">

Los 14 dígitos son la hora de pared; el +0000 del final es el offset de zona horaria en el que está esa hora. Así que 20260507180000 +0000 significa "18:00 UTC del 7 de mayo de 2026". El reproductor lee los dos, lo convierte a tu zona horaria local y muestra "20:00" si estás en CET.

Esto funciona si el archivo XMLTV es internamente coherente. Pero el XMLTV lo genera una larga cadena de programas:

  1. El sistema de programación de la cadena original, en su zona horaria local.
  2. Un agregador regional que quizá convierta a una zona regional.
  3. El scraper del proveedor IPTV, que probablemente redondea otra vez.
  4. El exportador XMLTV de tu proveedor, que le pega un +0000 al final tanto si los dígitos están realmente en UTC como si no.

Cualquiera de estos pasos puede meter un error de zona horaria, y el formato no incluye ninguna suma de comprobación. El archivo de salida parece bien formado. El reproductor no puede detectar que los dígitos de dentro no concuerdan con el offset declarado. El resultado es una guía equivocada con plena seguridad por un número entero de horas.

Un segundo tipo de fallo es cuando el archivo XMLTV omite el offset directamente:

<programme start="20260507180000" stop="20260507190000" channel="bbc1">

Sin offset, el reproductor tiene que adivinar. La mayoría asume que "los dígitos están en tu hora local"; algunos asumen UTC. Si el proveedor pretendía UTC y tu reproductor asume local, cada programa estará desplazado tu offset local.

En ambos casos los datos subyacentes son correctos: a los números solo hay que sumarles o restarles algo para que caigan donde deben.

Averiguar qué offset necesitas

El arreglo es "suma N horas a cada marca de tiempo del archivo XMLTV". Para elegir N:

Paso 1: elige un canal del que sepas qué hay ahora mismo

Abre el reproductor. Busca un canal que esté emitiendo en directo algo que conozcas: el telediario local a las 21:00, el informativo de TVE a en punto, el prime time de una cadena grande. La idea es tener un ancla conocida: "este canal está emitiendo X ahora mismo, a esta hora exacta según mi reloj".

Paso 2: mira qué dice la EPG

Mira la entrada de "en emisión" de ese mismo canal en el reproductor. Anota la hora de inicio que afirma. Si dice que el programa empezó a las 19:00 pero en realidad empezó a las 21:00, la EPG va dos horas por detrás: tienes que sumar 2 a cada marca de tiempo.

Si la EPG indica que el programa "empieza en dos horas" pero está emitiéndose ya, la EPG va dos horas por delante: tienes que restar 2.

Paso 3: confirma el mismo offset en varios canales

Elige un segundo y un tercer canal y comprueba que el offset es coherente. Si el canal A está a +2 y el canal B a -3, no tienes un problema de zona horaria; tienes datos incoherentes por canal y un desplazamiento fijo no va a arreglar ambos. (La incoherencia entre canales es rara y suele significar que el proveedor ha mezclado feeds de varias fuentes sin armonizar las zonas horarias; el único arreglo ahí es pedirle al proveedor que limpie sus datos.)

En más del 95% de los casos el offset es coherente para todos los canales y el valor es uno de: ±1, ±2, ±3, a veces ±5 o ±8 para usuarios en zonas horarias muy alejadas del feed de origen del proveedor.

Aplicar el desplazamiento

Una vez que sabes el offset, el desplazador te da una URL nueva que entrega el XMLTV de tu proveedor con cada marca de tiempo desplazada exactamente esa cantidad. Sustituye la URL de EPG de tu reproductor por la nueva y las horas de la guía cuadran.

Dos puntos prácticos:

  • El desplazador es un proxy, no algo de un solo uso. Tu reproductor refresca la EPG cada pocas horas. Cada refresco vuelve a descargar el XMLTV de tu proveedor a través del desplazador y aplica de nuevo el offset. No hay caché por nuestra parte; los datos autoritativos del proveedor siguen mandando, solo que con las horas corregidas.
  • Tus credenciales van en la URL. La mayoría de proveedores IPTV entregan XMLTV en una URL del tipo http://server/xmltv.php?username=...&password=.... El desplazador lee esas credenciales solo en el momento de la petición para descargar el origen: no las registra, no las cachea, no las indexa. Además, la cadena de consulta se elimina antes de escribir nuestros logs de acceso.

Lo que el desplazador no arregla

Hay algunos problemas vecinos que parecen fallos de zona horaria pero no lo son:

Los programas entran y salen de sincronía

Si la EPG a veces está bien y a veces no, no estás ante un problema de zona horaria. Posibilidades:

  • Los datos del proveedor están rancios. Las entradas de programa más antiguas se refrescan con poca frecuencia; las más nuevas vienen de un feed más fresco. Los dos feeds pueden estar en zonas horarias distintas, mezclados en el mismo XMLTV. Difícil de arreglar sin colaboración del proveedor.
  • El cambio de hora. Si tu zona horaria local aplica horario de verano pero el XMLTV del proveedor no (o al revés), el offset cambia una hora dos veces al año. Un desplazamiento de offset fijo solo funciona para la mitad del año para la que lo calibres.

Para los problemas de cambio de hora en concreto puedes mantener dos URLs desplazadas —una para cada mitad del año— y cambiar la fuente de EPG del reproductor dos veces al año. Es engorroso, pero funciona.

La guía está vacía, no equivocada

"Sin información" o guía en blanco es otro problema. Mira cómo arreglar que la EPG no cargue: ahí la causa suele ser una incoherencia de tvg-id entre la lista y el XMLTV, no la zona horaria.

Algunos canales concretos están mal pero la mayoría bien

Si todo lo demás está bien y solo uno o dos canales están desplazados, los datos de origen de esos canales están mal en el lado del proveedor. El desplazamiento fijo estropeará los canales que están bien para arreglar los que están mal. O le pides al proveedor que arregle los datos, o asumes que las horas de esos canales concretos serán aproximadas.

Por qué no detectamos el offset automáticamente

El desplazador acepta el offset como un parámetro explícito en lugar de intentar deducirlo. Podríamos, en teoría, descargar el archivo, comparar las horas de inicio con "ahora" y adivinar. No lo hacemos porque:

  • La "respuesta correcta" depende del canal que tomes como ancla. Distintos canales podrían no coincidir.
  • Un autodetección equivocada es peor que preguntar. Si desplazamos en silencio una cantidad equivocada, tendrás una guía coherentemente equivocada por otro valor y perderás tiempo depurando.
  • El contexto lo tiene el usuario. Sabe que "el informativo de las 18:00 de la BBC One sale ahora mismo como las 16:00 en la guía". La herramienta puede aplicar ese conocimiento en un clic; deducirlo observando la red no es fiable.

Después del arreglo

Verifica con una pasada más del Paso 1 de arriba: canal conocido, programa actual, mira la hora "en emisión" en el reproductor. Debería coincidir ya con el reloj de pared. Si lo hace, el arreglo es permanente: tu reproductor seguirá refrescando a través de la URL del desplazador y el offset se sigue aplicando.

Si sigue habiendo algo mal (canales que no se han desplazado, IDs que no coinciden, lagunas de cobertura), son problemas distintos y el siguiente paso es apuntar al validador de EPG. El validador parsea un archivo XMLTV y reporta problemas estructurales independientes del horario: útil cuando quieres saber "¿el archivo está bien formado?" en lugar de "¿las horas son correctas?".

Para todo lo demás del lado IPTV, el comprobador de credenciales Xtream y el comprobador de listas M3U cubren los bordes de la lista y las credenciales. Junto con el desplazador de zona horaria, esas cuatro herramientas resuelven la mayor parte del troubleshooting que la gente acaba haciendo a ciegas en los foros.