Fehlerbehebung

Das Dashboard ist grün, aber kein Fernsehgerät empfängt etwas

Jeder Sender wird als laufend angezeigt. Die Bitraten sehen plausibel aus. Kein einziges Fernsehgerät hat ein Bild. Das ist mit großem Abstand der häufigste Fehler bei einer neuen Installation, und fast immer liegt es an der Multicast-Route.

Wahrscheinliche Ursache

Die Route für Multicast-Verkehr zeigt auf die falsche Netzwerkschnittstelle oder auf eine Schnittstelle ohne Link — nichts eingesteckt oder an einem toten Port. Die Pakete werden korrekt erzeugt und an eine Schnittstelle übergeben, die ins Nichts führt.

Warum das aus dem Prozess heraus unsichtbar ist

Das Senden eines UDP-Datagramms an ein nicht routbares Multicast-Ziel gelingt. Der Socket-Aufruf kehrt ohne Fehler zurück. Es gibt kein ICMP-Unreachable, das man beobachten könnte, keine Verbindung, die scheitert, keinen Wiederholungsversuch, den man zählen könnte. Folglich zeigt jeder Zähler im Streaming-Prozess einen einwandfreien Zustand, während nichts das Gebäude erreicht.

Keine Streaming-Engine kann das erkennen, und kein noch so häufiger Neustart ändert etwas daran. Es muss von außerhalb des Prozesses gegen die Routingtabelle des Hosts geprüft werden, und genau das tut Castmux.

Das Binden des Ausgangs-Sockets an eine Quelladresse löst das Problem nicht. Der Kernel wählt die Ausgangsschnittstelle weiterhin anhand der Routingtabelle; die Quelladresse bestimmt nur, was im Paket-Header steht.

So bestätigen Sie es

Zwei Befehle auf dem Gerät. Fragen Sie den Kernel, wohin ein Datagramm für die Gruppe des Senders tatsächlich ginge, und sehen Sie dann nach, welche Schnittstellen einen Link haben:

# Substitute the destination group of an affected channel
ip route get 239.10.0.1

# Which interfaces are actually up, and which are merely configured
ip -brief link

Der erste Befehl nennt die Schnittstelle, die verwendet wird. Ist es nicht die Schnittstelle zu den Fernsehgeräten, haben Sie den Fehler gefunden. Ist es die richtige Schnittstelle, zeigt ip -brief link sie aber als DOWN oder ohne Link an, haben Sie den Fehler ebenfalls gefunden.

Linklokale Adressen führen Sie in die Irre

Eine Schnittstelle hat häufig sowohl eine linklokale Adresse aus 169.254.0.0/16 als auch ihre eigentliche Adresse, und ip -brief führt oft die linklokale zuerst auf. Wenn Sie Schnittstellen an der ersten ausgegebenen Adresse erkennen, halten Sie womöglich eine andere Netzwerkkarte für die zu den Fernsehgeräten, als es tatsächlich ist. Lesen Sie die ganze Zeile.

Lösung

Leiten Sie den gesamten Multicast-Bereich auf die Schnittstelle zu den Fernsehgeräten, und sorgen Sie dafür, dass die Änderung einen Neustart übersteht — ein von Hand eingegebener ip route-Befehl geht beim nächsten Neustart des Geräts verloren. So kehrt dieser Fehler Wochen später zurück, und niemand erinnert sich mehr an das erste Mal. Installation beschreibt die mitgelieferte Routing-Unit, die die Route regelmäßig neu bewertet, sodass sie dem Kabel folgt, wenn der Link wechselt.

Korrigieren Sie den Bereich, niemals einzelne Gruppen

Eine Host-Route für eine Gruppe — ein /32 für 239.10.0.1 — bringt diesen einen Sender zum Laufen und lässt 224.0.0.0/4 weiterhin defekt. Jeder danach hinzugefügte Sender ist unbemerkt unroutbar, und der Grund ist nicht offensichtlich, weil die Sender, die funktioniert haben, weiterhin funktionieren.

Genau dieser Fehler hat zwei getrennte, stundenlange Störungen verursacht. Die eine zeigte sich als Container, der stundenlang alle fünfzehn Minuten neu startete, die andere als einzelner Sender, der alle dreißig Sekunden neu anlief. Beide wurden als Engine- und Watchdog-Fehler untersucht. Keiner von beiden war es. Routen Sie den Bereich.

