Bei einem Test mit ORF 2 sah es zunächst unspektakulär aus: Der Stream lief, dann kamen die Regionalnachrichten – und irgendwann war das Bild weg. Nicht kurz weg, nicht mit einem kleinen Ruckler, sondern so weg, dass Tvheadend den Kanal nach dem Wechsel praktisch nicht mehr zurückbekam. Besonders zuverlässig ließ sich der Rückweg vom regionalen zum nationalen Programm reproduzieren: Bild eingefroren, Stop und Play ohne Wirkung, Umschalten ebenso. Im Test bestand die zuverlässige Wiederherstellung ausgerechnet darin, Tvheadend neu zu starten. Als Fehlerbehebung ist das ungefähr so elegant wie beim Lichtausfall den Sicherungskasten neu zu booten.Aus dem reproduzierbaren Fehler wurde eine ziemlich hartnäckige technische Frage: Was ändert ORF 2 in diesem Moment im Transportstrom – und warum stolpert Tvheadend genau darüber?

Tvheadend ist bei mir keine Spielwiese, sondern die TV-Zentrale. Die Satellitenschüssel liefert das Signal, Tvheadend verteilt es über Heimnetz beziehungsweise WLAN zu den Fernsehern. Damit konnte ich klassisches Kabel-TV ersetzen: keine zusätzliche monatliche Kabel-TV-Gebühr und vor allem kein Koaxialkabel zu jedem einzelnen Gerät. Wo Netzwerk oder WLAN vorhanden ist, kann ein passender Client fernsehen. Dazu kommen zentrale Aufnahmen, Timeshift und ein Backend, das unabhängig von den Fernsehern läuft. Für die folgende Fehlersuche diente der ORF2-Streamwechsel als technischer Testfall.

Mein generelles Setup mit Docker, SAT>IP, Aufnahmen, Timeshift und Transcoding beschreibe ich weiterhin im Tvheadend-Grundlagenartikel. Hier geht es dagegen um einen reproduzierbaren Stream-Fehler – und darum, wie aus Workarounds, gezielten Tests rund um 19:21 Uhr und Codex-Analyse schließlich ein eigener Patch für das offizielle Tvheadend-Repository wurde.

Tvheadend: erstaunlich viel TV in einem Server

Tvheadend ist für mich nach wie vor eines dieser Open-Source-Projekte, bei denen die Funktionsliste länger ist als so manche Bedienungsanleitung: DVB-S/S2, DVB-C, DVB-T, SAT>IP, IPTV, HTSP, Aufnahmen, Timeshift und Transcoding. Gerade die Möglichkeit, eine vorhandene SAT-Anlage zentral bereitzustellen und das Fernsehen anschließend über das normale Netzwerk zu verteilen, macht klassische sternförmige TV-Verkabelung in vielen Räumen unnötig. Bei mir ersetzt dieses Setup damit auch einen laufenden Kabel-TV-Anschluss.

Gleichzeitig merkt man dem Projekt seine lange Geschichte an. Die Codebasis ist groß und gewachsen, manche Technik wirkt heute etwas in die Jahre gekommen und auch der Release-Rhythmus ist ungewöhnlich. Wer am 30. September 2026 auf die GitHub-Releases schaut, findet v4.3 weiterhin als Pre-release. Im master-Branch landen dagegen weiterhin aktuelle Commits, und die offizielle Container Registry veröffentlicht laufend neue Images; die Tags latest, master und edge zeigen zum Recherchezeitpunkt auf denselben frisch gebauten Digest.

Verlassen ist Tvheadend damit keineswegs. Es ist eher eine spezielle Mischung aus aktiver Entwicklung und sehr reifer, komplexer Basis. Nicht jeder Bug verschwindet deshalb schnell in einem klassischen Stable-Release. Das ORF2-Issue zeigt das ziemlich gut: Es wurde am 25. Oktober 2025 eröffnet und ist fast ein Jahr später noch offen. Dass sich Entwickler und Tester trotzdem mit so einem speziellen Rundfunk-Sonderfall beschäftigen, ist für mich eher ein Argument für das Projekt als dagegen.

Ein Workaround ist noch kein Fix

Technisch ist der Fehler speziell. Im Testfall ist er schnell erklärt: ORF 2 wechselt für die regionalen Nachrichtensendungen zwischen nationalen und regionalen Programmteilen. Der Service bleibt bestehen, aber Video-, Audio- und Teletext-PIDs können wechseln. Genau an diesem Punkt konnte Tvheadend den laufenden Stream verlieren. Das offene Issue #1973 beschreibt denselben Effekt: letztes Bild eingefroren, nach Stop und Play bleibt der Kanal dunkel, als Ausweg hilft ein Neustart von Tvheadend.

