Anfragen an den technischen Support

Dieser Abschnitt hilft, eine Anfrage so vorzubereiten, dass die Analyse sofort beginnen kann, ohne Rückfragen hin und her. Er besteht aus einem Fragebogen, den Sie vor der Anfrage beantworten sollten, und einer Liste der Materialien, die ihr beigefügt werden.

Anfragen werden per E-Mail gesendet; die Adresse des Supports ist auf der Website https://pstreamer.tv/ angegeben.

Eine Anfrage darf keine privaten Informationen enthalten: Passwörter, Schlüssel, Geheimnisse, Adressen und Namen Ihrer Systeme und Abonnenten, Angaben zum Auftraggeber. Der Fragebogen ist so aufgebaut, dass keine Antwort solche Daten erfordert, und die Materialien werden vor dem Versand nach den Regeln des Abschnitts Private Daten bereinigt.

Fragebogen

Beantworten Sie die Fragen der Reihe nach. Ist eine Antwort unbekannt, schreiben Sie das: Auch das ist eine Information, und sie spart Zeit.

Knoten

  1. Welche Build-Version ist installiert? Sie wird auf dem Bildschirm Über das System im Abschnitt „Build & Bibliotheken“ angezeigt; auf der Kommandozeile gibt /usr/local/bin/pss -v sie zusammen mit den Versionen der eingebundenen Bibliotheken aus.

  2. Welches Betriebssystem in welcher Version? Läuft der Knoten auf einem physischen Server oder in einer virtuellen Maschine?

  3. Welche Hardware ist an dem Problem beteiligt: Prozessormodell und Speichergröße, Modelle der Netzwerkkarten, Grafikkarten und DVB-Karten?

  4. Arbeitet der Knoten allein oder gehört er zu einer Meshwork-Domain? Wenn zu einer Domain — wie viele Knoten hat sie, und läuft auf allen dieselbe Build-Version?

  5. Welcher Lizenztyp liegt vor, und ist die Lizenz gültig? Bildschirm Lizenz. Die Schlüssel-ID und die C2V/V2C-Dateien werden der Anfrage nicht beigefügt, solange der Support sie nicht anfordert.

Was geschieht

  1. Was wurde erwartet, und was geschieht stattdessen? Beschreiben Sie das Beobachtete, nicht die vermutete Ursache: „am HLS-Ausgang friert das Bild alle paar Minuten ein“, nicht „der Transcoder ist kaputt“.

  2. Wann trat das Problem zum ersten Mal auf und wann zuletzt? Geben Sie Zeiten mit Zeitzone an. Das Protokoll main.log schreibt die Zeit standardmäßig in UTC und ohne Jahr (Protokoll des Dienstes) — gleichen Sie beides miteinander ab.

  3. Ist das Problem dauerhaft, periodisch oder trat es einmal auf? Wenn periodisch — wie häufig, und gibt es eine Gesetzmäßigkeit: Tageszeit, Last, eine bestimmte Quelle?

  4. Lässt sich das Problem Schritt für Schritt reproduzieren? Wenn ja, führen Sie die Schritte auf.

  5. Was hat sich kurz vor dem Auftreten des Problems geändert: ein Update des Builds oder des Betriebssystems, eine Änderung der Einstellungen, ein Hardwaretausch, Änderungen im Netzwerk oder an der Quelle?

Betroffene Streams

  1. Welche Streams sind betroffen — die Stream-Nummern auf dem Knoten? Sind alle Streams betroffen, ein Teil oder einer?

  2. Welcher Transport liegt am Eingang und am Ausgang des betroffenen Streams an, handelt es sich um SPTS oder MPTS? Wird transkodiert, und wenn ja — welches Backend in welcher Version (Backends und Codecs, Bildschirm Über das System, Abschnitt „Transcoder“)?

  3. Welche Codecs und welche Bitrate hat die Quelle? Liegt ein Analysebericht vor (Was beizufügen ist), beantwortet er diese Frage.

  4. Liegt das Problem auf der Eingangs- oder der Ausgangsseite? Ist es in der Stream-Statistik sichtbar (Stream-Statistik) — Kontinuitätsfehler, Umschaltungen auf den Backup-Input, Pufferrücksetzungen?

  5. Wie verhält sich dieselbe Quelle unter Umgehung des Knotens oder auf einem anderen Knoten? Wie verhält sich eine andere Quelle auf demselben Stream?

Dienst und Ressourcen

  1. Wurde der Dienst im Zeitraum des Problems neu gestartet? Auf dem Bildschirm Logs ist jeder Start mit der Zeile „Streamer-Start“ markiert; ein Lauf, der ohne reguläres Herunterfahren endete, ist gesondert gekennzeichnet.

  2. Welche Alarme sind auf dem Knoten aktiv (Alarme)?

  3. Wie hoch ist die Auslastung von Prozessor, Speicher und Netzwerkschnittstellen zum Zeitpunkt des Problems? Bildschirm System-Monitor, Block „Verlauf“.

