Eine Textdatei, kein Video
Eine M3U-Datei lässt sich mit jedem Texteditor öffnen und lesen. Darin steht kein Bildmaterial, sondern eine Aufzählung: pro Eintrag ein Name mit einigen Zusatzangaben und darunter die Adresse, unter der das zugehörige Medium liegt. Die Datei ist ein Inhaltsverzeichnis, nicht der Inhalt.
Diese Unterscheidung erklärt mehrere Beobachtungen, die sonst widersprüchlich wirken. Eine Liste mit mehreren tausend Einträgen bleibt eine sehr kleine Datei, weil sie nur aus Text besteht. Ein Eintrag kann sauber in der Übersicht erscheinen und trotzdem nicht starten, weil die Playlist lediglich den Wegweiser enthält und nichts über den Zustand des Ziels aussagt. Und dieselbe Datei funktioniert auf ganz unterschiedlichen Geräten, solange der jeweilige Player das Format liest und die enthaltenen Adressen erreichen kann.
M3U
Ein zeilenbasiertes Playlistformat in reinem Text. Im einfachsten Fall besteht ein Eintrag aus einer einzigen Zeile mit einer Dateiadresse oder URL. Das erweiterte Format ergänzt Kommentarzeilen, die mit #EXT beginnen und Zusatzangaben wie Laufzeit, Anzeigename und Gruppierung transportieren.
Woher das Format kommt
Das Format stammt nicht aus der Fernsehwelt, sondern aus der Musikwiedergabe am PC. Bekannt wurde es als Playlistdatei des Players Winamp: eine Liste von Titeln in gewünschter Reihenfolge, gespeichert als schlichter Text. Später kam die erweiterte Variante hinzu, die jedem Eintrag eine Laufzeit und einen Anzeigenamen mitgeben konnte, ohne die Einfachheit des Formats aufzugeben.
Dass heute Senderlisten in diesem Format ausgeliefert werden, hat einen pragmatischen Grund: Eine Textzeile mit einer URL funktioniert unabhängig davon, ob dahinter eine Musikdatei oder ein Livestream liegt. Die IPTV-Nutzung hat lediglich weitere Angaben in die Kommentarzeilen geschrieben.
Die Grundbausteine sind dabei durchaus festgeschrieben: Die Spezifikation des Streaming-Verfahrens HLS, veröffentlicht als RFC 8216, legt #EXTM3U und #EXTINF verbindlich fest. Was eine IPTV-Senderliste ausmacht, steht dort jedoch nicht – weder die Attribute tvg-id, tvg-name, tvg-logo und group-title noch überhaupt ein Verfahren, mehrere verschiedene Sender in einer Datei zu führen. Diese Ebene ist eine Konvention, auf die sich Anbieter und Player-Entwickler eingespielt haben, kein Standard. Was ein Programm daraus macht, steht deshalb nicht in der Spezifikation, sondern nur in seiner eigenen Dokumentation: Kodis Add-on IPTV Simple etwa führt die vier Attribute im Abschnitt zu den unterstützten M3U-Elementen auf und hält zugleich fest, dass für einen Eintrag eine #EXTINF-Zeile mit Sendernamen und die Adresszeile darunter genügen. Für ein zweites verbreitetes Programm liegt uns eine vergleichbar belastbare Dokumentation nicht vor; wie weit die Unterschiede zwischen Playern reichen, lässt sich hier deshalb nicht beziffern.
Der Aufbau: eine Kopfzeile, dann Paare aus Beschreibung und Adresse
Eine erweiterte Playlist beginnt mit der Kopfzeile #EXTM3U. Sie signalisiert dem Player, dass Kommentarzeilen mit Zusatzangaben folgen. Danach wiederholt sich immer dasselbe Muster: eine #EXTINF-Zeile beschreibt den Eintrag, die unmittelbar folgende Zeile nennt seine Adresse.
Das folgende Beispiel ist frei erfunden; .invalid ist nach RFC 2606 eine reservierte Top-Level-Domain für Namen, die mit Sicherheit ungültig sind, und dient hier ausschließlich der Veranschaulichung der Struktur.
#EXTM3U x-tvg-url="https://epg.beispiel.invalid/guide.xml.gz"
#EXTINF:-1 tvg-id="beispiel.eins" tvg-name="Beispielsender Eins" tvg-logo="https://logo.beispiel.invalid/eins.png" group-title="Beispielgruppe",Beispielsender Eins
https://stream.beispiel.invalid/live/eins/index.m3u8
#EXTINF:-1 tvg-id="beispiel.zwei" tvg-name="Beispielsender Zwei" tvg-logo="https://logo.beispiel.invalid/zwei.png" group-title="Beispielgruppe",Beispielsender Zwei
https://stream.beispiel.invalid/live/zwei/index.m3u8
In der Kopfzeile steht im Beispiel zusätzlich x-tvg-url. Auch das ist keine vorgeschriebene Angabe, sondern eine verbreitete Konvention: Sie nennt die Adresse der zugehörigen Programmdaten, damit diese nicht getrennt im Player hinterlegt werden muss. Ob ein Player den Hinweis beachtet, sagt nur dessen eigene Dokumentation: Kodis Add-on IPTV Simple etwa zieht die Adresse ausdrücklich nur dann heran, wenn in seinen Einstellungen keine EPG-Quelle hinterlegt ist.
Drei weitere Details in dieser Struktur werden regelmäßig missverstanden:
Die Zahl direkt hinter #EXTINF: ist die Laufzeit in Sekunden. RFC 8216 lässt dafür nur nicht negative Werte zu. In Senderlisten steht bei Livesendern trotzdem -1 – eine Praxis außerhalb der Spezifikation, die auch die Beispielliste in der Dokumentation von Kodis IPTV Simple verwendet. Der Wert ist dort kein Fehler und kein Platzhalter, den man ausfüllen müsste.
Das Komma trennt zwei Welten. Links davon stehen die maschinenlesbaren Attribute, rechts davon der Anzeigename für den Menschen. Taucht in einem Sendernamen selbst ein Komma auf, geraten manche Parser durcheinander – ein klassischer Grund für abgeschnittene Namen in der Senderliste.
Die Adresszeile gehört untrennbar zur #EXTINF-Zeile darüber. Fehlt sie, oder ist sie durch einen Zeilenumbruch beim Kopieren zerrissen, verschiebt sich die Zuordnung: Ab dieser Stelle bekommt jeder Eintrag die Adresse des nächsten – die Liste sieht vollständig aus, spielt aber die falschen Inhalte ab.
Was die Attribute bewirken
Die Attribute in der #EXTINF-Zeile beschreiben den Eintrag für den Player. Sie ändern nichts am Stream selbst, sondern nur daran, wie er dargestellt und mit anderen Daten verknüpft wird.
| Attribut | Was darin steht | Wozu ein Player es verwenden kann |
|---|---|---|
| tvg-id | Eine Kennung des Senders, die auch in der EPG-Quelle vorkommen soll | Verknüpfung des Eintrags mit den passenden Programmdaten |
| tvg-name | Der Name des Senders, wie er in den EPG-Daten geführt wird | Zuordnung zu den Programmdaten, wenn die Kennung nicht greift |
| tvg-logo | Die Adresse einer Bilddatei auf einem beliebigen Server | Anzeige eines Senderlogos in der Übersicht |
| group-title | Ein frei vergebener Gruppenname | Einsortierung in Kategorien, etwa nach Land, Sprache oder Genre |
| Text nach dem Komma | Der Anzeigename des Eintrags | Beschriftung in der Senderliste und in der Suche |
Die Tabelle lässt sich seitwärts scrollen.
Keines dieser Attribute ist verbindlich vorgeschrieben: Kodis Add-on IPTV Simple etwa dokumentiert alle vier, verlangt für einen Eintrag aber nur eine #EXTINF-Zeile mit Sendernamen und die Adresszeile darunter. Dieselbe Dokumentation beschreibt die Zuordnung zu den Programmdaten in drei Durchgängen: zuerst über tvg-id, dann über tvg-name, zuletzt über den Sendernamen hinter dem Komma. Welche Attribute ein anderer Player auswertet, steht verbindlich nur in dessen eigener Dokumentation.
Praktisch bedeutsam ist vor allem tvg-logo: Das Attribut enthält eine Adresse, das Bild selbst steht also nicht in der Playlist, sondern wird darüber nachgeladen. Fehlende Logos sind daher kein Playlist-Fehler, sondern deuten auf ein nicht erreichbares Ziel dieser Adresse. Und tvg-id ist der Ankerpunkt für die elektronische Programmzeitschrift: In der XMLTV-Datei trägt jedes channel-Element eine vorgeschriebene Kennung, auf die sich jede Sendung über ihr channel-Attribut bezieht. Findet ein Player in keinem seiner Zuordnungsschritte eine Übereinstimmung – bei Kodis IPTV Simple sind das tvg-id, tvg-name und der Sendername –, bleibt die Programmvorschau leer, obwohl der Sender einwandfrei läuft.
Die häufigste Verwechslung: .m3u und .m3u8
Hier liegt der Punkt, an dem Anleitungen im Netz regelmäßig aneinander vorbeireden. Die Endung .m3u8 hat zwei voneinander unabhängige Bedeutungen.
Die erste ist die verbreitete Lesart: Die 8 stehe für UTF-8, .m3u8 sei also dieselbe Liste in dieser Zeichenkodierung. Wer sich darauf verlässt, liest mehr in die Endung hinein, als die Spezifikation hergibt. RFC 8216 verlangt UTF-8 – ohne Byte Order Mark – für jede Playlist und lässt für den Pfad ausdrücklich beide Schreibweisen zu, .m3u8 oder .m3u. Über die Kodierung sagt die Endung dort also nichts; entscheidend ist, dass die Datei tatsächlich UTF-8 enthält. Für südosteuropäische Sendernamen ist genau das der Punkt, an dem es hängt: Zeichen wie č, ć, š, ž und đ kommen nur mit dieser Kodierung zuverlässig an.
Die zweite Bedeutung hat mit Senderlisten nichts zu tun. Beim Streaming-Verfahren HLS trägt auch das Manifest eines einzelnen Streams die Endung .m3u8. Dieses Manifest verwendet dasselbe zeilenbasierte Grundformat, beschreibt aber nicht viele Sender, sondern die Bestandteile genau einer Übertragung: verfügbare Qualitätsstufen und die kurzen Videosegmente, aus denen der Player die laufende Sendung zusammensetzt. Im Beispiel oben sehen Sie beide Ebenen gleichzeitig – die Playlist selbst und, als Ziel jedes Eintrags, eine Adresse, die auf ein solches Manifest zeigt.
| Frage | Senderliste (.m3u / .m3u8) | HLS-Manifest (.m3u8) |
|---|---|---|
| Was steht darin? | Viele Einträge mit Namen, Attributen und je einer Zieladresse | Die Bausteine eines einzelnen Streams: Qualitätsstufen und Segmente |
| Wie oft ändert sich der Inhalt? | Selten – nur wenn der Anbieter die Liste umbaut | Laufend – ohne EXT-X-ENDLIST verlangt RFC 8216 eine neue Fassung mit mindestens einem neuen Segment |
| Wer liest die Datei? | Der Player beim Einrichten und beim Aktualisieren der Senderliste | Die Abspielkomponente während der Wiedergabe |
| Wo begegnet sie Ihnen? | Als Datei oder Abo-Adresse, die Sie im Player hinterlegen | Als Ziel hinter einem einzelnen Eintrag der Senderliste |
| Was bedeutet die 8? | Verbreitet als Hinweis auf UTF-8 gelesen – RFC 8216 verlangt UTF-8 ohnehin für jede Playlist | Nichts Eigenes – RFC 8216 lässt für den Pfad .m3u8 oder .m3u zu |
Die Tabelle lässt sich seitwärts scrollen.
Beide sind Textdateien im selben Grundformat. Der Unterschied liegt darin, worauf ihre Zeilen verweisen: auf viele Sender oder auf die Teile eines Streams.
Für die Praxis folgt daraus eine klare Regel: In das Feld für die Playlist gehört die Senderliste, auch wenn beide Adressen auf .m3u8 enden. Eine einzelne HLS-Adresse ersetzt keine Playlist – sie liefert genau einen Kanal und niemals eine Senderübersicht.
Wie ein Player daraus eine Senderliste baut
Der Ablauf ist immer derselbe und hilft beim Verständnis von Fehlern. Der Player lädt die Datei oder ruft die hinterlegte Adresse ab. Anschließend liest er die Zeilen der Reihe nach und legt für jedes Paar aus Beschreibung und Adresse einen Eintrag an. Aus group-title entstehen die Kategorien im Menü, aus dem Text nach dem Komma die Beschriftung, aus tvg-id die Verbindung zu den Programmdaten. Die Logos holt er separat über das Netz.
Das Ergebnis speichert der Player lokal ab, damit die Liste beim nächsten Start sofort da ist. Diese Zwischenspeicherung ist der Grund, warum Änderungen an einer Playlist oft nicht sofort sichtbar werden: Sie sehen noch die alte Fassung, bis der Player die Quelle erneut abruft. Wie groß der Unterschied zwischen einer lokal gespeicherten Datei und einer laufend aktualisierten Abo-Adresse ist, zeigt sich genau hier – die Datei bleibt, wie sie ist, die Adresse kann sich jederzeit ändern.
Je umfangreicher eine Liste ist, desto länger dauert dieser Aufbau, und desto mehr Arbeitsspeicher braucht er. Auf leistungsschwachen Sticks und älteren Fernsehern ist das spürbar. Eine auf die tatsächlich genutzten Gruppen reduzierte Liste startet daher schneller als eine mit mehreren tausend Einträgen.
Warum eine Playlist-Adresse wie ein Passwort zu behandeln ist
Wird eine Senderliste nicht als Datei, sondern als Adresse bereitgestellt, stecken die Zugangsdaten häufig in dieser Adresse selbst. Wie das aussieht, zeigt die Beispielliste in der Dokumentation von Kodis IPTV Simple: Dort stehen Benutzername und Passwort als Bestandteile des Pfades im Klartext in der URL. RFC 3986 hält zu Anmeldedaten in einer Adresse ausdrücklich fest, dass sich ihre Übergabe im Klartext in nahezu jedem Anwendungsfall als Sicherheitsrisiko erwiesen hat. Wer die Adresse hat, hat damit den Zugang.
Eine Playlist-Adresse ist ein Zugangsschlüssel
Geben Sie eine solche Adresse nicht in Foren, Chatgruppen oder Kommentaren weiter und laden Sie keine Bildschirmfotos hoch, auf denen sie lesbar ist. Auch Online-Dienste, die eine Playlist „prüfen“ oder „umwandeln“, erhalten damit vollständigen Zugang. Ist eine Adresse einmal öffentlich geworden, hilft nur, beim Anbieter neue Zugangsdaten anzufordern – die alte Adresse lässt sich nicht zurückholen.
Dasselbe gilt für den Weg, auf dem Sie die Adresse selbst transportieren. Eine Playlist-Adresse, die per E-Mail durch mehrere Postfächer läuft oder in einem Messenger-Verlauf auf einem geteilten Gerät liegt, ist so gut geschützt wie ein Passwort auf einem Notizzettel.
Typische Fehlerquellen
Die meisten Probleme entstehen nicht im Format, sondern beim Umgang mit der Datei:
- Falsch gespeichert. Wird die Playlist mit einer Textverarbeitung bearbeitet und in deren Format gesichert, ist sie kein reiner Text mehr. Ein Editor ohne Formatierung ist Pflicht.
- Falsche Zeichenkodierung. Speichert der Editor nicht in UTF-8, werden diakritische Zeichen unleserlich. Das betrifft südosteuropäische Sendernamen besonders häufig.
- Fehlende oder verrutschte Kopfzeile. RFC 8216 verlangt
#EXTM3Uals erste Zeile jeder Playlist; Dateien, die gegen die Syntaxregeln verstoßen, sind dort ungültig, und Clients müssen ihre Auswertung verweigern. Wie nachsichtig ein einzelner IPTV-Player damit umgeht, sagt nur dessen eigene Dokumentation. - Versteckte Dateiendung. Blendet das Betriebssystem bekannte Endungen aus, entsteht beim Speichern unbemerkt eine Datei namens
playlist.m3u.txt. - Beschädigte Zeilenumbrüche. Über Messenger oder aus Webseiten kopierte Playlists verlieren Umbrüche oder bekommen typografische Anführungszeichen statt gerader – beides macht die Attribute unlesbar.
- Abgelaufene Adresse. Enthält die Abo-Adresse ein zeitlich begrenztes Merkmal, lädt die Liste ab einem bestimmten Zeitpunkt nicht mehr, ohne dass sich an der Datei etwas geändert hätte.
Wie Sie diese Ursachen der Reihe nach ausschließen, steht ausführlich im Leitfaden zu Playlists, die nicht laden.
So prüfen Sie eine Playlist selbst
Sie brauchen dafür keine Spezialsoftware, nur einen Texteditor und einen Player am Computer:
- Öffnen Sie die Datei in einem einfachen Texteditor. Steht
#EXTM3Uin der ersten Zeile und sind Umlaute sowie diakritische Zeichen korrekt dargestellt, ist die Grundlage in Ordnung. - Vergleichen Sie, ob auf jede
#EXTINF-Zeile genau eine Adresszeile folgt. Weichen die Anzahlen voneinander ab, liegt ein Zuordnungsfehler vor. - Kopieren Sie eine einzelne Adresse aus der Datei in einen Desktop-Player. Startet dieser Stream, funktioniert die Verbindung, und das Problem liegt beim Abspielgerät oder bei der App – wie das am Computer mit Windows oder macOS geht, ist dort beschrieben.
- Bleibt die Programmvorschau leer, ist nicht die Playlist schuld, sondern die Zuordnung zur EPG-Quelle. Ihr Aufbau ist im Ratgeber zur elektronischen Programmzeitschrift erklärt.
Diese vier Schritte trennen die drei Ebenen sauber voneinander, die im Alltag ständig vermischt werden: die Datei, die Verbindung und die App.