Was XMLTV ist, und was ein Parser darin überstehen muss

XMLTV ist das Format, in dem fast jeder Fernsehprogrammführer außerhalb des eigenen Systems eines Senders ausgeliefert wird. Es ist älter als die Streaming-Industrie, es ist einfaches XML, und seine Spezifikation ist eine DTD und kein Schema mit einem Prüfer, den irgendjemand ausführt.

Dieser letzte Teil ist die ganze Geschichte. XMLTV ist nicht schwierig, weil das Format komplex wäre. Es ist schwierig, weil jeder eines erzeugen kann, niemand es prüft, und die Dateien, die bei einem Player ankommen, durch eine Kette von Sammlern und Umwandlern gegangen sind, zwischen denen keine Testsuite steht.

Das Format, auf einem Bildschirm#

Es gibt 2 Elemente, auf die es ankommt.

<tv>
  <channel id="bbc1.uk">
    <display-name>BBC One</display-name>
    <display-name lang="en">BBC One HD</display-name>
    <icon src="https://example.com/bbc1.png" />
  </channel>

  <programme channel="bbc1.uk" start="20260831180000 +0100" stop="20260831190000 +0100">
    <title lang="en">The Six O'Clock News</title>
    <desc lang="en">National and international news.</desc>
    <category lang="en">News</category>
  </programme>
</tv>

Ein channel deklariert eine Kennung und einen oder mehrere für Menschen lesbare Namen. Ein programme zeigt auf eine Senderkennung, trägt eine Startzeit und meist eine Endzeit und hält einen Titel plus die optionalen Metadaten, auf die der Erzeuger Lust hatte.

Das ist das Format. Alles andere ist optional, und in der Praxis ist alles andere uneinheitlich vorhanden.

Die Kennung ist die ganze Verknüpfung#

channel id ist ein Verknüpfungsschlüssel, und es ist der einzige. Das ist das Wichtigste an XMLTV.

Ihre Playlist sagt, ein Sender sei tvg-id="bbc1.uk". Ihre Programmdatei hat ein <channel id="bbc1.uk">. Diese beiden Zeichenketten müssen genau übereinstimmen, sonst hat der Sender kein Programm.

Sie werden aus nichts abgeleitet. Es gibt kein Register. Es gibt keine Normalisierung, die das Format vorschreibt. bbc1.uk, BBCOne.uk, BBC1.uk und bbc-one.uk sind für jeden Parser 4 verschiedene Sender, und es ist völlig normal, dass die Playlist eines Anbieters der einen Konvention folgt, während die Programmdatei, die er empfiehlt, einer anderen folgt.

Deshalb ist "mein Programmführer ist leer" meist ein Zuordnungsproblem und kein Abruf- oder Auswertungsproblem. Beide Dateien können tadellos geformt und zusammen völlig nutzlos sein.

Die display-name-Elemente helfen bei der Verknüpfung nicht. Sie sind dazu da, Menschen gezeigt zu werden, es sind häufig mehrere je Sender in mehreren Sprachen, und sie zum Zuordnen zu nutzen ist eine Heuristik und keine Regel.

Zeitstempel, und der Grund, warum so viele Programmführer eine Stunde daneben aussehen#

Ein XMLTV-Zeitstempel ist eine Zeichenkette mit der Uhrzeit, gefolgt von einem optionalen Versatz:

20260831180000 +0100    six in the evening, one hour ahead of UTC
20260831180000          six in the evening UTC, per the spec's default

Der Versatz ist optional. Diese eine Entwurfsentscheidung erzeugt mehr Supportanfragen als alles andere im Format zusammen.

Wir haben das in einem früheren Entwurf dieses Artikels falsch gemacht und einen blanken Zeitstempel als nicht einordenbar beschrieben. Er ist es nicht. Die DTD ist ausdrücklich darin, dass ein Zeitstempel ohne Zeitzone als UTC zu lesen ist, es gibt also einen definierten Standardwert, und ein konformer Parser folgt ihm.