Was bereits unternommen wurde

  1. Welche Maßnahmen wurden bereits ergriffen, und welche davon haben geholfen: Neustart des Streams oder des Dienstes, Wechsel des Eingangs, Änderung der Einstellungen?

Chronologie des Vorfalls

  1. Beschreiben Sie den Ablauf der Ereignisse der Reihe nach, mit Zeitstempeln und Zeitzone:

    • den letzten Zeitpunkt, zu dem alles wie erwartet funktionierte;

    • danach vorgenommene Änderungen — am Knoten, im Netzwerk, an der Quelle oder beim Empfänger;

    • das erste Auftreten des Problems und wie es entdeckt wurde: Alarm, Beschwerde eines Abonnenten, eigene Beobachtung;

    • wie sich das Problem weiter entwickelte: verstärkte sich, verschwand von selbst, wiederholte sich;

    • jede ergriffene Maßnahme und was sich danach änderte;

    • den aktuellen Zustand zum Zeitpunkt der Anfrage.

    Die Chronologie fügt die Antworten auf die vorherigen Fragen zu einem Gesamtbild zusammen und ermöglicht es, die Ereignisse Zeile für Zeile mit dem Protokoll des Knotens abzugleichen.

Was beizufügen ist

Fügen Sie bei, was zum Problem gehört. Die folgende Liste nennt die häufigsten Materialien, keinen Pflichtumfang.

Das Protokoll des Dienstes für den Zeitraum des Problems — siehe Protokoll des Dienstes.

Transcoder-Protokolle, wenn das Transkodieren am Problem beteiligt ist — vor allem das „Vorheriges Log“ des Prozesses, außerdem der letzte Exit-Code und das aktuelle Log. Sie werden nur im Speicher des Knotens gehalten und gehen bei Neustarts verloren, sichern Sie sie daher zuerst — siehe Transcoder-Protokolle.

Einträge des Bildschirms Logs, gefiltert nach dem betroffenen Stream und dem Datumsbereich. Der vollständige Text eines einzelnen Eintrags wird mit der Schaltfläche „Meldung kopieren“ kopiert.

Screenshots der Statistik des betroffenen Streams (Stream-Statistik) und des Systemmonitors für denselben Zeitraum.

Einstellungen des betroffenen Streams — nur nach der Bereinigung (Private Daten). Eine vollständige Sicherung der Konfiguration vom Bildschirm Wartung enthält die Passwörter und Schlüssel aller Objekte des Knotens im Klartext; fügen Sie sie nur bei, wenn der Support darum bittet, und ebenfalls erst nach der Bereinigung.

Ein Analysebericht zur Quelle, wenn das Problem nach einem Defekt des Streams selbst aussieht: Das Werkzeug TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290 liest UDP oder eine Datei und gibt einen Text- oder XML-Bericht aus.

Diagnoseausgaben je nach Art des Problems:

Protokoll des Dienstes

Der Dienst schreibt sein Protokoll in die Datei main.log. Das Verzeichnis legt der Schlüssel log-dir der Datei pss.properties fest, standardmäßig /var/log/pss. Die Datei wird täglich rotiert: frühere Tage liegen daneben in Dateien main.log.<Zeitstempel>, für einen zurückliegenden Zeitraum brauchen Sie daher die Datei jenes Tages und nicht die aktuelle main.log.

Die Zeit in den Protokollzeilen ist ohne Jahr und standardmäßig in UTC angegeben; Ortszeit schaltet der Schlüssel log-time-local derselben Datei ein.

$ ls -l /var/log/pss/
$ tail -n 200 /var/log/pss/main.log
$ journalctl -u pss -n 50

Die beiden letzten Befehle sind nicht gleichwertig. Ist der Dienst gar nicht erst hochgefahren, kann die Ursache vor dem Protokoll selbst liegen — sein Verzeichnis ist nicht erreichbar, pss.properties lässt sich nicht lesen —, und dann steht in main.log keine Zeile darüber: Die Datei kann vom vorigen Start übrig sein und Altes zeigen. Eine solche Ursache gibt der Dienst in einer Zeile aus, die mit !!! beginnt, und sie ist im Systemjournal sichtbar, also in der Ausgabe von journalctl -u pss. Gewöhnliche Protokollzeilen gelangen nur dann ebenfalls dorthin, wenn in pss.properties log-to-console oder log-to-syslog aktiviert ist.

Die Protokollierungsstufe wird auf dem Bildschirm Server-Einstellungen festgelegt — eine allgemeine und gesonderte für die Bibliotheken SRT, RIST und FFmpeg. Eingänge und Ausgänge einzelner Transporte haben eine eigene Ablaufverfolgung — das Feld Trace (Eingangs- und Ausgangsfelder nach Transport). Erhöhen Sie die Stufe oder schalten Sie die Ablaufverfolgung nur ein, wenn der Support darum bittet, und stellen Sie nach dem Sammeln den vorherigen Wert wieder her: Ein ausführliches Protokoll wächst schnell.

