XMLTV est un format de données qui permet de décrire les programmes de télévision : noms des chaînes, titres des émissions, horaires et informations complémentaires. Dans un environnement IPTV, un lecteur compatible peut utiliser ces données pour construire un EPG (Electronic Program Guide), c’est-à-dire le guide électronique des programmes affiché à l’écran.
Il faut distinguer trois notions : XMLTV est le format des données, EPG est la fonction d’affichage et tvg-id est un identifiant utilisé dans certaines playlists M3U pour associer une chaîne à ses programmes.
Un fichier XMLTV ne contient pas les vidéos des émissions et ne fournit aucun droit d’accès aux chaînes. Il sert à décrire leur programmation.
Voici comment ces éléments fonctionnent ensemble, avec des exemples fictifs et des références techniques vérifiables.
À retenir
- XMLTV : format XML décrivant des chaînes et des programmes.
- EPG : guide des programmes affiché par un lecteur compatible.
- M3U : playlist contenant notamment des références vers des ressources média.
tvg-id: attribut utilisé dans certaines playlists M3U pour faciliter la correspondance avec XMLTV.- Lecteur multimédia : application qui interprète les données et construit l’interface du guide.
XMLTV IPTV : à quoi sert ce format ?
XMLTV est un format basé sur XML (Extensible Markup Language), un langage servant à représenter des données structurées.
Dans le cas de XMLTV, ces données décrivent principalement des chaînes et des diffusions de programmes.
Un fichier peut indiquer qu’une émission fictive commence à 20 h, se termine à 21 h, possède un certain titre et appartient à une chaîne identifiée.
Le lecteur peut ensuite utiliser ces informations pour présenter une grille horaire.
Ce que contient un fichier XMLTV
Selon les données disponibles, un fichier XMLTV peut contenir :
- les identifiants et noms des chaînes ;
- les titres des programmes ;
- leurs heures de début et éventuellement de fin ;
- leurs descriptions ;
- leurs catégories ;
- des informations linguistiques ou d’autres métadonnées.
Tous ces éléments ne sont pas obligatoires.
La structure exacte est décrite par la DTD officielle du projet XMLTV. Une DTD, ou Document Type Definition, définit notamment les éléments et attributs autorisés dans un document XML.
Ce que XMLTV ne contient pas
Le format XMLTV n’est pas destiné à transporter directement les vidéos des chaînes.
Il ne garantit pas non plus qu’une ressource média fonctionne, qu’une émission est disponible à la lecture ou que son utilisateur dispose des droits nécessaires.
Une grille de programmes peut être présente alors que la ressource vidéo est inaccessible.
Inversement, un média peut être lisible sans qu’aucune donnée de programmation soit disponible.
XMLTV et EPG : deux notions distinctes
La différence peut être résumée ainsi :
| Terme | Définition | Rôle |
|---|---|---|
| XMLTV | Format de données XML | Décrire les programmes et leurs métadonnées |
| EPG | Guide électronique des programmes | Présenter les émissions et horaires à l’utilisateur |
| M3U | Format de playlist texte | Référencer des ressources média |
tvg-id | Convention d’attribut dans certaines playlists M3U | Faciliter l’association avec une chaîne du guide |
| Lecteur IPTV | Logiciel de lecture multimédia | Interpréter les ressources compatibles et afficher l’interface |
Un EPG n’utilise pas nécessairement XMLTV. XMLTV est une manière courante de fournir des données de guide, mais la fonction EPG n’est pas limitée à ce seul format.
Comment M3U et XMLTV fonctionnent ensemble
Pour afficher une grille de programmes, le lecteur doit savoir à quelle chaîne correspondent les données reçues.
Cela nécessite de distinguer plusieurs composants.
Le rôle de la playlist M3U
Une playlist M3U décrit des entrées et les ressources auxquelles elles correspondent.
Dans une playlist étendue, une entrée peut également contenir des métadonnées comme un nom affiché ou un identifiant tvg-id.
La playlist ne contient pas nécessairement les horaires des émissions.
Pour approfondir les différents types de playlists, consultez notre article M3U vs M3U8 : différences, UTF-8 et HLS.
Le rôle du fichier XMLTV
Le document XMLTV constitue une source de données supplémentaire.
Il peut décrire une chaîne nommée « Chaîne Exemple A » ainsi que les programmes qui lui sont associés.
Chaque programme référence un identifiant de chaîne.
Le rôle du lecteur
Un lecteur compatible peut effectuer plusieurs opérations :
- Charger la playlist M3U.
- Charger les données XMLTV.
- Identifier les correspondances entre les chaînes et les programmes.
- Interpréter les horaires.
- Construire le guide affiché à l’utilisateur.
Le comportement exact dépend du logiciel. Certaines applications proposent une association manuelle des chaînes, tandis que d’autres utilisent des règles automatiques.
Schéma de fonctionnement :
PLAYLIST M3U
Nom de chaîne + tvg-id
│
│
▼
LECTEUR MULTIMÉDIA
▲
│
│
FICHIER XMLTV
Chaînes + programmes + horaires
│
▼
CORRESPONDANCE DES DONNÉES
│
▼
GUIDE EPG
Programmes affichés à l'écran
La source du média, le format du fichier et l’affichage du guide sont trois responsabilités distinctes.
Comprendre la structure d’un fichier XMLTV
La définition officielle utilise trois éléments essentiels :
<tv>
<channel>
<programme>
Ils ne remplissent pas les mêmes fonctions.
L’élément racine <tv>
Un document XMLTV possède un élément racine <tv>.
Il contient les données de chaînes et de programmes.
La DTD décrit sa structure par la règle :
tv (channel*, programme*)
Cela signifie qu’un document peut comporter zéro ou plusieurs déclarations de chaînes, suivies de zéro ou plusieurs déclarations de programmes.
Cette précision est importante : la structure XMLTV autorise un document sans programme.
L’élément <channel>
Une déclaration de chaîne peut ressembler à ceci :
<channel id="exemple.a.fr">
<display-name lang="fr">Chaîne Exemple A</display-name>
</channel>L’attribut id sert à identifier la chaîne dans les données XMLTV.
Lorsque l’élément <channel> est présent, cet attribut est obligatoire, tout comme la présence d’au moins un élément <display-name> dans la déclaration.
L’élément <programme>
Un programme associe une diffusion à une chaîne et à un horaire.
Exemple :
<programme
start="20261023180000 +0000"
stop="20261023190000 +0000"
channel="exemple.a.fr">
<title lang="fr">Journal fictif</title>
<desc lang="fr">Émission pédagogique.</desc>
</programme>Cet extrait signifie que le programme fictif commence à 18 h UTC le 23 octobre 2026 et se termine à 19 h UTC.
Il est associé à la chaîne exemple.a.fr.
Champs XMLTV : lesquels sont obligatoires ?
Voici les principaux éléments décrits dans la DTD XMLTV.
| Élément ou attribut | Fonction | Statut dans la DTD |
|---|---|---|
<tv> | Racine du document | Obligatoire |
<channel> | Déclaration de chaîne | Facultatif dans le document |
id dans <channel> | Identifiant de chaîne | Obligatoire si <channel> est présent |
<display-name> | Nom de chaîne | Au moins un par <channel> |
<programme> | Programme diffusé | Facultatif dans le document |
start | Heure de début | Obligatoire dans <programme> |
stop | Heure de fin | Facultatif |
channel dans <programme> | Identifiant de la chaîne concernée | Obligatoire |
<title> | Titre du programme | Au moins un par <programme> |
<desc> | Description du programme | Facultatif |
lang dans <title> | Langue du titre | Facultatif |
Deux détails sont souvent mal expliqués : l’attribut stop n’est pas systématiquement obligatoire, et un fichier peut être conforme à la structure XMLTV sans contenir de programme.
Ces règles proviennent de la DTD XMLTV officielle.
Exemple d’un fichier XMLTV complet
Voici un exemple entièrement fictif :
<?xml version="1.0" encoding="UTF-8"?>
<tv>
<channel id="exemple.a.fr">
<display-name lang="fr">Chaîne Exemple A</display-name>
</channel>
<programme
start="20261023180000 +0000"
stop="20261023190000 +0000"
channel="exemple.a.fr">
<title lang="fr">Journal fictif</title>
<desc lang="fr">Émission pédagogique.</desc>
</programme>
<programme
start="20261023190000 +0000"
channel="exemple.a.fr">
<title lang="fr">Documentaire fictif</title>
</programme>
</tv>Le deuxième programme ne contient pas d’attribut stop.
Cela est permis par la DTD. Le logiciel qui présente la grille doit ensuite gérer cette information de fin absente selon son implémentation.
À retenir : la validité structurelle du fichier et la manière dont un lecteur affiche ses données sont deux questions différentes.
tvg-id : comment les programmes XMLTV sont associés aux chaînes
Le champ tvg-id est particulièrement important dans l’écosystème des playlists M3U étendues.
Mais il faut éviter une confusion : tvg-id n’est pas un attribut XMLTV défini dans la DTD officielle.
C’est une convention utilisée dans certaines playlists pour faciliter l’association entre une entrée et les données du guide.
Étape 1 — L’identifiant dans la playlist M3U
Prenons cette playlist fictive :
#EXTM3U
#EXTINF:-1 tvg-id="exemple.a.fr",Chaîne Exemple A
https://media.example.com/chaine-aLe lecteur peut identifier une entrée dont le tvg-id est :
exemple.a.fr
L’adresse est fictive et ne représente pas un flux réel.
Étape 2 — L’identifiant dans XMLTV
Le fichier XMLTV déclare :
<channel id="exemple.a.fr">
<display-name>Chaîne Exemple A</display-name>
</channel>La valeur de id correspond à celle de tvg-id.
Étape 3 — Le programme référence cette chaîne
L’élément suivant utilise le même identifiant :
<programme
start="20261023180000 +0000"
channel="exemple.a.fr">
<title>Programme Exemple</title>
</programme>On obtient donc trois niveaux :
M3U
tvg-id="exemple.a.fr"
│
▼
XMLTV
<channel id="exemple.a.fr">
│
▼
XMLTV
<programme channel="exemple.a.fr">
│
▼
PROGRAMME ASSOCIÉ À LA CHAÎNECette correspondance permet au lecteur de déterminer à quelle entrée de la playlist attribuer les horaires et les titres.
Que se passe-t-il si les identifiants diffèrent ?
Prenons cette fois :
Dans M3U :
tvg-id="exemple.a.hd"
Dans XMLTV :
id="exemple.a.fr"
Les valeurs ne sont pas identiques.
Un lecteur qui exige une correspondance exacte ne pourra pas associer directement ces deux identifiants.
Il peut cependant exister d’autres méthodes de correspondance.
La correspondance doit-elle toujours être exacte ?
Non, ce n’est pas une règle universelle.
La documentation de Kodi IPTV Simple Client décrit plusieurs mécanismes de recherche, notamment les identifiants et les noms des chaînes.
Kodi propose également une option permettant d’ignorer les différences de majuscules et minuscules lors de certaines correspondances EPG.
Source : Kodi IPTV Simple Client — documentation officielle.
Voici les distinctions utiles :
| Méthode | Exemple | Limite |
|---|---|---|
| Identifiant exact | exemple.a.fr = exemple.a.fr | Nécessite des valeurs cohérentes |
| Correspondance sans distinction de casse | EXEMPLE.A.FR et exemple.a.fr | Doit être prise en charge par le lecteur |
| Correspondance par nom | « Chaîne Exemple A » | Risque d’ambiguïté si plusieurs entrées portent des noms similaires |
| Association manuelle | L’utilisateur choisit une chaîne du guide | Fonctionnalité dépendante de l’application |
La présence de tvg-id améliore la précision de la correspondance lorsque cet identifiant est correctement utilisé.
Mais son absence n’empêche pas automatiquement tous les lecteurs d’afficher un guide.
Pourquoi les noms de chaînes ne suffisent pas toujours
Deux chaînes distinctes peuvent partager un nom affiché très proche.
Par exemple :
« Chaîne Exemple »
et
« Chaîne Exemple HD ».
Si un lecteur s’appuie sur les noms plutôt que sur des identifiants précis, il peut rencontrer une ambiguïté.
L’utilisation d’identifiants stables permet de réduire ce risque, à condition que les données restent cohérentes entre les deux fichiers.
Comment XMLTV représente les horaires
Les dates XMLTV sont indispensables à la construction d’une grille de programmes.
Elles permettent d’identifier le début et, lorsqu’elle est fournie, la fin d’une diffusion.
Lire l’attribut start
Considérons :
start="20261023180000 +0000"
Cette valeur représente :
- le 23 octobre 2026 ;
- à 18 h 00 ;
- avec un décalage UTC de
+0000.
Pour la France métropolitaine, cet instant correspond à 20 h 00, car le 23 octobre 2026 se situe encore dans la période d’heure d’été.
Heure d’hiver et heure d’été en France
En France métropolitaine, le fuseau Europe/Paris suit deux décalages principaux :
- UTC+1 en hiver ;
- UTC+2 en été.
Le passage à l’heure d’hiver en 2026 intervient le 25 octobre.
Voici quelques conversions pour comprendre le principe :
| Date | Heure indiquée en UTC | Heure locale à Paris |
|---|---|---|
| 15 janvier 2026 | 18:00 | 19:00 |
| 15 juillet 2026 | 18:00 | 20:00 |
| 23 octobre 2026 | 18:00 | 20:00 |
| 26 octobre 2026 | 18:00 | 19:00 |
Les règles de fuseaux horaires sont documentées dans la Time Zone Database de l’IANA.
Ces conversions concernent la France métropolitaine. Les territoires français situés dans d’autres fuseaux ne suivent pas tous les mêmes règles.
Et si aucun fuseau horaire n’est précisé ?
La documentation de la DTD XMLTV indique que lorsqu’une date ne comporte pas de fuseau explicite, UTC est supposé.
Par exemple :
20261023180000
est interprété, selon cette règle, comme 18 h UTC.
Il ne faut donc pas automatiquement le lire comme 18 h à Paris.
Si une source écrit une heure locale sans son décalage approprié, le guide peut apparaître décalé.
Pourquoi il ne faut pas corriger les horaires au hasard
Un lecteur peut aussi proposer des paramètres de décalage horaire.
Ces paramètres interviennent à un autre niveau que les timestamps fournis dans XMLTV.
Pour comprendre l’origine d’un décalage, il faut distinguer la date enregistrée dans le fichier, sa conversion vers le fuseau local et les éventuelles corrections du lecteur.
Si votre grille présente effectivement un décalage, consultez notre guide spécialisé : EPG IPTV ne fonctionne pas : guide vide et horaires incorrects.
XMLTV, XML et XML.GZ : quelles différences ?
Les appellations peuvent sembler proches, mais elles ne désignent pas exactement la même chose.
XML est le langage de représentation
XML fournit les règles de syntaxe utilisées pour organiser les éléments et les attributs.
XMLTV utilise cette syntaxe pour représenter des données de programmes télévisés.
Un fichier XML quelconque n’est donc pas automatiquement un fichier XMLTV.
.xml désigne habituellement un document XML
Par convention, une source XMLTV peut être disponible sous un nom comme :
guide.xml
Mais l’extension ne suffit pas, à elle seule, à démontrer que le contenu respecte la structure XMLTV.
.xml.gz correspond à des données compressées
Un fichier :
guide.xml.gz
contient généralement un document XML compressé avec Gzip.
Après décompression, les données peuvent conserver exactement la même structure XMLTV.
La compression vise principalement à réduire la quantité de données à transférer ou stocker.
Tous les lecteurs acceptent-ils XMLTV compressé ?
Non, cela dépend du logiciel.
La documentation de Kodi IPTV Simple Client indique explicitement la prise en charge des données XMLTV compressées avec Gzip et XZ.
Cela ne garantit pas que chaque lecteur multimédia accepte ces formats de compression.
Avant d’utiliser une ressource compressée, vérifiez la documentation de votre application.
Une URL XMLTV doit-elle terminer par .xml ?
Pas nécessairement.
Une ressource distante peut être fournie par une URL sans extension apparente.
L’important est le document effectivement récupéré, son éventuelle compression et sa prise en charge par le lecteur.
Un fichier XMLTV valide garantit-il un EPG utilisable ?
Non. C’est une distinction technique essentielle.
Il existe plusieurs niveaux de vérification :
- Le document respecte-t-il la syntaxe XML ?
- Sa structure respecte-t-elle les règles XMLTV ?
- Contient-il des programmes pour les chaînes et horaires concernés ?
- Le lecteur peut-il associer et afficher correctement ces données ?
Un succès à la première étape ne garantit pas les suivantes.
Exemple A — XMLTV avec programmes
<?xml version="1.0" encoding="UTF-8"?>
<tv>
<channel id="exemple.a.fr">
<display-name>Chaîne Exemple A</display-name>
</channel>
<programme
start="20261023180000 +0000"
channel="exemple.a.fr">
<title>Programme Exemple</title>
</programme>
</tv>Cet exemple contient une déclaration de chaîne et un programme.
Sa structure correspond aux éléments essentiels prévus par la DTD.
Cela ne garantit pas encore qu’un lecteur externe trouvera une entrée M3U correspondante.
Exemple B — XMLTV valide, mais sans programme
<?xml version="1.0" encoding="UTF-8"?>
<tv>
<channel id="exemple.a.fr">
<display-name>Chaîne Exemple A</display-name>
</channel>
</tv>Ce document respecte la structure prévue par la DTD XMLTV.
Pourtant, il ne contient aucune émission.
Un lecteur ne peut donc pas afficher de programmes à partir de ces seules données.
La validité du fichier n’est pas la même chose que la présence d’informations utiles.
La DTD permet même un élément <tv> sans aucune déclaration de chaîne ni de programme.
Exemple C — Document XML mal formé
<?xml version="1.0" encoding="UTF-8"?>
<tv>
<channel id="exemple.a.fr">
<display-name>Chaîne Exemple A</display-name>
</tv>Ici, la balise <channel> n’est pas correctement fermée.
Le document ne respecte donc pas la syntaxe XML.
Ce problème est différent de l’absence de programmes dans un fichier correctement formé.
Un autre cas : XML valide, mais identifiants incohérents
Même lorsque XMLTV est correctement structuré, il peut exister des identifiants qui ne correspondent pas à ceux de la playlist.
C’est une erreur de cohérence entre les données, pas nécessairement une erreur de syntaxe XML.
La DTD indique comment représenter les références de chaînes, mais ne garantit pas à elle seule que les valeurs correspondent aux identifiants externes présents dans une playlist M3U.
Tableau des niveaux de validation
| Résultat du contrôle | Ce qu’il confirme | Ce qu’il ne garantit pas |
|---|---|---|
| XML correctement formé | Le document respecte la syntaxe XML | Conformité XMLTV |
| Structure conforme à la DTD | Les éléments suivent les règles du format | Programmes présents |
| Programmes présents | Le fichier contient des diffusions | Programmes correspondant à la période recherchée |
| Identifiants cohérents | Les correspondances peuvent être établies | Affichage identique dans tous les lecteurs |
| Horaires exploitables | Les données peuvent être interprétées temporellement | Absence d’erreur de configuration dans le lecteur |
Cette distinction évite de conclure trop rapidement qu’un XMLTV est entièrement opérationnel parce qu’il peut être ouvert.
Comment les lecteurs interprètent XMLTV
Le comportement d’un lecteur ne doit pas être confondu avec les obligations de la DTD XMLTV.
Un fichier peut respecter les règles du format et donner des résultats différents selon la façon dont l’application charge, associe ou présente les données.
Sources locales et distantes
Certains lecteurs peuvent utiliser un fichier XMLTV enregistré localement.
D’autres récupèrent une source distante.
Kodi IPTV Simple Client documente ces deux approches, ainsi que des possibilités de cache et d’actualisation.
Ces fonctions dépendent de la version et de la configuration.
Correspondance des identifiants
Kodi IPTV Simple Client documente le rapprochement entre tvg-id et les données XMLTV, ainsi que des mécanismes alternatifs reposant sur les noms.
Cela permet d’illustrer une chose importante : une règle d’association décrite par une application n’est pas une obligation universelle du format XMLTV.
Plusieurs sources de guide
Certaines applications peuvent prendre en charge plusieurs sources EPG ou plusieurs configurations.
Kodi IPTV Simple Client documente notamment plusieurs couples de configurations M3U/XMLTV dans les versions appropriées de Kodi.
La capacité à réunir plusieurs sources, à résoudre les doublons ou à sélectionner une source prioritaire dépend toutefois du lecteur.
Pourquoi deux lecteurs peuvent afficher des résultats différents
Les causes possibles comprennent :
- des règles de correspondance différentes ;
- une gestion différente des dates ;
- une fenêtre temporelle d’affichage différente ;
- des méthodes d’actualisation distinctes ;
- des limitations liées aux données ou aux fichiers pris en charge.
Il faut éviter de présenter ces différences comme des comportements universels.
Comment vérifier un XMLTV sans exposer vos données
Vous pouvez examiner la structure d’un fichier XMLTV sans publier sa source ou son contenu complet sur Internet.
Les cinq vérifications essentielles
| Étape | Question | Résultat attendu |
|---|---|---|
| 1 — Syntaxe | Le document peut-il être analysé comme XML ? | Aucune erreur de syntaxe |
| 2 — Structure | Les éléments correspondent-ils à XMLTV ? | Structure conforme au format attendu |
| 3 — Programmes | Existe-t-il des <programme> ? | Données de diffusion présentes |
| 4 — Correspondance | Les identifiants correspondent-ils à ceux de la playlist ? | Association exploitable par le lecteur |
| 5 — Horaires | Les programmes couvrent-ils la période recherchée ? | Dates et heures pertinentes |
Si vous utilisez un outil de validation, vérifiez ce qu’il analyse réellement.
Un outil qui reçoit uniquement le fichier XMLTV ne peut pas confirmer les correspondances avec une playlist M3U qu’il n’a jamais consultée.
Privilégier une inspection locale
Pour les fichiers privés, il est préférable de travailler sur une copie locale et d’éviter les validateurs inconnus qui demandent d’envoyer l’ensemble des données à un serveur.
Les adresses de téléchargement peuvent contenir des paramètres sensibles, par exemple des jetons d’accès.
Ne partagez jamais publiquement ces valeurs.
La sécurité des fichiers XML
Un fichier XML provenant d’une source inconnue ne doit pas être considéré comme automatiquement sûr.
Certains parseurs XML mal configurés peuvent traiter des entités externes et créer des risques de divulgation ou d’accès indésirable à des ressources.
La documentation OWASP recommande notamment de désactiver la résolution des entités externes et de limiter les ressources consommées lors de l’analyse des documents XML non fiables.
Référence : OWASP — XML External Entity Prevention.
Cette précaution concerne surtout les outils qui analysent les fichiers, notamment lorsqu’ils sont développés pour un site Web.
Respecter les droits sur les données
Une source XMLTV accessible publiquement n’est pas automatiquement librement réutilisable ou redistribuable.
Les conditions de licence et les droits applicables aux données doivent être vérifiés séparément.
ParisIPTV privilégie les exemples fictifs et les sources auxquelles l’utilisateur dispose d’un accès légitime.
Quand faut-il passer au dépannage de l’EPG ?
Cet article explique comment XMLTV représente les programmes et comment un lecteur peut les associer aux chaînes.
Il ne remplace pas un diagnostic lorsqu’une installation présente une panne réelle.
Si vous rencontrez l’un de ces symptômes :
- le guide est entièrement vide ;
- certaines chaînes affichent « No Information » ;
- les émissions sont attribuées aux mauvaises chaînes ;
- les horaires sont décalés ;
- les programmes ne s’actualisent plus ;
le problème nécessite des vérifications spécifiques sur les sources, les identifiants ou la configuration temporelle.
Utilisez alors le guide EPG IPTV ne fonctionne pas : corriger un guide vide, « No Information » ou des horaires décalés.
Si c’est la playlist M3U elle-même qui est refusée avant l’affichage des chaînes, consultez plutôt Playlist M3U ne se charge pas : diagnostic et solutions.
Questions fréquentes sur XMLTV IPTV
XMLTV et EPG sont-ils la même chose ?
Non. XMLTV est un format de données décrivant notamment les chaînes et leurs programmes. L’EPG est le guide électronique présenté à l’utilisateur. Un lecteur peut utiliser XMLTV pour alimenter son EPG, mais le guide n’est pas limité à ce seul format.
Un fichier XMLTV contient-il des vidéos ?
Non. XMLTV décrit des informations de programmation. Il ne fournit pas automatiquement des ressources vidéo, des chaînes ou des autorisations de lecture.
XMLTV fonctionne-t-il avec M3U et M3U8 ?
Oui, lorsqu’un lecteur compatible permet d’associer les entrées d’une playlist à des données XMLTV. L’extension de la playlist ne détermine pas à elle seule le fonctionnement du guide.
Le champ tvg-id est-il obligatoire ?
Il n’est pas obligatoire dans la DTD XMLTV, car il ne fait pas partie de ce format. tvg-id est une convention utilisée dans certaines playlists M3U. Certains lecteurs peuvent également rapprocher les chaînes par leur nom ou par une autre méthode.
Un fichier XMLTV peut-il être valide sans programme ?
Oui. La DTD XMLTV autorise un document ne contenant aucune entrée <programme>. Ce fichier peut être conforme à la structure du format, tout en n’apportant aucune émission à afficher dans le guide.
Pourquoi certains guides XMLTV utilisent-ils l’extension .xml.gz ?
Parce que le document XMLTV est compressé avec Gzip. Après décompression, il retrouve sa structure XML. Les lecteurs ne prennent pas tous en charge les mêmes formats de compression.
Peut-on utiliser plusieurs sources XMLTV ?
Cela dépend du lecteur. Certaines applications prennent en charge plusieurs configurations ou sources, mais la façon de les associer, de gérer les conflits et de prioriser les données relève de leur implémentation. Il faut consulter la documentation du logiciel concerné.
Sources consultées
1. XMLTV Project — DTD officielle xmltv.dtd
Référence principale pour la structure XMLTV, les éléments obligatoires et facultatifs, les attributs des programmes et les règles d’interprétation des dates.
https://github.com/XMLTV/xmltv/blob/master/xmltv.dtd
2. Kodi Wiki — PVR IPTV Simple Client
Documentation des relations entre playlists M3U, identifiants tvg-id, noms des chaînes et données XMLTV dans ce lecteur.
https://kodi.wiki/view/Add-on:PVR_IPTV_Simple_Client
3. Kodi — PVR IPTV Simple Client, dépôt officiel
Documentation technique complémentaire des configurations XMLTV, des mécanismes de correspondance et des formats compressés pris en charge.
https://github.com/kodi-pvr/pvr.iptvsimple
4. IANA — Time Zone Database
Référence relative aux fuseaux horaires et aux règles de conversion temporelle.
https://www.iana.org/time-zones
5. OWASP — XML External Entity Prevention Cheat Sheet
Recommandations de sécurité relatives à l’analyse de documents XML provenant de sources non fiables.
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
Méthodologie : les exemples XMLTV et M3U sont des exemples pédagogiques fictifs. Les règles de structure ont été confrontées à la DTD officielle et les affirmations propres à Kodi à sa documentation. Aucun essai manuel dans une application particulière n’est revendiqué.
Dernière vérification éditoriale : 23 octobre 2026.
Découvrez nos offres techniques
Explorez nos solutions techniques et trouvez les ressources adaptées à vos besoins.