tvg-chno: Sendernummern in IPTV-Playlists, und was jeder Player damit macht

tvg-chno="1"      107 entries
tvg-chno="2"       92
tvg-chno="3"       80
tvg-chno="4"       72
tvg-chno="5"       68
tvg-chno="#"        4
tvg-chno="22.1"     1

Das ist der Kopf des Sendernummern-Histogramms einer echten Playlist, mit zwei ihrer merkwürdigeren Werte darunter festgehalten. Die Datei hält 1.895 Einträge. 1.355 davon tragen das Attribut, und diese 1.355 Nummern decken 263 verschiedene Werte ab, im Mittel 5.15 Einträge je Wert. Die mit Abstand beliebteste Nummer der Datei wird von 107 nicht miteinander verwandten Sendern beansprucht.

Kein Standard definiert, was irgendetwas davon bedeutet. Es gibt keine Spezifikation für tvg-chno, kein Register und keinen Eigentümer. Die Referenzumsetzung dokumentiert es in einer Zeile einer README, und die Anwendungen, die es lesen, sind sich über die Schreibweise, den Typ, den Rückfall und darüber, ob der Wert überhaupt gezeigt wird, uneinig.

Woher das Attribut kommt, soweit es sich zeigen lässt#

RFC 8216 ist eine informative Einreichung und kein Dokument des Standardisierungswegs. Sie definiert EXTM3U in Abschnitt 4.3.1.1, EXTINF in Abschnitt 4.3.2.1 und die Familie #EXT-X-, und die Zeichenkette tvg kommt darin nirgends vor. Ihre Attributlisten-Grammatik ist kommagetrennt mit einer festen Namensform, der die leerzeichengetrennte tvg--Konvention nicht folgt, und derselbe Abschnitt weist Clients an, Namen zu ignorieren, die sie nicht kennen. Diese Anweisung ist es, die die Konvention neben der RFC leben lässt: alles Folgende ist eine private Übereinkunft zwischen einem Programm und den Playlists, die man ihm gezeigt hat.

Das früheste Auftreten von tvg-chno, auf das ich zeigen kann, ist der Pull Request #92 gegen Kodis IPTV-Simple-Erweiterung, eröffnet am 2016-11-24 und zusammengeführt am 2016-12-17. Ich kann nicht belegen, dass er der erste ist, nur dass nichts Früheres öffentlich ist. Er fügt eine Markerkonstante hinzu, und die erklärte Motivation seines Autors war der Abgleich von Sendernummern mit einem Backend. Der Negativbefund drumherum ist stärker als der Commit: ein Eintrag im selben Verfolger vom 2015-07-20 sagt klar, dass das M3U-Format kein Tag für eine Sendernummer hat, und schlägt vor, die Nummer in den Sendernamen zu packen. Der Autor von #92 fand diesen Eintrag fünf Minuten nach dem Eröffnen seines Pull Requests, und der Betreuer schloss ihn später als durch seinen Patch behoben. Mitte 2015 kannte die eigene Gemeinschaft der Erweiterung kein solches Attribut.

Das Präfix tvg- ist fast vier Jahre älter als die Nummer. tvg-name, tvg-logo und group-title sitzen im ersten Projekt-Commit der Erweiterung vom 2013-01-17, tvg-id landet am selben Tag, und tvg-shift vier Tage danach. Wofür tvg steht, ist Folklore: alle lesen es als Kurzform von Fernsehprogrammführer, also TV-Programm, und die Geschwisterattribute, die die Programmadresse tragen, stützen diese Lesart, aber keine Erstquelle nennt die Auflösung, und die Berichte, die den Attributsatz auf ein früheres Windows-Player-Umfeld zurückführen, sind aus zweiter Hand. Der Negativbefund ist fester. XMLTV ist das, worauf diese Attribute zeigen, und nicht das, woher sie kamen.

Die Übernahme nach Kodi verläuft über Tvheadend, das es im März 2018 ausgibt, Emby, das es im Lauf von 2018 dokumentiert, und Jellyfin im Februar 2019. Die ärgerlichste Einzelheit der Sammlung ist, dass die Commit-Nachricht von Tvheadend sagt, sie füge ein Attribut tvg-chnum hinzu, während der Code, den sie mitbringt, tvg-chno= schreibt, und dass es auf dem Rückweg zuerst tvh-chnum liest und auf tvg-chno zurückfällt. Mindestens fünf Schreibweisen tragen in echten Dateien eine Sendernummer: tvg-chno, channel-number, ch-number, tvh-chnum, und eine channel-id, die manche Leser als Nummer behandeln.