Das Problem ist, dass ein Erzeuger, der den Versatz weglässt, meist kein UTC veröffentlicht. Er veröffentlicht die örtliche Uhrzeit dort, wo der Programmführer zusammengestellt wurde, und verlässt sich darauf, dass der Leser am selben Ort ist. Das ist nicht, was die Spezifikation sagt, und es ist das, was sehr viele Dateien tun. Ein Parser, der der DTD folgt, ist dann gleichzeitig korrekt und eine oder zwei Stunden falsch.

Unser Parser nimmt für genau diesen Fall eine anzunehmende Zeitzone vom Aufrufer entgegen, was die Abweichung zu einer Einstellung macht statt zu einer stillen Entscheidung. Beide Aufnahmewege auf dem Gerät lassen sie leer, ein blanker Zeitstempel wird also als UTC gelesen und die Zeitzone des Rechners geht nie in die Rechnung ein.

Die Störung, die daraus entsteht, ist unverwechselbar: ein ganzer Tag um eine ganze Anzahl Stunden verschoben, wobei alle Sendungsdauern stimmen. Wenn Ihr Programm stimmt, aber durchgehend ein oder zwei Stunden danebenliegt, ist warum die Programmzeiten falsch sind der Artikel mit den Einzelheiten.

Eine Programmdatei ist nicht vertrauenswürdige Eingabe#

Für eine Nutzerin oder einen Nutzer unsichtbar. Für einen Parser alles.

Eine Programmdatei ist XML von einer beliebigen Adresse, und XML hat eine lange Geschichte von Angriffen auf Parser. Der Leser wird deshalb defensiv eingestellt, bevor er ein Byte liest: Dokumenttypdefinitionen werden ignoriert statt verarbeitet, der externe Auflöser wird leer gesetzt, damit keine Entität einen Netzwerkabruf auslösen kann, und die Ausdehnung aus Entitäten wird auf null Zeichen begrenzt.

Diese drei Einstellungen schließen die klassischen Probleme mit Entitätsausdehnung und externen Entitäten. Sie sind keine Härtung, die wir für einen freundlicheren Parser lockern könnten; eine Programmadresse hat genau die Form von Eingabe, auf die diese Angriffe zielen.

Auf der Serverseite gibt es eine dazu passende Regel, und sie wird den Nutzerinnen und Nutzern gesagt statt versteckt: Ihre Geräte laden die Programmdateien direkt herunter, und unsere Server holen sie nie für Sie. Ein Server, der beliebige vom Benutzer angegebene Adressen abriefe, wäre eine Maschine zum Fälschen von Anfragen, also tut er es nicht.

Elf Grenzen, und warum es jede davon gibt#

Den Leser zu härten genügt nicht, denn die gefährliche Eingabe ist in der Praxis nicht bösartig. Es ist ein Programmführer mit 40 Titelelementen.

depth                32       nesting
text                 64 KB    any single text node
description          4 KB     aggregate across repeats
title                1 KB     aggregate across repeats
credits              15       per programme
categories           6        per programme
alternate names      8        per channel
channel batch        512      rows written at a time
programme batch      2,000    rows written at a time
programme duration   6 hours  ceiling
retention            8 days forward, 1 day back

Die Titelgrenze hat den lehrreichsten Grund. Eine Sendung darf zulässigerweise einen Titel je Sprache tragen. Ein Programmführer, der 40 davon ausgibt, ist nicht fehlerhaft, er ist gründlich, und ohne eine Grenze werden alle 40 zu einem einzigen gespeicherten Titel verkettet. Die Beschreibungsgrenze ist dieselbe Regel aus demselben Grund.

Die Stapelgrößen sind Durchsatz und keine Sicherheit: ein nationaler Programmführer sind hunderttausende Sendungen, und sie einzeln zu schreiben ist der Unterschied zwischen einem Programmführer, der lädt, und einem, der zu hängen scheint.