Castmux prüft die Routingtabelle von außerhalb des Prozesses und meldet ein Ziel als nicht routbar, wenn es das ist. Den Sender startet es in diesem Fall bewusst nicht neu: Ein Neustart kann einen Routingfehler nicht beheben, und eine Neustartschleife würde die eine Logzeile verschütten, die die eigentliche Ursache nennt. Siehe Überwachung.

Pixelbildung und Ruckeln auf einem Sender

Das Bild zerfällt in Blöcke oder friert ein und springt, auf einem Sender, während die anderen in Ordnung sind.

Am wahrscheinlichsten: zwei Absender auf derselben Gruppe

Zwei Prozesse senden an dasselbe Multicast-Ziel. Die Fernsehgeräte empfangen beide Streams verschachtelt, und das Ergebnis ist ständige Bildstörung. Meist steckt eine Migration dahinter: ein älterer Dienst aus einer früheren Installation, der noch läuft, oder eine System-Unit, die deaktiviert, aber nicht gestoppt wurde, neben der neuen Installation. Beide Absender sehen aus eigener Sicht völlig gesund aus, weil jeder einen gültigen Stream erzeugt.

Bestätigen Sie es mit dem Alarm für doppelte Absender, der ausgelöst wird, wenn Castmux Verkehr zu einem seiner Ziele beobachtet, den es nicht selbst gesendet hat, und indem Sie auf dem Gerät und im Netzwerk nach einem anderen Prozess suchen, der an dieselbe Gruppe und denselben Port sendet. Beheben Sie es, indem Sie den älteren Absender ordnungsgemäß stoppen — das Deaktivieren einer Unit hindert nichts anderes daran, sie zu starten, prüfen Sie also auch geplante Jobs.

Ziehen Sie außerdem in Betracht

• Verluste auf der Quellseite. Der Ursprungsserver liefert einen beschädigten Stream, und Sie leiten ihn getreu weiter. Um das unverfälscht zu sehen, betreiben Sie den Sender mit der Pass-through-Engine: Sie erhält die ursprünglichen Continuity Counter, sodass eine nachgelagerte Analyse die Verluste zeigt. Die Remux-Engine setzt die Continuity Counter neu; dadurch sieht der Ausgang strukturell sauber aus, und es bleibt verborgen, woher der Schaden kam. Siehe Streaming-Engines.
• Ein überbuchter Multiplex, wenn der Sender über DVB-C übertragen wird. Übersteigt die gemeinsame Bitrate der Services, was der Träger aufnehmen kann, verschlechtert sich alles in diesem Multiplex, nicht nur der Sender, den jemand gemeldet hat. Siehe DVB-C-Multiplexing.
• Switches ohne IGMP-Snooping. Ohne Snooping wird jeder Multicast-Stream an jeden Port geflutet. Ein Dutzend Sender kommt dann bei jedem Fernsehgerät und jedem anderen Gerät im Segment an, und die Access-Ports laufen voll. Das Symptom ist meist Pixelbildung auf vielen Sendern gleichzeitig, die mit jedem weiteren Sender schlimmer wird.

Ein Sender startet immer wieder neu

Die Laufzeit wächst nie über ein oder zwei Minuten hinaus. Lesen Sie zuerst das Log dieses Senders in der Oberfläche: Der Grund jedes Neustarts wird dort festgehalten, und er unterscheidet die meisten der folgenden Ursachen ohne weitere Untersuchung.

Quelle nicht erreichbar oder unzuverlässig

Der Ursprungsserver bricht die Verbindung ab oder ist nur zeitweise erreichbar. Castmux wartet zunehmend länger, statt ihn mit Anfragen zu überhäufen, und das Backoff wird nach einem längeren fehlerfreien Lauf zurückgesetzt. Prüfen Sie den Ursprungsserver, bevor Sie irgendetwas am Gerät ändern.

Der Ursprungsserver veröffentlicht eine IPv6-Adresse, die das Gerät nicht erreichen kann

Äußerst häufig, selten vermutet. Siehe Alles startet langsam weiter unten — es verursacht beide Symptome.

SRT-Latenz zu niedrig eingestellt

Die konfigurierte Latenz muss die Round-Trip-Zeit der Verbindung abdecken und Raum für Neuübertragungen lassen. Ist sie zu niedrig, scheitert die Fehlerkorrektur, und die Sitzung bricht immer wieder ab.

Ein Watchdog, der an einem Messwert hängt, den es für die Engine nicht gibt

Eine externe Überwachung, die bei Bildern pro Sekunde oder Wiedergabegeschwindigkeit alarmiert, startet gesunde Pass-through-Sender endlos neu, weil es diese Messwerte für diese Engine nicht gibt. Siehe den Warnhinweis unter Überwachung.