1.176 der 1.355 Nummern werden mit einer anderen Zeile geteilt#

Wir haben drei lokal gehaltene Beispiel-Playlists vermessen, insgesamt 2.209 Einträge. Zwei der drei nummerieren überhaupt nichts: null ihrer 314 Einträge tragen das Attribut. Alles hier ist die dritte Datei.

Die Werte sind schief verteilt. 179 der 263 verschiedenen Werte werden genau einmal verwendet, die Masse sitzt also in einem kurzen Kopf: 107 Einträge auf der Nummer 1, dann 92, 80, 72 und 68. Der Bereich reicht von 1 bis 4.999, die Obergrenze des Parsers von 99.999 hat also nie ausgelöst. 1.176 der 1.355 Zeilen, also 86.8 Prozent, teilen sich ihre Nummer mit mindestens einer anderen Zeile, und ein eindeutiger Schlüssel über der Datei würde 1.092 davon verwerfen. Zählt man nur die Werte, die unser Parser annimmt, liegt der Anteil geteilter Nummern bei 1.172 von 1.299, also 90.2 Prozent.

Warum nichts in einer dieser Dateien ein stabiler Schlüssel ist, wird in dem Artikel zum erweiterten M3U geklärt, und ich führe das hier nicht erneut aus. Was dieser Artikel nicht tut, ist die naheliegende Reparatur zu erledigen: wenn sich Nummern über eine Datei hinweg doppeln, beschränken Sie sie auf die Gruppe, in der sie sitzen, und jede Gruppe bekommt eine saubere Folge.

Das funktioniert nicht.

33 der 85 Gruppen, die überhaupt eine Nummer tragen, enthalten innerhalb der Gruppe mindestens eine doppelte Nummer. 69 dieser 85 enthalten einen Sender mit der Nummer 1. Eine Gruppe hält 7 Einträge, die alle die Nummer 1 tragen, und in der größten Gruppe der Datei decken 79 nummerierte Einträge 74 verschiedene Nummern ab. Das Gruppieren verringert die Anzahl der Kollisionen, ohne sie zu beseitigen, und eine Lösung, die für zwei Drittel Ihrer Gruppen wirkt, scheitert beim übrigen Drittel stillschweigend.

Die Ausfallquote zählt so viel wie die Doppelung. 596 der 1.895 Einträge, also 31.5 Prozent, enden ohne brauchbare Nummer: 540 trugen das Attribut nie, und 56 trugen etwas, das der Parser ablehnt. Im Abgleich mit dem Kennungsattribut tragen 398 Zeilen weder eine Nummer noch eine Kennung, also die Menge, die in der Datei nichts ansprechen kann. Eine Programmzeile ohne etwas, woran sie sich hängen kann, zeigt sich als ein Programm, das auf manchen Sendern falsch und auf anderen richtig ist, nie als Beschwerde über die Nummerierung.

Jede Dezimalzahl in der Datei ist argentinisch#

25 Einträge nutzen die Nummerierung major.minor, über 24 verschiedene Werte von 22.1 bis 36.2, und nur 32.1 wiederholt sich. Jeder einzelne der 25 trägt das Land AR, eine Kennung, die auf .ar endet, und die Gruppe Argentina, die 26 Einträge hält und alle 26 nummeriert. Argentinien sendet ISDB-Tb. ATSC und ISDB-Tb nutzen beide die Form major.minor, und die Form ist alles, was sie hier teilen. Unser eigener Quellkommentar nennt diese Werte ATSC-artig, was für die Form stimmt und über die Herkunft falsch ist.

Diese 25 Zeilen sind der Grund, warum die Nummer eine Gleitkommazahl ist und keine Ganzzahl. Der Typ war billig. Die Migration nicht. Die Spalte lässt sich nicht nachfüllen, denn die Nummer wohnt in der Nutzlast der Quelle und wir bewahren die rohe Playlist nicht auf. Jede bestehende Installation hätte auf jeder Zeile einen leeren Wert getragen, und eine nach dieser Nummer sortierte Liste hätte eine ganze Bibliothek in den nicht nummerierten Schwanz gestellt. Die Migration löscht den Fingerabdruck der Momentaufnahme und die Materialisierungsmarke und zwingt die nächste Synchronisierung, den Katalog neu aufzubauen. Jede bestehende Installation zahlte eine vollständige Neumaterialisierung, um ein Abzeichen anzuzeigen.