Das Aufbewahrungsfenster ist das, was die Leute überrascht. Sendungen außerhalb davon werden während der Auswertung verworfen, statt gespeichert und danach aufgeräumt zu werden. Vorwärts steht standardmäßig auf 8 Tagen und zurück auf 1, begrenzt auf 14 und 7. Ein Anbieter, der 14 Tage Programm in einen auf 8 eingestellten Client veröffentlicht, verliert keine Daten durch einen Fehler; ihm wird gesagt, dass ein Player das Programm der übernächsten Woche nicht dringend genug braucht, um es zu speichern.

Das hat eine unmittelbare Folge für Catch-up: Catch-up-Einträge werden aus Programmzeilen gebaut, die Aufbewahrung des Programmführers ist also eine Obergrenze dafür, wie weit Sie zurückreichen können. Was Catch-up und Timeshift sind behandelt das Zusammenspiel.

Acht Arten, wie ein Abruf scheitert#

Fehler werden in 8 Arten eingeordnet, statt als ein Fehler gemeldet zu werden: keine Adresse, kein XML, Netzwerk, Größengrenze, Dekomprimierungsgrenze, Sicherheitsgrenze, abgebrochen und unbekannt. Die Dekomprimierungsgrenze und die Sicherheitsgrenze sind mit Absicht vom Netzwerkfehler getrennt, denn sie bedeuten wirklich Verschiedenes: das eine ist eine Kompressionsbombe, das andere ein feindliches Dokument, und das dritte eine schlechte Verbindung.

Die drei Fehler, die ein Vorlagenpaket gefunden hat#

Echte Programmdateien sind schlimmer, als das Format erlaubt. Dazu haben wir Zahlen und keinen Eindruck.

Ein Vorlagenpaket aus 51 echten Programmdateien förderte 3 verschiedene Fehler zutage. Jeder einzelne konnte den gesamten Programmführer eines Anbieters über ein einziges Byte zerstören.

Ein nicht maskiertes kaufmännisches Und in einem Sendungstitel. XML verlangt &, viele Erzeuger schreiben ein blankes &, und ein strenger Parser hört an dieser Stelle auf. Alles danach ist weg.

Eine Datei, die UTF-8 deklariert und Latin-1-Bytes trägt. Der Kopf sagt das eine und der Rumpf ist etwas anderes, und das erste betonte Zeichen in einem französischen Filmtitel ist die Stelle, an der es endet.

Ein verirrtes Steuerzeichen in einer Beschreibung. In keiner Kodierung zulässiges XML, und wieder tödlich an der Stelle, an der es auftaucht.

Alle 3 werden heute repariert statt tödlich zu sein, und die Reparaturen werden gezählt, eine Datei, die geflickt werden musste, sagt das also, statt still zu funktionieren. Der Grund, das zu veröffentlichen statt es still zu beheben, ist, dass es die Erwartungen richtig einstellt: wenn Sie annehmen, Programmdateien seien wohlgeformt, ergeben die Fehler keinen Sinn.

Vor dem XML: herausfinden, was die Datei überhaupt ist#

Eine Programmadresse mit der Endung .xml.gz ist ein Hinweis und keine Tatsache. Anbieter liefern gzip von Pfaden mit der Endung .xml, schlichtes XML von Pfaden mit der Endung .gz, und beides von Pfaden ganz ohne Endung, und ein Inhaltstyp im Kopf ist nicht verlässlicher als der Pfad.

Der Behälter wird deshalb bestimmt, indem die ersten Bytes gelesen und mit bekannten Kennungen verglichen werden:

1F 8B                gzip
50 4B 03 04          zip
FD 37 7A 58 5A 00    xz
anything else        treat as uncompressed

Vier Ausgänge, und der vierte ist der wichtige: ein nicht erkannter Kopf ist kein Fehler, sondern eine Datei, die als schlichtes XML angenommen wird. Das ist die richtige Vorgabe, denn der häufige Fall für einen nicht erkannten Kopf ist ein schlichtes XMLTV-Dokument, und der falsche Fall scheitert einen Moment später sauber am Parser statt am Entpacker mit etwas Verwirrenderem.

