Si ton guide de chaînes IPTV affiche les bons programmes mais les mauvais horaires — chaque émission décalée d'une ou deux heures par rapport à sa diffusion réelle — tu tombes sur l'un des bugs XMLTV les plus tenaces qu'on croise. Le correctif tient en général en une modification d'URL. Diagnostiquer dans quel sens décaler prend cinq minutes.

Ce guide explique où se loge le bug, comment trouver l'offset qu'il te faut, et comment l'appliquer. Le décaleur de fuseau horaire EPG de ce site fait le décalage proprement dit ; cet article explique comment l'utiliser correctement.

Deux lignes de temps : la ligne « heure réelle » marque BBC News à 18 h ; la ligne EPG montre le même programme à 16 h, puis un décalage animé de +2 h vient l'aligner sur l'heure réelle.

Même programme, deux horloges : l'EPG est en retard de deux heures sur l'heure réelle jusqu'à ce que le décaleur le réaligne.

Pourquoi les bugs de fuseau horaire XMLTV existent

XMLTV est un format vieux de 25 ans. Chaque programme a un attribut start et stop qui ressemble à ça :

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

Les 14 chiffres sont l'heure murale ; le +0000 à la fin est le décalage horaire de cette heure murale. Donc 20260507180000 +0000 veut dire « 18 h UTC, le 7 mai 2026 ». Le lecteur lit les deux, convertit dans ton fuseau local, et affiche « 20 h » si tu es en heure d'hiver française.

Ça marche si le fichier XMLTV est cohérent en interne. Mais le XMLTV est généré par une longue chaîne de programmes :

  1. Le système de programmation du diffuseur d'origine, dans son fuseau local.
  2. Un agrégateur régional qui convertit peut-être dans un fuseau régional.
  3. Le scraper du fournisseur IPTV, qui arrondit probablement encore.
  4. L'exportateur XMLTV de ton fournisseur, qui colle un +0000 à la fin que les chiffres soient réellement en UTC ou pas.

N'importe laquelle de ces étapes peut introduire une erreur de fuseau, et le format ne fournit aucune somme de contrôle. Le fichier produit a l'air bien formé. Le lecteur ne peut pas détecter que les chiffres ne correspondent pas au décalage déclaré. Résultat : un guide tranquillement faux de quelques heures entières.

Un deuxième genre de bug, c'est quand le fichier XMLTV omet complètement le décalage :

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

Sans le décalage, le lecteur doit deviner. La plupart des lecteurs supposent « les chiffres sont à ton heure locale » ; d'autres supposent UTC. Si le fournisseur pensait UTC et que ton lecteur suppose local, chaque programme est décalé de ton offset local.

Dans les deux cas, la donnée de base est correcte — il faut juste ajouter ou retrancher un certain nombre d'heures pour que tout tombe juste.

Trouver le bon décalage

Le correctif, c'est « ajouter N heures à chaque horodatage du fichier XMLTV ». Pour choisir N :

Étape 1 : choisis une chaîne dont tu connais le programme actuel

Ouvre ton lecteur. Trouve une chaîne qui passe un direct dont tu sais ce que c'est — le journal régional de 19 h, la météo en tête d'heure, une émission de prime time sur une grande chaîne. L'idée, c'est d'avoir un repère sûr : « cette chaîne diffuse X maintenant, à cette heure exacte selon ma montre ».

Étape 2 : regarde ce que dit l'EPG

Regarde l'entrée « en cours » de cette même chaîne dans ton lecteur. Note l'heure de début qu'il annonce. S'il dit que l'émission a commencé à 17 h alors qu'elle a démarré à 19 h, l'EPG est en retard de deux heures — il faut ajouter 2 à chaque horodatage.

Si l'EPG indique que l'émission « commence dans deux heures » alors qu'elle est diffusée maintenant, l'EPG est en avance de deux heures — il faut retrancher 2.

Étape 3 : confirme que le décalage est le même sur plusieurs chaînes

Choisis une deuxième puis une troisième chaîne et vérifie que le décalage est cohérent. Si la chaîne A est décalée de +2 et la B de -3, ce n'est pas un problème de fuseau ; ce sont des données incohérentes par chaîne et un décalage fixe ne corrigera pas les deux. (L'incohérence multi-chaînes est rare et signifie en général que le fournisseur a fusionné des flux de plusieurs sources sans harmoniser les fuseaux — le seul correctif, c'est de lui demander de nettoyer ses données.)

Dans 95 % et plus des cas, le décalage est cohérent sur toutes les chaînes et vaut : ±1, ±2, ±3, parfois ±5 ou ±8 pour les utilisateurs très éloignés de la source du flux d'origine.

Appliquer le décalage