Sechsundfünfzig Werte sind überhaupt keine Zahlen#

56 der 1.355 Werte, über 53 verschiedene Schreibweisen, werden rundheraus abgelehnt. Sie fallen in vier Formen:

• Ein blankes # auf 4 Einträgen, ein Platzhalter, den der Erzeuger nie gefüllt hat.
• 49 Codes von Rundfunksystemen: eine Reihe D011 bis D081, eine Familie BS101 bis BS4K101, eine lange Reihe CS055 bis CS363, und ein einzelnes JCOM307. Das ist ein echtes nationales Nummerierungsschema, und das Attribut hat keinen Platz dafür.
• CH 106 und CH 108, dieselbe Nummer mit einem Präfix und einem Leerzeichen.
• Ein Wert, der ein Plattformname in japanischer Schrift ist, mit 527 am Ende.

Eine Ablehnung kostet die Zeile ihre Nummer und nie die Zeile, alle 56 behalten also ihren Platz und sortieren sich in den nicht nummerierten Schwanz.

Mehrere Ablehnungen sind Regeln ohne Zeugen: ein führendes Vorzeichen stellt +5 und -5 außerhalb der angenommenen Stile, und null wird abgelehnt, weil eine fehlende Nummer nicht Sender null ist. Keine dieser Formen kommt in 1.355 Werten auch nur einmal vor. Führende Nullen sind der nachsichtige Fall: 007 wird zu 7 ausgewertet.

Diese Aufteilung braucht einen Vorbehalt, denn das Messskript bildet unseren Parser in Python nach und float() ist lockerer als der Stilsatz, den wir übergeben. Ich habe den Bestand auf jede Form geprüft, in der die beiden uneins sind, ein führendes Plus oder Minus, Exponenten, Unterstriche, umgebende Leerzeichen und führende Nullen, und von jedem null gefunden. Die Aufteilung 1.299 gegen 56 ist die des ausgelieferten Parsers.

Keine zwei dieser Leser sind sich einig#

Nichts davon stammt aus einer Spezifikation, denn es gibt keine. Jede Zelle ist aus dem Quelltext des jeweiligen Projekts oder seiner eigenen Dokumentation gelesen.

Kodis Leser ist der freizügigste des Feldes und der in seiner Wirkung überraschendste. Jeder Eintrag wird aus einem laufenden Zähler angesetzt, der sich auf die Nummer zurücksetzt, die ein Sender beansprucht, ein einziges tvg-chno="500" zwei Drittel weit unten in einer Datei nummeriert also jeden späteren nicht nummerierten Sender ab 501 neu. Ein Attribut auf einer Zeile bewegt hunderte andere. Und nach all dem Auswerten steht die Einstellung im Kern von Kodi, Backend-Sendernummern zu verwenden, standardmäßig auf aus: die Gruppe aller Sender nummeriert sich selbst von 1 bis n, andere Gruppen erben das, und die Nummer der Playlist bleibt am Sender, ohne gezeigt zu werden.

Jellyfins ist der strengste: sein Regex verlangt einen Wert in doppelten Anführungszeichen, tvg-chno=101 ohne Anführungszeichen ist für ihn also unsichtbar, während Kodi es bereitwillig liest, und unser eigener Leser hat dieselbe Einschränkung. Seine Rückfallkette endet beim Dateinamen der Stream-Adresse, dem Punkt, an dem eine Sendernummer aufhört, Daten zu sein, und anfängt, eine Vermutung über einen Pfad zu sein.

xTeVe ist die interessante Verweigerung. Es wertet das Attribut in allgemeine Metadaten aus und nutzt es nie, vergibt seine eigenen Nummern ab dem ersten freien Platz bei 1000 oder darüber, und ein Wunsch, tvg-chno zu beachten, wurde als nicht geplant geschlossen. Das ist der einzige Entwurf hier, in dem zwei Zeilen, die eine Nummer beanspruchen, nicht kollidieren können, denn die Meinung der Playlist wird nie eingeholt, und der Preis ist, dass eine sorgfältig nummerierte Quelle umnummeriert ankommt. Threadfin, seine Abspaltung, ging den anderen Weg und kopiert den Wert wörtlich, Kollisionen kommen also unversehrt durch; sein Entdoppeln hasht die Adresse, die tvg-id und die Quellenkennung, nie die Nummer.