Meine erste Reaktion im Testaufbau war deshalb sehr pragmatisch und überhaupt nicht heroisch: Hauptsache, der Stream kommt nach dem Wechsel wieder. Zwei ORF2-Services, Prioritäten umschalten, API- und Cron-Skripte, ein Watchdog – damit ließ sich der Fehler automatisiert abfangen. Den damaligen Ansatz habe ich auch im Grundlagenartikel dokumentiert.

Nur hat ein Workaround eine unangenehme Eigenschaft: Er bleibt ein Workaround. Er muss den Fehler kennen, im richtigen Moment reagieren und repariert außerhalb von Tvheadend etwas, das eigentlich Tvheadend selbst sauber behandeln sollte. Als Testhilfe war das brauchbar, als eigentliche Fehlerbehebung nicht. Also wollte ich wissen, warum der Kanal überhaupt stirbt.

Was KI hier wirklich verändert hat

Programmieren ist für mich nichts Neues. Neu war, mich in eine große fremde C-Codebasis wie Tvheadend einzuarbeiten und dort ausgerechnet einen Fehler zu verfolgen, der nur bei einer sehr speziellen Änderung eines laufenden MPEG-Transportstroms auftritt. Genau hier wurde KI für mich zum Hebel.

Ich habe Codex nicht mit einem magischen „repariere Tvheadend“ losgeschickt. Stattdessen bekam es Quellcode, konkrete Logfiles und Beobachtungen. Ich ließ verdächtige Codepfade analysieren, Zusammenhänge erklären und mögliche Ursachen gegeneinander prüfen. Danach musste jeder Vorschlag zurück in den Test: kompilieren, starten, den ORF2-Wechsel abwarten und prüfen, ob Live-Stream, Timeshift und Aufnahme-Pfad weiterhin funktionieren.

Codex half mir, mich in der fremden Codebasis zurechtzufinden, verdächtige Stellen schneller einzugrenzen und mir Zusammenhänge erklären zu lassen, die ich selbst nicht bis ins letzte Detail durchdrungen hatte. Genau das war für mich ein wesentlicher Teil des Nutzens: Ich musste nicht erst die komplette Tvheadend-Codebasis verstehen, bevor ich sinnvoll an diesem konkreten Problem arbeiten konnte.

19:21 Uhr: Wenn ein Bug einen Sendetermin hat

Der Testzyklus war fast komischer als der Fehler selbst. Für die Patch-Tests nutzte ich an mehreren Tagen gezielt das kurze Fenster um ungefähr 19:21 Uhr. Zu diesem Zeitpunkt wechselte der getestete ORF2-Stream vom regionalen wieder auf das nationale Programm – genau jener Moment, an dem der problematische PID-Wechsel stattfand.

Der Ablauf war entsprechend entschleunigt: Code ändern, neu bauen, Tvheadend mit Patch starten und dann auf den Stream-Wechsel warten. Funktionierte es nicht, war die nächste aussagekräftige Wiederholung im Zweifel erst am folgenden Tag möglich. Mein Debugger hatte damit keinen Breakpoint, sondern einen Sendeplan.

So mühsam das war, hatte es auch einen Vorteil: Jeder Fortschritt musste sich am tatsächlichen Stream-Wechsel beweisen. Ein Patch, der im Code sauber aussah, war für mich erst dann interessant, wenn Tvheadend den Umschaltpunkt im Test überstand.

Der erste Fix: winziger Eingriff, große Wirkung

Die erste belastbare Ursache war erstaunlich unspektakulär. Beim ORF2-Wechsel werden Elementary Streams ersetzt, während der Service aktiv bleibt. In elementary_stream_create_parent() konnte Tvheadend bei einem verschobenen Teletext-Stream die Suche zu früh beenden. Dadurch wurde nicht mehr sicher der höchste bereits verwendete interne Komponentenindex berücksichtigt.

Im ungünstigen Fall bekamen zwei Komponenten denselben internen Index – beim dokumentierten ORF2-Fall etwa H.264-Video und Teletext. Der erste Pull Request #2204 macht im Kern etwas verblüffend Einfaches: Die vorhandene Stream-Liste wird vollständig durchsucht, bevor für den Ersatzstream ein neuer eindeutiger Index vergeben wird.