Die eine Form, bei der das nicht helfen kann, ist eine Adresse, die mit einer HTML-Fehlerseite antwortet. Sie hat keine Kennung, gilt also als unkomprimiert, wird dem XML-Leser übergeben und als kein XML abgelehnt. Der Fehler ist korrekt und er ist einen Schritt von der Ursache entfernt, was wissenswert ist, wenn Sie eine Programmadresse untersuchen, die früher funktioniert hat.

Zwei Obergrenzen für die Dekomprimierung, und warum eine davon ein Verhältnis ist#

Ein komprimierter Programmführer ist ein nicht vertrauenswürdiges Archiv, und ein Archiv, das sich ausdehnt, bis eine Festplatte voll ist, ist ein alter Angriff mit einem Namen. Die Dekomprimierung ist deshalb zweifach begrenzt und nicht einfach.

Die absolute Obergrenze liegt bei 2 GiB Ausgabe. Das ist bewusst großzügig: nationale Programmführer für mehrere Länder laufen unkomprimiert tatsächlich auf mehrere hundert Megabyte hinaus, und eine Grenze, die einen berechtigten Programmführer abschneidet, wäre schlimmer als das Problem, das sie verhindert.

Die zweite Grenze ist die interessante. Die Ausgabe ist außerdem auf das 400-Fache der tatsächlich empfangenen komprimierten Bytes begrenzt. Eine Verhältnisgrenze fängt den Fall, den die absolute Obergrenze verfehlt: eine Datei von 40 KB, die sich Richtung Gigabyte ausdehnt, wird bei 16 MB gestoppt, lange bevor sie sich 2 GiB nähert, denn nichts an ihrem Größenprofil ähnelt einem echten Programmführer.

XML lässt sich außerordentlich gut komprimieren, 400 zu 1 ist für ehrliche Daten also keine enge Grenze. Es ist der Punkt, jenseits dessen eine Datei aufgehört hat, wie ein Programm auszusehen, und angefangen hat, wie eine Nutzlast auszusehen.

Wie die Abdeckung mit Kennungen tatsächlich aussieht#

Die Verknüpfung über Kennungen nützt nur dann etwas, wenn Playlists Kennungen tragen, und die Abdeckung schwankt stärker, als einem lieb ist.

Über unseren eigenen Playlist-Bestand gemessen, insgesamt 2.203 Einträge:

playlist_01.m3u    308 entries    308 with tvg-id (100%)    283 group-title     0 tvg-chno
playlist_02.m3u8 1,895 entries  1,392 with tvg-id (73.5%)  1,895 group-title  1,355 tvg-chno

Beide sind kuratierte Playlists in Verzeichnisform und keine Exporte aus einem Anbieter-Panel, und dieser Vorbehalt zählt hier mehr als sonst: kuratierte Listen werden von Menschen gepflegt, denen Kennungen wichtig sind, und ein Panel-Export wird von Software erzeugt, der sie es möglicherweise nicht sind.

Zwei Einzelheiten in dieser Tabelle zählen. Die zweite Datei hat 20 Einträge, die ein Kennungsattribut tragen, das vorhanden und leer ist. Das ist ein anderer Zustand als ein fehlendes Attribut, und ein Parser muss es als fehlend behandeln und nicht als Kennung, die zufällig die leere Zeichenkette ist, sonst verknüpfen sich alle 20 dieser Sender miteinander.

Und die Gruppenabdeckung liegt in der zweiten Datei bei 100 Prozent, während die Kennungsabdeckung bei 73.5 Prozent liegt. Gruppierung und Programmzuordnung sind getrennte Anliegen, die von getrennten Attributen getragen werden, und deshalb kann eine Playlist tadellos in Kategorien geordnet ankommen und trotzdem überhaupt kein Programm zeigen.

Warum Anzeigenamen eine gescheiterte Verknüpfung nicht retten können#

Die naheliegende nächste Idee, wenn Kennungen nicht übereinstimmen, ist der Abgleich über den für Menschen lesbaren Namen. Das ist ein viel schwereres Problem, als es aussieht.