Transcoder-Protokolle

Ist das Transkodieren am Problem beteiligt, ist das Protokoll des Transcoder-Prozesses das wichtigste Material der Anfrage: Die Ursache eines Kodier- oder Dekodierfehlers ist fast immer nur dort zu sehen.

Der Transcoder-Prozess führt stets ein ausführliches Protokoll, die Ablaufverfolgung muss nicht gesondert eingeschaltet werden. Dieses Protokoll wird jedoch nicht in eine Datei geschrieben: Der Knoten hält nur sein Ende im Speicher, die letzten 256 KB, und nur für zwei Starts des Prozesses — den aktuellen und den vorherigen. Geöffnet wird das Protokoll im Fenster Transcoder-Instanz (Bildschirm Transcoder), im Block „Prozess-Log“: „Aktuelles Log“, „Vorheriges Log“ und „Letzter Exit-Code“. Jedes Log wird mit der Schaltfläche „Kopieren“ übernommen.

Am wertvollsten ist das „Vorheriges Log“. Der fehlerhafte Prozess ist meist schon neu gestartet — vom Watchdog-Timer oder vom Knoten selbst —, und dann enthält gerade das vorherige Log den beendeten Start samt den Meldungen, die dem Fehler vorausgingen. Das aktuelle Log beschreibt bereits den neuen Start und zeigt nur, ob sich das Problem wiederholt.

Daraus ergeben sich folgende Regeln für das Sammeln:

  • Kopieren Sie das „Vorheriges Log“ sofort, sobald Sie das Problem bemerken. Jeder neue Start des Prozesses — ein Watchdog-Neustart, das Stoppen und erneute Starten des Streams — verschiebt die Logs um eine Position: Das aktuelle wird zum vorherigen, das bisherige vorherige wird gelöscht. Wiederholt sich der Fehler, bevor das Log kopiert ist, geht der Eintrag über den ersten Fehler verloren. Ein Neustart des Dienstes oder des Knotens löscht beide Logs.

  • Starten Sie weder den Stream noch den Dienst neu, bevor das Log kopiert ist — selbst wenn der Neustart den Betrieb wiederherstellt.

  • Fügen Sie zusammen damit den letzten Exit-Code und das aktuelle Log bei.

  • Bei einem lange laufenden Prozess ist der Anfang des Logs bereits verdrängt. Kommt es auf den Moment des Starts an — etwa die Wahl von Gerät und Treiber —, reproduzieren Sie das Problem nach einem Neustart des Streams und kopieren Sie das Log sofort.

Eine Zeile über das Prozessende bleibt auch im Protokoll des Dienstes erhalten: Beendet sich der Transcoder von selbst, schreibt der Knoten in main.log eine Warnung mit seiner letzten Meldung und dem Exit-Code. Diese Zeilen überstehen einen Neustart des Dienstes und helfen, den Zeitpunkt des Fehlers zu finden, selbst wenn das Prozess-Log bereits verloren ist:

$ grep -i 'transcoder' /var/log/pss/main.log

Fügen Sie den Transcoder-Protokollen Typ und Version des Backends vom Bildschirm Über das System (Abschnitt „Transcoder“) sowie die Diagnoseausgabe des Geräts bei — nvidia-smi oder vainfo (Was beizufügen ist).

Private Daten

Protokolle, Einstellungen und Screenshots enthalten Daten, die nicht in eine Anfrage gelangen dürfen. Ersetzen Sie sie vor dem Versand:

  • Passwörter, Passphrasen, Schlüssel und Geheimnisse — die vollständige Liste der Konfigurationsschlüssel, die sie speichern, steht im Abschnitt Werte, die nicht weitergegeben werden dürfen;

  • Adressen mit Zugangsdaten direkt im Link — bei der Quelle eines Eingangs und bei der Veröffentlichungsadresse auf einer externen Plattform;

  • IP-Adressen und Hostnamen von Quellen, Empfängern und Abonnenten sowie die Adressen des Knotens selbst;

  • Namen von Abonnenten, Logins von Konten, Kanalnamen und Angaben zum Auftraggeber, wenn sie für sich genommen Informationen preisgeben.

Ersetzen Sie konsequent: denselben Originalwert überall durch denselben Platzhalter (10.0.0.5 → HOST-A). Dann ist im bereinigten Protokoll weiterhin zu sehen, welche Zeilen zu einem Knoten gehören und welche zu verschiedenen, und die Analyse bleibt aussagekräftig.

Geben Sie in einer Anfrage keine Zugangsdaten für die Anmeldung am Knoten oder an seiner Weboberfläche weiter. Wird für die Analyse ein Zugang benötigt, wird die Art seiner Bereitstellung gesondert vereinbart.