Plex ist die eigenartige Zeile, denn es hat keine eigene M3U-Aufnahme und nichts darin wertet das Attribut aus; seine Seite zu von der Gemeinschaft unterstützten Tunern verlangt ein Windows-BDA- oder Linux-DVB-Gerät. Der übliche Weg von einer Playlist aus ist ein Proxy nach Art von HDHomeRun, wo die Nummer als GuideNumber in lineup.json ankommt, und welche Nummer das ist, hängt vom Proxy ab: xTeVe setzt eine eigene ein, Threadfin reicht die Zeichenkette geradewegs durch.

Sechs Zeilen ergeben vier brauchbare Nummern#

Hier ist ein Bruchstück, gebaut, um jeden Pfad auf einmal zu treffen. Jeder Host ist eine reservierte Beispieldomain und jeder Name ist erfunden.

#EXTINF:-1 tvg-id="one.example" tvg-chno="1",Example One
https://example.com/live/one.m3u8
#EXTINF:-1 tvg-id="two.example" tvg-chno="1",Example Two
https://example.com/live/two.m3u8
#EXTINF:-1 tvg-chno=101,Example Three
https://example.com/live/three.m3u8
#EXTINF:-1 tvg-chno="22.1",Example Four
https://example.com/live/four.m3u8
#EXTINF:-1 tvg-chno="BS4K101",Example Five
https://example.com/live/five.m3u8
#EXTINF:-1 tvg-chno="007",Example Six
https://example.com/live/six.m3u8

Eins und Zwei beanspruchen beide die Nummer 1, was der Normalfall dieser Datei ist und nicht ihr Sonderfall. Unser Vergleicher behält beide, geordnet über einen Namensvergleich in natürlicher Ordnung und danach einen ordinalen Vergleich ihrer Kennungen, das Paar ist also vorhersagbar. Kodi behält ebenfalls beide. xTeVe würde ihnen 1000 und 1001 geben und das Attribut nie lesen.

Drei steht ohne Anführungszeichen da, Kodi liest also 101, während wir überhaupt nichts lesen, wie es auch Jellyfin täte: die Zeile landet auf unserer Seite im nicht nummerierten Schwanz und bei Kodi auf Sender 101.

Vier ist der Unterkanalfall. Wir behalten 22.1 als Dezimalzahl, Kodi teilt es in Hauptnummer 22 mit Unterkanal 1, Jellyfin wertet eine Gleitkommazahl aus und behält die ursprüngliche Zeichenkette zur Anzeige, und jeder Verbraucher mit einer Ganzzahlspalte zeigt 22.

Fünf wird von unserem Zahlenparser abgelehnt und behält seine Zeile, es gesellt sich also im Schwanz zu Drei. Kodi kommt schlechter weg als wir: sein Leser übergibt den Wert an atoi, was für eine Zeichenkette, deren Ziffern nicht vorne stehen, 0 zurückgibt, und nichts sichert den Setter ab, die Zeile wird also Sender 0 und der laufende Zähler wird mit ihr auf 0 zurückgesetzt. Der nächste nicht nummerierte Sender wird 1. Ein Unrat-Wert richtet dort mehr Schaden an als ein fehlender.

Sechs ist der Fall mit der führenden Null: 007 normalisiert sich für uns zu 7, und Jellyfin wertet dieselbe 7 aus und zeigt dabei weiter 007 an.

Nach der Nummer der Quelle sortiert liest sich unsere Liste als Example One, Example Two, Example Six bei 7, Example Four bei 22.1, dann Example Five und Example Three in Namensreihenfolge, denn eine fehlende Nummer sortiert hinter jede vorhandene und nicht als null.

Eine Kollision löst sich je nachdem, was die Zuschauerin oder der Zuschauer gerade tut, unterschiedlich auf. Uns hat es drei Mechanismen gekostet statt einem. Beim Sortieren wird die Kollision vom Namens-Gleichstandsbrecher aufgefangen. Bei der Eingabe über den Ziffernblock geht das Tippen von 1 die Treffer durch: jede Zeile mit dieser Nummer wird gesammelt und wiederholte Druckvorgänge gehen sie durch, mit Umbruch am Ende, denn die erste von 107 für immer festzuhalten würde die anderen 106 unerreichbar machen. Beim Zusammenführen, wo mehrere Quellen zu einem logischen Sender beitragen, gewinnt die Nummer des namengebenden Mitglieds, und andernfalls das erste Mitglied in Prioritätsreihenfolge, das eine hat. Dieselben Mitglieder sind die Warteschlange, in die ein stehengebliebener Stream wechselt, was einen eigenen Artikel hat.