Ein überlasteter Uplink beim Start

Starten alle Sender auf einmal, öffnet jeder gleichzeitig seine Verbindung zum Ursprungsserver, und der Uplink kann nicht alle bedienen; mehrere laufen in ein Timeout, starten neu und versuchen es wieder gemeinsam. Genau dagegen gibt es den gestaffelten Start. Wurde er verkürzt oder abgeschaltet, stellen Sie ihn wieder her.

Ein Sender startet überhaupt nicht

Prüfen Sie diese Punkte der Reihe nach. Die Liste ist danach geordnet, wie oft sich der jeweilige Punkt als Antwort herausstellt, nicht danach, wie interessant er ist.

1. Ist der Sender aktiv? Ein deaktivierter Sender wird überhaupt nicht eingeplant.
2. Ist er ein Sender on demand ohne Zuschauer? Das ist der häufigste Fehlalarm auf der Seite. Ein Sender on demand, den niemand sieht, soll gerade nicht laufen. Zur Bestätigung öffnen Sie seine Vorschau; sie zählt als Zuschauer und startet ihn. Siehe On-Demand-Streaming.
3. Ist die Quelle vom Gerät aus erreichbar? Nicht von Ihrem Laptop — vom Gerät. Anderes DNS, anderes Routing, andere Firewall-Regeln, womöglich ein anderes VLAN. Eine Quelle, die auf Ihrem Rechner in VLC einwandfrei läuft, sagt Ihnen, dass der Ursprungsserver lebt, aber nichts darüber, ob das Gerät ihn erreicht.
4. Wird das Ziel bereits von einem anderen Sender verwendet? Zwei Sender mit derselben Gruppe und demselben Port sind derselbe Fehler mit doppelten Absendern wie oben, nur lokal verursacht.
5. Bei DVB-C: Konnte der Sender untersucht werden? Ein Service, der nicht untersucht werden konnte, lässt sich keinem Multiplex zuweisen. Siehe DVB-C-Multiplexing.

Alles startet langsam, und Abrufe dauern Sekunden

Sender brauchen unverhältnismäßig lange zum Starten, Playlist-Abrufe dauern Sekunden, und die Langsamkeit ist uneinheitlich — manchmal ist dieselbe Anfrage schnell.

Ursache

Der Ursprungsserver veröffentlicht einen IPv6-AAAA-Eintrag, und das Gerät hat keine funktionierende IPv6-Route. Die Adressauswahl bevorzugt IPv6, also versucht jede HTTP-Anfrage zuerst IPv6 und fällt erst danach auf IPv4 zurück. Was dieser Rückfall kostet, hängt ganz davon ab, wie der IPv6-Versuch scheitert:

Wie der IPv6-Versuch scheitert	Kosten pro Anfrage
Sofortige Ablehnung	Einige hundert Millisekunden. Lästig, aber verkraftbar.
Route ins Leere (Blackhole)	Ein vollständiger Verbindungs-Timeout, ohne dass ihn etwas vorzeitig abbricht. Daher kommen die Hänger von mehreren Sekunden.

Bei jeder Playlist- und jeder Segmentanfrage bezahlt, reicht das, damit ein Sender sein Timing verfehlt und neu startet. In einem Fall führte es dazu, dass ein Sender an einem einzigen Tag 765-mal neu startete.

Dieser Fehler wird oft falsch diagnostiziert — messen Sie ihn also richtig

Derselbe Vorfall wurde zunächst einem langsamen Ursprungsserver zugeschrieben, auf Grundlage eines einzigen gemessenen Abrufs, der 10.8 Sekunden dauerte. Wiederholte Läufe desselben Abrufs dauerten 0.59 Sekunden. Eine einzelne Messung eines Fehlers, der nur manchmal in einen Timeout läuft, bestätigt Ihnen, was Sie ohnehin schon glaubten. Führen Sie den Abruf zehnmal aus und betrachten Sie die Verteilung.

Lösung

Konfigurieren Sie das Gerät so, dass es bei der Adressauswahl IPv4 gegenüber IPv6 bevorzugt. Tun Sie das an beiden Stellen: auf dem Host und im Container, der seine eigene Kopie der Richtlinie zur Adressauswahl mitbringt. Wird nur der Host korrigiert, bleibt der Streaming-Prozess — der, der die Anfragen stellt — unverändert, und das Symptom verändert sich überhaupt nicht. Das wird dann meist so gedeutet, als sei die Diagnose falsch.

