Was ein EPG ist – und was es nicht ist
Das EPG ist die Programmübersicht, die ein Fernseher oder eine App auf Knopfdruck einblendet: Welche Sendung läuft gerade, was kommt danach, was ist für morgen Abend angekündigt. Technisch ist es nichts anderes als ein Datensatz mit Sendungstiteln, Beschreibungen sowie Start- und Endzeiten.
Entscheidend für das Verständnis aller EPG-Probleme ist, woher diese Daten kommen. Beim klassischen Antennen-, Kabel- oder Satellitenempfang werden sie mit dem Fernsehsignal zusammen übertragen; der Empfänger liest sie aus demselben Datenstrom, aus dem auch das Bild kommt. Bei IPTV ist das in der Regel nicht der Fall. Dort sind Bild und Programmdaten zwei getrennte Dinge: Die Senderliste kommt aus der einen Quelle, die Programmdaten aus einer zweiten, meist aus einer eigenen Datei, die der Player von einer anderen Adresse lädt.
EPG und XMLTV
EPG (Electronic Program Guide) bezeichnet die elektronische Programmzeitschrift als Funktion. XMLTV ist das Dateiformat, in dem diese Programmdaten im IPTV-Umfeld üblicherweise ausgetauscht werden: eine XML-Datei, häufig komprimiert ausgeliefert, mit Kanaldefinitionen und Programmeinträgen.
Aus dieser Trennung folgt die wichtigste Faustregel für die Fehlersuche: Ein fehlendes Programm sagt nichts über die Bildqualität aus, und ein laufender Sender sagt nichts über die Gültigkeit der Programmdaten. Es handelt sich um zwei unabhängige Systeme, die nur an einer einzigen Stelle miteinander verbunden sind.
Woher die Daten stammen
Am Anfang der Kette steht immer der Sender selbst: Er legt sein Programm fest und veröffentlicht es. Von dort gelangen die Angaben über verschiedene Zwischenstufen – Datendienste, Aggregatoren, Anbieter oder selbst gepflegte Sammlungen – in die Datei, die Ihr Player schließlich lädt. Jede dieser Stufen kann Zeiten runden, Titel kürzen, Sprachen mischen oder Änderungen verspätet übernehmen.
Das erklärt eine Beobachtung, die viele Nutzer irritiert: Das Programm im EPG kann von dem abweichen, was der Sender auf seiner eigenen Website ausweist. Die Website ist näher an der Quelle. Kurzfristige Programmänderungen, etwa bei Sportübertragungen oder Sondersendungen, erreichen eine über mehrere Stationen weitergereichte Datei oft gar nicht mehr.
XMLTV: zwei Bausteine, mehr nicht
Eine XMLTV-Datei kennt im Kern zwei Arten von Einträgen. Der erste definiert einen Kanal und gibt ihm eine Kennung. Der zweite beschreibt eine einzelne Sendung und verweist auf genau diese Kennung. Alles Weitere – Beschreibungstexte, Kategorien, Bildmaterial, Sprachangaben – hängt an diesen beiden Bausteinen.
Das folgende Beispiel ist frei erfunden und zeigt nur die Struktur:
<tv>
<channel id="beispiel.eins">
<display-name lang="de">Beispielsender Eins</display-name>
</channel>
<programme start="20260914200000 +0200" stop="20260914214500 +0200" channel="beispiel.eins">
<title lang="de">Beispielsendung</title>
<desc lang="de">Eine kurze Beschreibung der Sendung.</desc>
</programme>
</tv>
Drei Eigenschaften dieses Aufbaus prägen den Alltag:
Zeiten sind absolut, nicht relativ. Jeder Eintrag trägt einen eigenen Beginn und ein eigenes Ende. Es gibt keinen fortlaufenden Ablaufplan, aus dem sich Lücken ergänzen ließen. Fehlt ein Eintrag, entsteht im Player eine echte Lücke, kein Übergang.
Die Zeitangabe enthält ihre eigene Zeitzone. Hinter Datum und Uhrzeit steht ein Offset wie +0200. Erst dieser Zusatz macht die Angabe eindeutig. Er ist die häufigste Fehlerquelle bei verschobenen Sendezeiten.
Der Kanalbezug ist eine Zeichenkette, kein Verweis mit Prüfung. Steht im Programmeintrag eine Kennung, zu der es keine passende Kanaldefinition gibt, ist die Datei formal trotzdem in Ordnung. Sie enthält dann Sendungen, die zu keinem Sender gehören – und niemand meldet einen Fehler.
Warum die Zuordnung über Kennungen läuft
Ein Player führt zwei Listen zusammen: die Senderliste aus der Playlist und die Programmdaten aus der XMLTV-Datei. Verbunden werden sie über die Kennung. In der M3U-Playlist steht sie im Attribut tvg-id, in der XMLTV-Datei im Attribut id der Kanaldefinition. Stimmen beide zeichengenau überein, erscheint das Programm. Andernfalls nicht.
Dass hier nicht über den Sendernamen zugeordnet wird, hat einen guten Grund: Namen sind uneindeutig und unbeständig. Sie werden umbenannt, unterschiedlich geschrieben, mit oder ohne Zusatz wie HD geführt, und derselbe Name kann in verschiedenen Ländern für verschiedene Sender stehen. Eine stabile Kennung löst dieses Problem – solange beide Seiten dieselbe verwenden.
Genau daran scheitert es in der Praxis regelmäßig, weil Playlist und EPG-Datei oft aus unterschiedlichen Händen stammen:
- Abweichende Schreibweise. Groß- und Kleinschreibung, Punkte, Bindestriche oder Leerzeichen werden in aller Regel als Unterschied gewertet.
- Unterschiedliche Namenskonventionen. Die eine Quelle verwendet ein Kürzel, die andere eine ausgeschriebene Kennung mit Länderteil.
- Unsichtbare Zeichen. Beim Bearbeiten von Hand geraten Leerzeichen an den Rand des Attributwerts, die man nicht sieht, die aber zählen.
- Mehrfach vergebene Kennungen. Tauchen zwei Kanaldefinitionen mit derselben Kennung auf, entscheidet der Player, welche er nimmt – nachvollziehbar ist das von außen nicht.
- Vollständig fehlende Kennung. Ohne
tvg-idbleibt dem Player nur der Abgleich über den Namen, sofern er diesen Notbehelf überhaupt anbietet.
Deshalb ist die erste sinnvolle Prüfung bei fehlendem Programm nicht, den Player neu zu installieren, sondern beide Werte nebeneinanderzulegen und zeichenweise zu vergleichen. Die Systematik dahinter ist im Leitfaden zu fehlendem oder falschem EPG Schritt für Schritt beschrieben.
Warum Sendezeiten verschoben erscheinen
Verschobene Zeiten sind der zweite große Beschwerdegrund – und beim Empfang südosteuropäischer Sender in Deutschland besonders verwirrend. Denn die Länder der Region liegen in derselben Zeitzone wie Deutschland. Eine Verschiebung dürfte es geografisch gar nicht geben, und trotzdem tritt sie auf.
Die Ursache liegt nicht in der Geografie, sondern in der Deklaration. Der Offset hinter der Zeitangabe wird von der Quelle gesetzt, und er kann falsch gesetzt sein. Typisch sind zwei Muster: Eine Quelle schreibt lokale Uhrzeiten, deklariert sie aber als +0000, sodass der Player sie zusätzlich umrechnet. Oder eine Quelle rechnet die Sommerzeit nicht mit und bleibt ganzjährig bei einem Winterzeit-Offset.
So grenzen Sie die Ursache ein:
- Alles ist um exakt eine Stunde verschoben, und zwar bei allen Sendern. Das deutet auf einen falschen Offset in der Quelle oder auf eine Sommerzeit-Umstellung hin, die dort nicht nachvollzogen wurde.
- Alles ist um exakt zwei Stunden verschoben. Hier liegt meist eine doppelte Umrechnung vor: lokale Zeit als UTC deklariert, danach vom Player noch einmal in die lokale Zeit gerechnet.
- Nur einzelne Sender sind verschoben. Dann stammen ihre Einträge aus einer anderen Teilquelle mit eigener Zeitlogik.
- Die Verschiebung ändert sich mit dem Standort oder Gerät. Dann prüfen Sie zuerst die Zeitzonen- und Sommerzeit-Einstellung des Abspielgeräts, nicht die Datei.
Die Umstellungsphase ist der Härtetest
Rund um die halbjährliche Zeitumstellung treten Offset-Fehler gehäuft auf, weil Quelle und Gerät den Wechsel nicht zwingend im selben Moment vollziehen. Eine Abweichung, die in dieser Phase auftritt und wenige Tage später von selbst verschwindet, war fast immer ein Deklarationsproblem der Datenquelle und kein Fehler Ihrer Einrichtung.
Wie oft die Daten aktualisiert werden
Eine XMLTV-Datei ist eine Momentaufnahme. Sie enthält einen begrenzten Zeitraum in die Zukunft und wird vom Player in Abständen neu geladen. Beide Größen – Vorschauzeitraum und Ladeintervall – hängen von der Quelle und von den Einstellungen des Players ab und lassen sich nicht allgemein beziffern. In Kodi etwa sind es zwei eigene Einstellungen: Update interval steht ab Werk auf 120 Minuten und reicht von 15 bis 2880 Minuten, Future days to display auf drei Tagen und reicht von einem bis 31 Tage. Nachsehen können Sie es deshalb an zwei Stellen: in der EPG-Einstellung Ihres Players, in der Intervall und Vorschautiefe hinterlegt sind, und am Ende der Programmvorschau, deren letzter Eintrag den Horizont der Datei markiert.
Daraus ergeben sich drei praktische Konsequenzen:
Die Vorschau endet irgendwann. Reicht das Programm nur wenige Stunden weit, ist das kein Defekt, sondern der Umfang der Quelle. Eine Einstellung im Player kann daran nichts ändern, wenn die Daten nicht geliefert werden.
Zwischengespeicherte Daten überleben Korrekturen. Ist eine fehlerhafte Datei einmal geladen, bleibt sie bis zum nächsten Abruf in Gebrauch. Wer eine korrigierte Quelle einträgt, sollte deshalb einen manuellen Neuabruf auslösen, statt das Ergebnis sofort zu beurteilen.
Aufnahmen hängen an diesen Daten. Eine über das EPG geplante Aufnahme übernimmt Start- und Endzeit aus dem Eintrag. Ist der Eintrag um eine Stunde verschoben, ist es die Aufnahme ebenfalls. Ein Vor- und Nachlauf von einigen Minuten fängt geringe Ungenauigkeiten ab, ein falsch deklarierter Zeitzonen-Offset lässt sich damit jedoch nicht ausgleichen. Welche Player überhaupt Aufnahmen und Erinnerungen anbieten, führt der Vergleich der IPTV-Apps auf.
Symptome richtig deuten
| Was Sie sehen | Wahrscheinliche Ursache | Nächster Prüfschritt |
|---|---|---|
| Kein Sender hat ein Programm | Die EPG-Quelle wurde nicht geladen oder ist nicht erreichbar | In den Player-Einstellungen prüfen, ob eine EPG-Adresse hinterlegt ist, und den Abruf danach von Hand auslösen |
| Nur einzelne Sender haben kein Programm | Deren Kennung findet keine Entsprechung in der XMLTV-Datei | tvg-id der Playlist und id der Kanaldefinition zeichengenau vergleichen |
| Alles um exakt eine Stunde verschoben | Falsch deklarierter Offset oder nicht nachvollzogene Sommerzeit | Offset hinter start und stop in der Datei ansehen und mit der Zeitzone des Geräts vergleichen |
| Programm endet nach wenigen Stunden | Die Quelle liefert nur einen kurzen Vorschauzeitraum | Letzten Eintrag der Vorschau ansehen und den Horizont mit der Angabe der Quelle abgleichen |
| Titel in falscher Sprache oder mit unleserlichen Zeichen | Sprachauswahl der Quelle oder Zeichenkodierung | Sprachpräferenz des Players prüfen und die Datei auf UTF-8-Kodierung ansehen |
| Programm war korrekt, ist jetzt veraltet | Zwischenspeicher des Players oder abgelaufene Quelle | Zwischengespeicherte Daten verwerfen, den Neuabruf auslösen und die Programmvorschau erneut ansehen |
Die Tabelle lässt sich seitwärts scrollen.
Die Tabelle ordnet Symptome ihrer häufigsten Ursache zu. Sie ersetzt keine Prüfung des Einzelfalls – decken sich mehrere Symptome, arbeiten Sie die Zeilen von oben nach unten ab.
Die Reihenfolge dieser Tabelle ist kein Zufall. Sie führt vom Allgemeinen zum Speziellen: erst klären, ob überhaupt Daten ankommen, dann die Zuordnung prüfen, dann die Zeitlogik, und erst zuletzt Darstellungsfragen. Wer in umgekehrter Reihenfolge vorgeht, ändert Einstellungen an einer Stelle, an der gar kein Fehler liegt.