Ein Anzeigename ist freier Text, es kann mehrere je Sender in mehreren Sprachen geben, und Anbieter schmücken sie aus. Derselbe Sender aus zwei Quellen kann ein Länderpräfix, ein Qualitätssuffix, ein Trennzeichen, das in der einen Liste ein senkrechter Strich und in der anderen ein Doppelpunkt ist, und beliebig viel Unicode-Zierrat tragen. Nichts davon ist fehlerhaft; so wird das Feld eben genutzt.

Der Namensabgleich ist also ein Normalisierungsproblem mit einem langen Schwanz, und eine falsche Zuordnung ist schlimmer als keine: ein Sender, der das Programm eines anderen Senders zeigt, ist ein Fehler, dem eine Zuschauerin oder ein Zuschauer mehrere Minuten glaubt, bevor es auffällt. Die Kennung gibt es genau deshalb, damit dieses Raten unnötig ist, und die richtige Lösung, wenn sie scheitert, ist, die Kennungen in Übereinstimmung zu bringen, und nicht, härter zu raten.

Und das ist das praktische Argument dafür, das eigene XMLTV Ihres Anbieters einem fremden vorzuziehen. Nicht weil es bessere Daten wären, sondern weil sein Programmführer und seine Playlist aus einem System kommen, die Kennungen passen also bauartbedingt zusammen.

Die Zahlen lesen, die eine Auswertung zurückgibt#

Eine Auswertung meldet mehr als Erfolg. Sie liefert 7 Felder zurück, und sie beantworten verschiedene Fragen:

Channels           how many channel declarations were kept
Programmes         how many programme rows were kept
Dropped            how many were discarded, mostly by the retention window
BytesCompressed    what arrived over the network
BytesUncompressed  what it expanded to
ParseMs            how long it took
CompletedAtUtc     when

Diese Kombination beantwortet Fragen, die ein Wahrheitswert nicht beantworten kann. Ein Programmführer mit 200.000 Sendungen und 40.000 verworfenen tut etwas anderes als einer mit 200.000 und 0. Mehrere Diagnosen fallen unmittelbar aus solchen Kombinationen heraus.

Nahezu gleiche komprimierte und unkomprimierte Größen bedeuten, dass die Datei nicht komprimiert war, was bei einer Adresse mit der Endung .gz heißt, dass Ihnen etwas anderes ausgeliefert wird, als der Name verspricht.

Eine hohe Sendungszahl mit einer hohen Verwurfszahl ist ein Anbieter, der weiter vorausveröffentlicht, als Ihr Aufbewahrungsfenster behält. Das ist normal, und es ist das, was Sie ändern sollten, wenn Catch-up flacher ist als erwartet.

Eine Auswertung, die bei einer Datei, die 60 MB groß sein sollte, in 40 Millisekunden fertig war, hat keinen Programmführer gelesen. Sie hat eine Fehlerseite gelesen, und die Fehlerart wird das sagen.

Eine Senderzahl in den Tausenden mit einer Sendungszahl von null ist die Form eines Programmführers, der Senderdeklarationen und kein Programm trägt, was manche Anbieter zwischen zwei Erzeugungsläufen veröffentlichen.

Was Sie daraus mitnehmen#

Wenn Ihr Programmführer leer ist, prüfen Sie vor allem anderen die Kennungen. Das ist die Verknüpfung, und dort geht das meiste schief.

Wenn Ihr Programmführer da, aber verschoben ist, prüfen Sie, ob die Datei Versätze trägt.

Wenn Ihr Programmführer unvollständig ist, prüfen Sie, ob er beim Übertragen abgeschnitten wurde, und das ist eine bestimmte Störung mit einer bestimmten Signatur: ein Programmführer, der auf halbem Weg aufhört.

Und wenn Sie zwischen dem eigenen XMLTV eines Anbieters und einem fremden wählen können, nehmen Sie das des Anbieters, aus dem oben genannten Grund. Der Programmführer ist leer geht die Diagnose von Anfang bis Ende durch.