Das war der erste echte Aha-Moment. Ein Fehler, der im Test wie der komplette Tod eines Kanals aussah und immer wieder einen Neustart erforderte, ließ sich im Live-Pfad auf eine vergleichsweise kleine Logikänderung zurückführen.

Live-Stream repariert. Natürlich war die Geschichte damit nicht vorbei.

Der Patch durfte allerdings nicht nur den Live-Pfad reparieren. Tvheadend verarbeitet denselben Stream auch für Aufnahmen und Timeshift. Wenn sich die Quell-PIDs mitten im laufenden Service ändern, müssen deshalb auch diese Pfade verstehen, welcher neue Stream zum bisherigen Video, Audio oder Teletext gehört.

Für Pass-through-Aufnahmen brauchte es eine stabile Ausgabe-Zuordnung: Die Quell-PID darf wechseln, die Aufnahme soll nach außen trotzdem ein konsistentes Programm behalten. Timeshift war noch tückischer. Am 4. August wurde der kombinierte PR sogar wieder zum Draft, weil Live-TV und Recording bereits weiterliefen, zeitversetztes Live-TV nach einem PID-Wechsel aber noch nicht zuverlässig funktionierte.

Danach folgten mehrere Varianten und Tests, bis auch das Zurückspringen im Puffer und der Wechsel zurück auf live mit der jeweils richtigen Stream-Zuordnung funktionierten. Die Änderungen aus #2204 und #2205 stecken heute gebündelt im offenen PR #2206. Er enthält drei getrennte Bausteine: eindeutige Stream-Indizes, stabile PIDs für Pass-through-Aufnahmen und das Wiederherstellen der aktiven Stream-Zuordnung nach Timeshift-Seeks.

Vom KI-Vorschlag zum getesteten Patch

Codex half mir, die Zusammenhänge zwischen Stream-Reconfiguration, Recording und Timeshift schneller nachzuvollziehen und verschiedene Lösungswege auszuprobieren. Dabei wäre es übertrieben zu behaupten, ich hätte anschließend die komplette Codebasis oder jedes Detail vollständig verstanden. Für dieses konkrete Problem war das aber auch nicht nötig: Ich konnte mir die relevanten Stellen erklären lassen, nachfragen, Änderungen testen und Schritt für Schritt näher an die Ursache kommen.

Genau deshalb ist für mich der interessante Teil nicht „KI schreibt einen Patch“, sondern die Kombination aus KI, eigener Erfahrung und echten Tests. Ein überzeugend klingender Diff ist noch kein Beweis. Erst kompilieren, ausprobieren, Fehler beobachten, nachbessern und erneut testen macht daraus etwas, das in einer fremden Codebasis bestehen kann.

Was sich dadurch verändert hat: Man muss nicht jedes Detail eines Projekts bereits beherrschen, um sinnvoll einzusteigen. Wer die Grundlagen versteht – oder sie sich von der KI erklären lässt ;-) – präzise Beobachtungen liefert und die Ergebnisse gewissenhaft prüft, kann heute deutlich schneller in fremde Systeme vordringen. Genau so wurde aus diesem ORF2-Testfall am Ende ein Beitrag zur Tvheadend-Entwicklung.

Ist der ORF2-Fix schon in Tvheadend enthalten?

Nein, Stand 30. September 2026 noch nicht. #2206 ist offen und zur Review bereit, aber nicht gemergt. Das Issue #1973 ist weiterhin offen. Die Branch-Seite von #2206 weist zudem ausdrücklich darauf hin, dass dieser Branch nicht deployed ist.

Wer Tvheadend produktiv betreibt, sollte deshalb zwischen einem erfolgreichen Test-Build, einem offenen Pull Request, einem Merge nach master und einer tatsächlich ausgelieferten Version unterscheiden. Der Patch hat es vom Neustart-Workaround im Testfall bis zu einem sauber eingegrenzten und praktisch getesteten Fix geschafft – durch die Ziellinie des Projekts ist er damit noch nicht.

Quellen

• Tvheadend auf GitHub: Repository und master-Entwicklung
• GitHub Releases: v4.3 als Pre-release
• Offizielle Tvheadend-Container-Images
• Issue #1973: Black/Crash when switching from national to regional stream (ORF - Austria)
• PR #2204: mpegts: keep teletext stream indexes unique
• PR #2205: mpegts: preserve stream mapping across PID switches
• PR #2206: mpegts: combine ORF2 stream index and PID mapping fixes
• Tvheadend-Forum: ORF 2 Stream Crash on TVH Server