Une fois que tu connais le décalage, l'outil de décalage te fournit une nouvelle URL qui diffuse le XMLTV de ton fournisseur avec chaque horodatage décalé d'exactement ce montant. Remplace l'URL EPG de ton lecteur par la nouvelle et les horaires du guide s'alignent.

Deux points pratiques :

  • Le décaleur est un proxy, pas un coup unique. Ton lecteur rafraîchit l'EPG toutes les quelques heures. À chaque rafraîchissement, on récupère à nouveau le XMLTV de ton fournisseur à travers le décaleur et on réapplique le décalage. Aucun cache de notre côté ; la donnée faisant foi reste celle de la source, juste avec les heures bougées.
  • Tes identifiants se trouvent dans l'URL. La plupart des fournisseurs IPTV servent le XMLTV à une URL du type http://serveur/xmltv.php?username=...&password=.... Le décaleur lit ces identifiants uniquement au moment de la requête pour aller chercher la source — il ne les journalise pas, ne les met pas en cache, ne les indexe pas. La query string est aussi retirée avant que nos logs d'accès soient écrits.

Ce que le décaleur ne corrige pas

Quelques problèmes voisins ressemblent à des bugs de fuseau mais n'en sont pas :

Les programmes décrochent et reviennent en place

Si l'EPG est parfois juste et parfois pas, ce n'est pas un problème de fuseau. Pistes possibles :

  • Les données du fournisseur sont vieilles. Les entrées plus anciennes sont rafraîchies à un rythme lent ; les plus récentes viennent d'un flux plus frais. Les deux flux peuvent être dans des fuseaux différents, mélangés dans le même XMLTV. Difficile à corriger sans coopération du fournisseur.
  • L'heure d'été. Si ton fuseau local observe le changement d'heure mais pas le XMLTV du fournisseur (ou l'inverse), le décalage change d'une heure deux fois par an. Un décalage fixe ne marche que pour la moitié de l'année pour laquelle tu le calibres.

Pour le passage à l'heure d'été en particulier, tu peux garder deux URLs décalées — une pour chaque moitié de l'année — et changer la source EPG du lecteur deux fois par an. Pénible, mais ça marche.

Le guide est vide, pas faux

Un guide « aucune info » / vide, c'est un autre problème. Va voir comment corriger un EPG qui ne se charge pas — la cause y est en général un décalage entre les tvg-id de la playlist et ceux du XMLTV, pas le fuseau.

Certaines chaînes sont fausses mais la plupart sont bonnes

Si tout le reste est juste et que seules une ou deux chaînes décalent, les données sources de ces chaînes sont fausses côté fournisseur. Le décalage fixe cassera les bonnes pour réparer les mauvaises. Soit tu demandes au fournisseur de corriger ses données, soit tu acceptes que les horaires de ces chaînes-là restent approximatifs.

Pourquoi on ne détecte pas l'offset automatiquement

Le décaleur prend l'offset en paramètre explicite plutôt que d'essayer de le deviner. On pourrait, en théorie, récupérer le fichier, comparer les heures de début des programmes à « maintenant » et estimer. On ne le fait pas parce que :

  • La « bonne réponse » dépend de la chaîne sur laquelle tu t'ancres. Différentes chaînes pourraient être en désaccord.
  • Une mauvaise estimation automatique est pire que de demander. Si on décale silencieusement de la mauvaise valeur, tu obtiens un guide systématiquement faux d'une autre valeur, et tu perdras du temps à debug.
  • L'utilisateur a le contexte. Il sait « le JT de 20 h sur France 2 est affiché à 18 h dans le guide ». L'outil peut appliquer cette info en un clic ; la déduire par observation réseau n'est pas fiable.

Après le correctif

Re-vérifie en repassant à l'étape 1 ci-dessus : chaîne connue, programme en cours, regarde l'heure « en cours » dans le lecteur. Elle doit maintenant correspondre à ta montre. Si c'est le cas, le correctif est permanent — ton lecteur va continuer à se rafraîchir via l'URL du décaleur et le décalage reste appliqué.

S'il reste autre chose qui cloche (chaînes non décalées, IDs qui ne correspondent pas, trous dans la couverture), ce sont des problèmes distincts et l'étape suivante est de passer par le validateur EPG. Le validateur parse un fichier XMLTV et signale les problèmes structurels indépendamment de l'heure — utile quand tu veux savoir « est-ce que le fichier lui-même est bien formé » plutôt que « est-ce que les horaires sont bons ».

Pour tout le reste côté IPTV, le vérificateur d'identifiants Xtream et le testeur de playlist M3U couvrent les soucis de playlist et d'identifiants. Avec le décaleur de fuseau, ces quatre outils règlent la plupart des diagnostics que les gens finissent par faire dans le brouillard sur les forums.