Der Weg über den Ziffernblock hat eine Lücke, die mir nicht gefällt. Er sammelt nur Zifferntasten, mit einem Fenster von 1.2 Sekunden dazwischen und einem Zurücksetzen nach fünf Ziffern, und er wertet ohne aktivierte Zahlenstile aus, es gibt also keine Möglichkeit, 22.1 zu tippen. Ein Unterkanal ist über die Suche erreichbar, wo die Anfrage durch den Parser geht, der einen Dezimalpunkt annimmt, und über die Fernbedienung unerreichbar. Der ehrliche Grund, warum das nicht behoben ist, lautet, dass 25 Zeilen in unserem Bestand es brauchen.

Eine Nummer, die Sie vergeben, ist nicht die Nummer, die die Datei geschickt hat#

Die Nummer der Quelle wird nie überschrieben. Eine Umsortiergeste schreibt einen eigenen gebrochenen Schlüssel, und die beiden leben nebeneinander.

Der Mechanismus wird von einer Beschränkung bestimmt, die mit der Ordnung nichts zu tun hat. Unsere Stapelgrenze bei der Synchronisierung liegt bei 500 Änderungen und ein einzelner abgelehnter Datensatz lässt den ganzen Stapel scheitern und nimmt jede unbeteiligte Änderung mit, die mitreist, eine Gruppe bei jedem Ablegen neu zu nummerieren war also nie tragfähig. Stattdessen bekommt jeder Sender einen impliziten Schlüssel aus seiner Position in der Rückfallordnung, ein platzierter Sender nutzt seinen synchronisierten Schlüssel, und ein Ablegen zwischen zwei Zeilen nimmt die Mitte, was genau eine Zeile schreibt. Implizite Schlüssel liegen eins auseinander, jedes Ablegen in dieselbe Lücke halbiert sie also: gegen eine Mindestlücke von 1e-9 landet das dreißigste aufeinanderfolgende Ablegen in einen Platz noch, und das einunddreißigste gleicht die Gruppe auf gleichmäßig verteilte Schlüssel neu aus. Dieser Neuausgleich ist der einzige Weg hier, der tausende Zeilen schreibt, und er wird mit seiner Größe protokolliert, statt still zu laufen. Drei Kommentare in unserem eigenen Quelltext sagen fünfzig. Wir haben das aus dem Bauch heraus falsch gemacht, der erste Entwurf dieses Artikels hat es wiederholt, und die Zahl wurde erst dreißig, als jemand die Rechnung gemacht hat.

Das Abzeichen zeigt die Position der Zeile statt dieses Schlüssels, denn implizite Schlüssel verschieben sich, sobald die Quelle Sender hinzufügt oder entfernt, und eine Nummer, die sich nach einer Synchronisierung von selbst bewegt, ist schlimmer als keine. Eine frühere Fassung dieser Ordnung wohnte im Ansichtsmodell, wo eine gespeicherte Reihenfolge für Kategoriegruppen der Quelle galt und stillschweigend nicht für Alle Sender, Favoriten oder benutzerdefinierte Gruppen.

Die Windows- und die Xbox-App werten all das auf Ihrem Gerät aus, aus der Playlist, auf die Sie sie richten, und Sie können ein kostenloses Konto anlegen, um beides auszuprobieren. Nichts über Ihre Sendernummern erreicht uns, denn die Datei wird nie hochgeladen und das Auswerten passiert lokal.

Wenn Sie Playlists ausgeben, schreiben Sie tvg-chno auf jede Zeile und halten Sie es innerhalb der Datei eindeutig, denn die Verbraucher, die es beachten, teilen keine Regel dafür, was zu tun ist, wenn Sie das nicht tun, und einer von ihnen nummeriert alles unterhalb Ihres ersten nummerierten Senders neu. Wenn Sie Playlists lesen, zählen Sie die verschiedenen Werte, bevor Sie irgendetwas auf dem Attribut aufbauen. In unserem Bestand ist diese Zahl der Unterschied zwischen 1.355 Nummern und 263.