Der Sender läuft, aber ohne Ton oder in der falschen Sprache

Das Bild stimmt, der Ton fehlt, oder es ist nur eine Sprache verfügbar, obwohl die Quelle mehrere führt. Drei verschiedene Ursachen:

• Die Remux-Engine leitet nur eine einzige Audiospur weiter. Ihre Standard-Streamauswahl nimmt einen Video- und einen Audiostream und verwirft den Rest. Braucht die Installation mehrere Sprachen, betreiben Sie den Sender mit der Pass-through-Engine. Sie überträgt jede Audio-PID zusammen mit der ursprünglichen Programmtabelle und deren Sprachdeskriptoren, sodass das Fernsehgerät die Auswahl anbieten kann. Siehe Streaming-Engines.
• Eine demultiplexte HLS-Qualitätsleiter. Wo der Ursprungsserver das Audio als separate Renditions veröffentlicht, statt es in die Videovarianten zu multiplexen, würde die Auswahl einer einzelnen Videovariante stummes Video auf Sendung bringen. Die Schutzregel der Auflösungsprofile erkennt das, behält genau deshalb die Master-URL bei und zeigt das am Sender an. Haben Sie die Quell-URL von Hand auf eine Videovariante einer solchen Leiter gesetzt, ist das der Ort, an dem der Ton verloren ging. Siehe Auflösungsprofile.
• Die Quelle führt tatsächlich nur eine Spur. Keine Engine-Einstellung erzeugt eine Audiospur, die der Eingang nicht enthält. Prüfen Sie das am Ursprungsserver, bevor Sie irgendetwas anderes verfolgen.

Ein Schalter in der Oberfläche widerspricht dem Badge daneben

Ein Schalter zeigt einen Zustand, während der daneben angezeigte Status, der auf demselben Wert beruht, den anderen zeigt.

Das ist Browserverhalten, kein Anwendungszustand. Bei einem einfachen Neuladen oder beim Zurücknavigieren stellen Browser Formularelemente auf den vorherigen Zustand zurück und ignorieren den Zustand, den der Server in der Seite geschickt hat. Das Badge ist reiner Text und spiegelt den Server wider; der Schalter ist ein Bedienelement und spiegelt die Erinnerung Ihres Browsers an die vorherige Seite wider.

Erzwingen Sie ein vollständiges Neuladen, dann stimmen beide überein. Dass das bei einem Produkt wie diesem überhaupt auftritt, liegt daran, dass Senderkennungen nach dem Löschen wiederverwendet werden: Legen Sie einen Sender an, löschen Sie ihn und legen Sie einen weiteren an, dann belegt der neue die alte Kennung — und der Browser überträgt den Schalterzustand des gelöschten Senders munter auf seinen Nachfolger.

Die Fernsehgeräte haben nach einer Änderung der Senderliste ihre Programmplätze verloren

Bei DVB-C speichern Fernsehgeräte Sender anhand der Service-Kennungen, die im Multiplex übertragen werden. Eine Änderung der Slot-Reihenfolge ändert diese Kennungen, sodass die Fernsehgeräte ihre gespeicherten Sender nicht mehr wiedererkennen und neu abgestimmt werden müssen — im ganzen Gebäude, und genau diese Arbeit will niemand machen.

Solange sich die Service-Kennung nicht unabhängig von der Slot-Reihenfolge festlegen lässt geplant, sollten Sie einen laufenden Multiplex nicht umsortieren. Hängen Sie neue Services an, statt sie einzufügen, und planen Sie die Reihenfolge, bevor die Geräte abgestimmt werden, nicht danach. Siehe DVB-C-Multiplexing.

Was Sie an den Support schicken sollten

Die folgenden Angaben machen aus einem tagelangen Hin und Her eine einzige Antwort. Sammeln Sie sie, bevor Sie die Nachricht schreiben, nicht erst, wenn danach gefragt wird.

• Den Sendernamen, seine Quell-URL sowie seine Zielgruppe und seinen Port.
• Das Log dieses Senders aus der Oberfläche.
• Die Ausgabe von ip route get <group> für das betroffene Ziel.
• Die Ausgabe von ip -brief link.
• Die Konfigurationsdatei, ohne Zugangsdaten.
• Ob der Fehler einen Sender betrifft oder alle — das allein trennt ein Quellenproblem von einem Netzwerkproblem.
• Ob sich am Netzwerk etwas geändert hat. Ein Switch ausgetauscht, ein VLAN geändert, ein Kabel umgesteckt, ein Firmware-Update. Die Antwort ist häufiger Ja, als man erwartet.