Versionsverlauf

Version 2.0.2.423

26.10.2026

  • Demoversion — kostenlose Edition zur technischen Evaluierung, Paket pstreamer-demo: ohne Schutzschlüssel und Aktivierung, ohne zeitliche Begrenzung, nur zum Kennenlernen (kommerzielle Nutzung untersagt). Funktionsumfang und Einschränkungen — Demoversion.

  • Demoversion: DVR-Feld ohne Fehler — auf der Registerkarte „OTT“ des Stream-Editors erscheint nach der Wahl des Modus „OTT / HLS“ unter dem Feld „DVR-Speicher“ nicht mehr der Fehler „DVR-Speicher konnten nicht geladen werden“: Das Feld zeigt nur „In der Demo nicht verfügbar“ (Vergleich der Editionen).

  • Aktualisieren Sie die Transcoder zusammen mit dem Streamer — benötigt werden pstreamer-tcnv 1.2.0.128, pstreamer-tcsw 1.2.0.127 und pstreamer-tcivpl 1.1.0.56 oder neuer: Ein Transcoder einer früheren Version kann beim Anhalten des Dienstes abstürzen, und das Logo auf dem Software-Transcoder erfordert die neue Version von tcsw. Starten Sie nach dem Update der Transcoder den Dienst neu (Dateien und Installationsprüfung).

  • Autostart des Dienstes bei einem Paket-Update — ein Update des rpm-Pakets deaktiviert den Autostart des Dienstes pss nicht mehr und hält ihn nicht mehr an: Bisher startete der Streamer nach einem solchen Update und einem Neustart des Servers nicht von selbst. Jetzt, auch beim Update von 2.0.2.408, bleibt der Autostart aktiviert, und ein laufender Dienst wird auf der neuen Version neu gestartet; ein Dienst, den der Administrator angehalten oder deaktiviert hat, bleibt so. Ein Update des deb-Pakets aktiviert keinen vom Administrator deaktivierten Autostart mehr. Der Systembenutzer pss wird beim Update nicht mehr gelöscht und neu angelegt. Wurde eine rpm-Installation früher aktualisiert, prüfen Sie den Autostart mit systemctl is-enabled pss und aktivieren Sie ihn bei der Antwort disabled: sudo systemctl enable pss (Installation auf Systemen der RHEL-Familie).

  • OTT-, DVR- und DRM-Einstellungen ohne Sendeunterbrechung — das Speichern der Einstellungen für OTT, DVR und DRM eines laufenden Streams startet nur die OTT-Auslieferung und die Archivaufzeichnung neu: Eingänge und Ausgänge (UDP, SRT und andere) arbeiten ohne Unterbrechung weiter, die Uptime des Streams wird nicht zurückgesetzt. Bisher startete jede solche Änderung alle Eingänge und Ausgänge des Streams neu, und an den Ausgängen gab es eine kurze Unterbrechung. Archivtiefe und LL-Part-Zieldauer werden im laufenden Betrieb übernommen, ohne Neustart. Einstellungen, die den Transportstrom selbst ändern (Dienstname, Programm, PID-Filter, PAT/PMT/PCR-Korrekturen, EPG-Quelle), starten Eingänge und Ausgänge wie bisher neu (OTT und DVR).

  • Klonen von Streams — in der Weboberfläche werden ein Stream oder mehrere markierte Streams samt Eingängen und Ausgängen kopiert: Die Kopie wird pausiert und mit der Endung -copy im Namen angelegt, und die Übersicht führt die Ports und Adressen auf, die mit dem Quellstream übereinstimmen (Klonen von Streams).

  • Anmeldung an der Weboberfläche ohne Browserfenster — beim Öffnen der Weboberfläche von einem anderen Computer zeigt der Browser vor dem Formular der Weboberfläche kein eigenes Anmeldefenster mehr. Eine API-Anfrage an einen Pfad /data/… mit dem Header X-Requested-With: XMLHttpRequest erhält bei Ablehnung 401 ohne Digest-Challenge; Skripte, die sich per Digest anmelden, sollten diesen Header nicht senden (Anmelden, Zugang).

  • Reklamationsassistent in der Weboberfläche — solange ein SPTS-Stream einen aktiven TR 101 290-Verstoß oder eine PCR-Drift aufweist, wird in der Stream-Zeile und im Statistikfenster das Symbol „KI-Brief“ angezeigt: Es öffnet eine fertige Anfrage für einen KI-Chat, der daraus ein Reklamationsschreiben an den Anbieter verfasst. Die Anfrage steht nur der Rolle Admin zur Verfügung, das Schreiben ist immer auf Englisch (die Sprachauswahl wurde entfernt), und von der Quelle gelangt nur die Eingangsadresse ohne Logins, Passwörter und Schlüssel in die Anfrage. Ohne aktiven Verstoß erstellt der Knoten keine Anfrage (Reklamationsassistent).

  • Verschieben des vergrößerten Mosaik-Einzelbildes — im Fenster „Originalbild“ lässt sich das vergrößerte Bild mit der Maus bei gedrückter rechter Taste verschieben, auf Telefon und Tablet mit zwei Fingern vergrößern und mit einem Finger verschieben (Originalbild).

  • OTT-Name des adaptiven Bundles ohne Leerzeichen — das Feld „OTT-Name“ eines adaptiven Bundles nimmt keine Leerzeichen mehr an: Sie störten die Wiedergabe und den Playlist-Export. Auch der Streamer entfernt sie — beim Hinzufügen und Ändern eines Bundles über die API und beim Laden der Einstellungen (mit einem Protokolleintrag); der bereinigte Name wird beim nächsten Speichern geschrieben. Stimmen nach dem Entfernen der Leerzeichen die Namen zweier Bundles überein, werden die Einstellungen trotzdem geladen: Der zweite Name wird nicht ausgeliefert, ins Protokoll wird eine Warnung geschrieben (früher wurden solche Einstellungen nicht geladen) (Adaptives Bundle).

  • Export nach M3U: adaptive Bundles und DASH — in die Playlist werden jetzt auch adaptive Bundles exportiert: die HLS-Master-Playlist und das DASH-Manifest des Bundles, jeweils solange mindestens ein Stream des Bundles sie ausliefert. Die Option „Alle aktiven“ fügt nach den Streams alle laufenden Bundles hinzu, und das neue Protokoll DASH umfasst die Manifeste der Bundles und die Streams im DASH-Modus. Bisher ließen sich ausgewählte Bundles nicht exportieren (Export und Import von M3U).

  • Logo im Bild des Transcoders — auf die Ausgänge eines NVIDIA-Transcoders und des Software-Transcoders (CPU) lässt sich ein Logo aus einer PNG-Datei legen: an jedem Ausgang mit eigener Datei, Position, Deckkraft und Hintergrundunschärfe unter dem Logo. Das Logo wird nicht skaliert; die Weboberfläche prüft sofort, ob es in das Bild des Ausgangs passt, und zeigt eine maßstabsgetreue Vorschau. Die Logo-Dateien werden in der Weboberfläche hochgeladen und auf dem Knoten gespeichert. Das Backend eines Decoders mit Logo lässt sich zwischen NVIDIA und Software umschalten; bei gleichen Größeneinstellungen kann ihr Bild um einige Pixel abweichen, und das Logo muss in das Bild des gewählten Backends passen. Intel hat kein Logo (Logo im Bild).

  • Schnelles Anhalten und Neustarten — Transcoder, die externen Befehle von std-Eingängen und -Ausgängen und der Alarmbefehl werden zusammen mit dem Dienst beendet, und während des Anhaltens startet der Knoten Transcoder nicht mehr neu. Bisher reagierten sie nicht auf das Stoppsignal, und das Anhalten oder Neustarten des Dienstes wartete, bis das System sie zwangsweise beendete — meist etwa 15 Sekunden.

  • Transcoder-Statistik — die Decoder-Warteschlange und die Latenz frieren nicht mehr ein, nachdem der Knoten den Transcoder neu gestartet hat.

  • Alarme nach Gruppen — die Ansicht „Alarme“ gruppiert die geltenden Alarme standardmäßig nach Knoten und nach Code, mit der Anzahl der Zeilen und dem höchsten Schweregrad in der Gruppenüberschrift; große Gruppen öffnen sich zugeklappt. Die Markierungen „anhaltender Resync“ und „Reserveeingang“ heben Empfehlungen zur Neusynchronisierung und Fehler von Reserveeingängen von aktuellen Ausfällen ab. Die bisherige Liste ist über den Umschalter „Liste“ erreichbar (Alarme).

  • Alarme ohne Flackern — ein Alarm zu den Ressourcen eines Knotens (CPU, Speicher, Netzwerk, GPU, GPU-Videospeicher, DVR-Storage, Worker-Threads der DVB-Adapter) wird erst ausgelöst, wenn der Wert 30 Sekunden lang jenseits des Schwellenwerts bleibt, und nach 60 Sekunden unter dem Schwellenwert behoben. Der Alarm zu Continuity-Counter-Fehlern eines Streams (Code 15) wird erst ausgelöst, wenn die Verluste 30 Sekunden lang andauern, und nach 60 Sekunden ohne Verluste behoben; der Fehlerpegel bleibt bestehen, bis die Anzahl der Fehler unter die Hälfte des Schwellenwerts fällt. Bisher erzeugten eine Last, die über den Schwellenwert hin und her sprang, und einzelne verlorene Pakete Alarme, die binnen Sekunden erschienen und wieder verschwanden. Die Zeiten werden auf dem Bildschirm „Alarmierung“ festgelegt (Parameter system-alert-raise-sec, system-alert-clear-sec, stream-cc-raise-sec und stream-cc-clear-sec im Abschnitt alerter); 0 stellt das bisherige Verhalten wieder her (Alerter-Einstellungen).

  • Alarm zur Belegung des GPU-Videospeichers — ein neuer Alarm mit Code 64 für jede NVIDIA-Karte: eine Warnung bei 85 % belegtem Videospeicher, ein Fehler bei 95 % (Zeile „GPU-Videospeicher“ des Bildschirms „Alarmierung“, Parameter gpu-mem-warning-pct und gpu-mem-error-pct; 0 schaltet den Pegel ab). Eine Karte mit vollem Videospeicher startet keinen neuen Transcoder-Kanal, obwohl ihre Auslastung normal aussehen kann. Für Intel-GPUs gibt es diesen Alarm nicht. Die Daten des Systemmonitors (/data/sysmon) zeigen für jede NVIDIA-Karte den belegten und den gesamten Videospeicher sowie die Belegung in Prozent, der Systemmonitor der Weboberfläche zeigt einen Balken „Videospeicher“; der bisherige Balken „Speicher“ einer NVIDIA-Karte heißt jetzt „Speicherbandbreite“. Bei aktivierter Replikation von System-Alarmen zeigen Knoten früherer Versionen in derselben Domäne diesen Alarm ohne Namen an, bis sie aktualisiert werden (Katalog der Alarmcodes).

  • Defekte Reserve — in einem einzigen Alarm — der neue Alarm mit Code 65 (Stufe „Warnung“, einer pro Stream) listet die Eingänge auf, die im Fehlerzustand sind, während der Stream über einen anderen Eingang läuft. Solche Eingänge halten keine eigenen Zeilen mit Code 1 mehr, und Code 1 ist jetzt immer kritisch: Der Stream hat seine Quelle verloren. Ein externes Ziel erhält die Aufhebung der Zeilen mit Code 1 und das Auslösen von Code 65 statt der früheren Aktualisierung „kritisch“ → „Fehler“. Eingestellt wird er im Block „Backup-Eingänge (Code 65)“ des Bildschirms „Alarmierung“ (Katalog der Alarmcodes).

  • Leisere Resynchronisations-Alarme — der Alarm mit Code 61 (PCR-Bruch ohne Verluste) ist jetzt informativ und standardmäßig aus; sein Schwellenwert ist ein eigener Schlüssel stream-sync-absorbed-count. Die Codes 58, 59 und 61 werden nach zwei Stunden unter dem Schwellenwert aufgehoben statt nach sechs Stunden ohne ein einziges Ereignis, und die Zeile des Eingangs, von dem der Stream umgeschaltet hat, wird sofort aufgehoben. Die Schwellenwerte und die Zahl ruhiger Stunden werden im neuen Block „Eingangs-Resync (Codes 58, 59, 61)“ des Bildschirms „Alarmierung“ festgelegt (Katalog der Alarmcodes).

  • ACME-Alarm wird von selbst behoben — der Alarm über einen Fehler bei der Ausstellung eines Zertifikats wegen eines Problems auf dem Knoten (kein HTTPS-Server mit dem Hostnamen, Port der HTTP-01-Prüfung belegt, Kontoschlüssel) wird nach dem ersten Versuch behoben, der diesen Schritt besteht; bisher hielt er sich bis zum Ausschalten der automatischen Ausstellung (Katalog der Alarmcodes).

  • Externe Alarme: Auslösen und Behebung als Paar — die Schwelle des Mindestschweregrads der Kanäle „Prozess“, Telegram und E-Mail gilt für den Vorfall, nicht für jede einzelne Nachricht. Ein Vorfall, dessen Schweregrad bis zur Schwelle gestiegen ist, wird im Moment der Erhöhung gemeldet, und die Behebung kommt immer, wenn das Auslösen gemeldet wurde. Bisher kam bei einer Änderung des Schweregrads relativ zur Schwelle eine Behebung ohne Auslösen oder ein Auslösen ohne Behebung (Wann das Skript gestartet wird).

  • Alarmskripte und stderr — die Fehlerausgabe des Skripts wird gelesen, während das Skript läuft: Umfangreiche Ausgaben nach stderr führen nicht mehr zu einem Timeout, und ein im Hintergrund zurückgelassener Prozess hält die nächsten Alarme nicht auf. Als Zustellfehler gilt nur ein Exit-Code ungleich null; ins Protokoll gelangen die letzten 4 KB von stderr (Ergebnis, Timeout und Protokoll).

  • Meshwork: Schutz des Austauschs zwischen Knoten — ein Knoten prüft, ob die Antwort eines Nachbarn mit demselben Secret oder dem Schlüssel der Domäne signiert ist, also von einem echten Teilnehmer des Netzwerks stammt, und lehnt eine Nachricht eines Nachbarn ab, die früher aufgezeichnet und erneut gesendet wurde, ebenso eine Nachricht, die an einen anderen Knoten adressiert ist. Der Domänenschlüssel wird verschlüsselt übertragen: Ein aufgezeichneter Austausch, der später wiederholt wird, erhält ihn nicht. Bisher konnte, wer auf die Verbindung antwortete (eine abgefangene Verbindung über HTTP oder TLS ohne Zertifikatsprüfung), Knotendaten, Anmeldesitzungen und den Domänenschlüssel unterschieben. Es muss nichts konfiguriert werden (Nachbarn und Secrets).

  • Meshwork: Die Uhren der Knoten müssen synchronisiert sein — einen Knoten, dessen Uhr um mehr als 5 Minuten von der eines Nachbarn abweicht, lehnt dieser Nachbar ab, und die Verbindung wird als nicht erreichbar angezeigt. Beide Knoten schreiben eine Warnung mit dem Namen des Nachbarn und der Größe der Abweichung ins Protokoll; die erste Warnung erscheint schon bei der halben Toleranz. Die Toleranz legt der neue optionale Parameter cluster-hello-window-sec fest (standardmäßig 300 Sekunden, 0–86400); 0 schaltet die Uhrenprüfung für Knoten ab, deren Uhren sich nicht synchronisieren lassen, wiederholte Nachrichten werden aber auch dann abgelehnt. Prüfen Sie vor dem Update, dass auf allen Knoten NTP läuft (Anforderungen und Erreichbarkeit).

  • Update und Zurücksetzen von Meshwork — aktualisieren Sie nach Möglichkeit alle Knoten der Domäne gleichzeitig. Ist das nicht möglich, aktualisieren Sie zuerst die Knoten, mit denen sich die übrigen verbinden (zentrale Knoten und Knoten mit öffentlichen Adressen), danach die Knoten hinter NAT. Solange in der Domäne Knoten unterschiedlicher Versionen laufen, ist der Datenaustausch eingeschränkt, und Nachrichten von Knoten älterer Versionen lassen sich noch wiederholen. Ein Knoten, der auf eine frühere Version zurückgesetzt wurde, wird von seinen Nachbarn mit der neuen Version bis zu deren Neustart abgelehnt: Setzen Sie die ganze Domäne zurück oder starten Sie die Knoten mit der neuen Version nach dem Zurücksetzen neu (Aktualisierung der Knoten einer Domäne).

  • Ruhiger bei geplanten Neustarts von Meshwork-Knoten — der Alarm über einen nicht erreichbaren Knoten (Code 26) wird nach einer Minute Schweigen ausgelöst statt nach 15 Sekunden, sodass ein kurzer Neustart eines Nachbarn nicht die ganze Domäne weckt. Ein Knoten, der absichtlich gestoppt oder neu gestartet wird, warnt zuerst seine Nachbarn (Knoten älterer Versionen erhalten die Benachrichtigung nicht), und diese lösen 5 Minuten lang keinen Alarm für ihn aus, während er in der Knotentabelle als „Neustart (N s)“ geführt wird. Die Zeiten legen die Felder des Blocks „Meshwork-Kontakt (erweitert)“ der Servereinstellungen fest (Parameter cluster-node-down-sec und cluster-leave-grace-sec im Abschnitt cluster, Katalog der Alarmcodes). Behoben: Ein Knoten konnte sich im Netzwerk doppelt anzeigen und seine eigenen Alarme wiederholen, als kämen sie von einem Nachbarn.

  • Ändern der Meshwork-Einstellungen — das Speichern der Einstellungen entfernt automatisch erkannte Knoten nicht mehr aus der Netzwerkkarte und hebt deren Alarme „ein Netzwerkknoten ist verstummt“ nicht mehr irrtümlich auf (Katalog der Alarmcodes).

  • Automatische Anmeldung von einem anderen Knoten der Domäne — eine Sitzung der automatischen Anmeldung, die von einem anderen Knoten der Domäne kommt, erhält auf einem Knoten ohne ein solches Konto die Rolle Viewer. Gibt es das Konto auf dem Knoten, gilt wie bisher dessen Rolle (Webserver & Konten).

  • Externes Billing und Nachbarknoten — Billing-Server erhalten keine Anmeldeanfrage eines benachbarten Meshwork-Knotens mehr, die der Knoten bereits selbst abgelehnt hat.

  • Geheimnisse in API-Antworten und ihr Zurückschreiben — die Antwort auf das Hinzufügen oder Ändern eines Eintrags über die API (POST an /config/…) wiederholt Passwörter und andere Geheimnisse nicht mehr, auch nicht für die Rolle Admin: Sie kommen als ********; das Lesen der Einstellungen (GET) hat sich nicht geändert. Ein Geheimnis oder eine Befehlszeile, die beim Schreiben als ******** übergeben wird, behält den gespeicherten Wert, ebenso eine Adresse, die mit der Spur <hidden> verborgen ist: Die erhaltene Antwort lässt sich zurücksenden, ohne Passwörter zu verlieren. ******** selbst lässt sich nicht mehr als Passwort setzen (Steuerung über die HTTP API).

  • Adressen in Antworten für die Rollen Viewer und Restricted admin — im Ereignisstrom /data/events (Adresse des aktiven Eingangs eines Streams und Fehlertexte), in den Ereignistexten von /data/dbstat und im Grund reason aus /data/cert/acme/status sind Logins, Passwörter und geheime Adressparameter ausgeblendet, wie im XML von /data. Für die Rolle Admin ändert sich nichts.

  • Eine abgelehnte Änderung der Einstellungen ändert nichts — lehnt der Knoten eine Änderung eines Streams, Eingangs, Ausgangs oder der Servereinstellungen ab (zum Beispiel einen unzulässigen Knotennamen), bleibt das Objekt so, wie es war. Früher blieben die vor der Ablehnung angewendeten Schlüssel bis zum Neustart in Kraft (Wie Fehler eintreffen).

  • Statistik aus der Datenbank ohne fehlende Tabellen — die Anfrage /data/dbstat mit dem Parameter missing=skip überspringt nicht vorhandene Tabellen, statt die ganze Anfrage abzulehnen.

  • Einstellungsdateien für andere Benutzer nicht mehr lesbar — pss.json und seine Sicherungskopien kann nur der Dienstbenutzer lesen. Der Metrik-Exporter pss-metrics verbindet sich, wenn er unter einem anderen Benutzer läuft, mit Port 43971; nutzt der Webserver einen anderen Port, setzen Sie PSS_URL, auch in der Datei /etc/pss-metrics.conf. Behoben: Der Exporter verband sich mit Port 8808, wenn in pss.json kein Webserver-Port gesetzt war, und berücksichtigte PSS_URL aus dieser Datei nicht (Dateien und Dienste, Konfiguration).

  • Konten nach IP-Adresse und IPv6-Clients — ein Client, der sich über IPv6 verbindet, verursacht bei der Prüfung der Konten nach IP-Adresse keinen Fehler mehr: Ein solcher Client stimmt einfach mit keiner IPv4-Adresse überein (Benutzer / Logins).

  • Erlaubte Streams eines lokalen Logins — ein Login, für das beim Start des Knotens keiner der Streams aus der Liste „Erlaubte Streams“ mehr vorhanden ist, erhält keinen einzigen Stream. Bisher konnte ein solches Login alle Streams ansehen (Benutzer / Logins).

  • Aktivieren und Deaktivieren des EPG-Servers — „EPG-Server aktivieren“ steuert jetzt beide Ports, HTTP und HTTPS, und wirkt sofort, ohne Neustart: Ein deaktivierter Server öffnet keinen einzigen Port. Bisher belegte ein deaktivierter Server beim Start des Dienstes trotzdem seine Ports (Verbindungen blieben hängen), das Deaktivieren im laufenden Betrieb startete den HTTP-Port neu, und der HTTPS-Port beachtete das Flag nicht (XMLTV-Auslieferung).

  • Vollständiger EPG-Export mit Zuordnungsdaten — der neue Pfad /xmltv-src des EPG-Servers (sowie /xmltv-src.gz) liefert die Kanäle aller oder ausgewählter Quellen mit den Daten für die Zuordnung der ausgestrahlten Kanäle: Nummer und Name der Quelle, Kanalbezeichner im Feed; man kann nur den Kanalkatalog exportieren oder vergangene Tage hinzufügen. Zugriff — für ein Benutzerkonto des EPG-Servers mit dem Kennzeichen „Alle Kanäle in /xmltv-src“ (all-channels) oder vom Knoten selbst (Vollständiger Export mit Zuordnungsdaten, EPG-Einstellungen).

  • Altersfreigabe im Sendeplan — das Tagesprogramm eines Kanals im JSON-Format für OTT-Middleware liefert die Altersfreigabe der Sendung (Alter und Bewertungssystem, zum Beispiel 16+), entnommen aus dem XMLTV-Feed oder aus der Altersfreigabe (Parental Rating) von DVB EIT; im Programmplan des Kanals in der Weboberfläche wird sie als Abzeichen angezeigt (Tagesprogramm im JSON-Format, EPG-Datenbank).

  • Untertitel der Sendung als eigenes Feld — der Untertitel aus dem XMLTV-Feed (<sub-title>, zum Beispiel der Folgentitel) in der Sprache des Titels oder ohne Sprachangabe wird im Tagesprogramm eines Kanals im JSON-Format als eigenes Feld sub ausgegeben und im vollständigen Export /xmltv-src als Element <sub-title>; der Sendungstitel kommt dort ohne Untertitel. Die normale Auslieferung /xmltv ist unverändert. Die Untertitel erscheinen nach der nächsten Aktualisierung jeder Quelle (Tagesprogramm im JSON-Format).

  • EPG-Abruf der Reihe nach — große Feeds werden einzeln abgerufen und verarbeitet, die übrigen warten in der Warteschlange, und beim Start des Dienstes sind die Abrufe zeitlich verteilt: Die Speicherspitze beim Neustart mit mehreren großen Feeds entspricht der eines einzigen Feeds. Ein fehlgeschlagener Abruf wird nach 2, 5 und 15 Minuten wiederholt, danach alle 30 Minuten, statt nach dem vollen Aktualisierungsintervall. In der Weboberfläche ist eine eingereihte Quelle markiert, und die Registerkarte „Status der Quellen“ zeigt die Felder „Nächster Versuch“ und „Fehlgeschlagene Abrufe in Folge“ (Abruf-Warteschlange und Wiederholungen, EPG-Datenbank).

  • Abruf-Timeout einer EPG-Quelle — der neue Parameter „Abruf-Timeout, s“ der Quelle (fetch-timeout) für langsame Quellen, die die Datei erst auf Anfrage erstellen; standardmäßig wie bisher 30 Sekunden (Konfiguration der Quellen).

  • EPG-Quellen — bei einer Änderung muss „URL / Pfad der Quelle“ eine http- oder https-Adresse oder ein absoluter Pfad zu einer Datei sein, sonst wird die Änderung abgelehnt. Die Cookies einer Quelle werden jetzt tatsächlich übertragen — im Standard-Header Cookie und nur an den konfigurierten Host; bisher hieß der Header Cookies, und Server berücksichtigten ihn nicht. Nach einer Änderung einer aktivierten Quelle (zum Beispiel ihrer Adresse) werden die Daten sofort geladen und nicht erst nach Ablauf des Aktualisierungsintervalls (Konfiguration der Quellen).

  • Löschen eines EPG-Kanalsatzes — der Inhalt eines Satzes wird zusammen mit dem Satz gelöscht, und nur dann, wenn das Löschen gelungen ist. Bisher blieb der Inhalt eines Satzes ohne Benutzerkonten in der Datenbank, und ein abgelehntes Löschen eines einem Benutzerkonto zugewiesenen Satzes konnte dessen Inhalt löschen.

  • EPG: Sendungen über Mitternacht — eine Sendung, die über Mitternacht (UTC) läuft, wird in beiden Tagen des Programms angezeigt, und ihre Markierung in der OTT-Playlist wird auch nach Mitternacht gefunden. Bisher verschwand eine solche Sendung aus beiden Tagen.

  • Behoben: Im Export /xmltv konnte sich eine Sendung wiederholen, wenn zwei Quellen einen Kanal mit demselben Bezeichner liefern; der Sendeplan aus dem EIT von Streams zeigt eine geänderte Sendung sofort an, nicht mehr den alten Text oder die alte Freigabe.

  • Behoben: „Automatische Bereinigung verwaister Kanäle“ konnte die Kanäle einer EPG-Quelle löschen, deren Feed sich nicht geändert hatte; Programmänderungen in externen Quellen werden jetzt zuverlässiger erkannt, und in der Weboberfläche vorgenommene Änderungen an Kanalnamen bleiben erhalten (EPG-Datenbank).

  • EIT — der Dienst stürzt beim Erzeugen der EIT aus XMLTV nicht mehr ab, wenn ein Ereignis zwei oder mehr Altersfreigaben oder eine lange Beschreibung auf Polnisch, Tschechisch, Ungarisch, Kroatisch oder Bosnisch hat: Ein zu langer Text wird auf mehrere Deskriptoren aufgeteilt. Eine lange Beschreibung in Kyrillisch und anderen nichtlateinischen Schriften wird nicht mehr in Ein-Byte-Fragmente zerlegt, die Deskriptoren sind korrekt nummeriert, und ein Ereignis mit langer Beschreibung behält seine Altersfreigabe (EIT-Generator).

  • NIT — der Knoten verfolgt die Version der NIT auch nach einem Reset (bisher konnte die Liste der logischen Kanalnummern leer bleiben) und wendet nur die NIT des eigenen Netzes (actual) an.

  • Automatischer Diensttyp — bei Service type 0 gilt ein H.264-Programm ab Level 3.1 als HD (Typ 0x19). Bisher lag die Schwelle bei Level 3.0, und SD 576i/480i dieses Levels wurde als HD gekennzeichnet; jetzt als SD (0x16) (Parameter der Programme).

  • Multicast-Empfang auf der Loopback-Schnittstelle — ein UDP- oder RTP-Eingang mit der Schnittstelle lo oder 127.0.0.1 tritt der Multicast-Gruppe nur auf der Loopback-Schnittstelle bei und empfängt die Gruppe, die auf demselben Knoten gesendet wird. Früher trat der Eingang der Gruppe auf der externen Schnittstelle bei und empfing nichts. Um eine Gruppe aus dem Netz zu empfangen, geben Sie eine Netzwerkschnittstelle an oder lassen Sie das Feld leer (Eingang).

  • Erneuter Beitritt zur Multicast-Gruppe — bei UDP-, RTP- und Pro-MPEG-Eingängen ist die Wiederholungsperiode auf 3600 Sekunden begrenzt: Einen größeren Wert nimmt der Knoten nicht an und senkt ihn beim Start auf 3600. Früher ließ ein Wert über 4294 Sekunden den Eingang den Beitritt fortlaufend wiederholen. Ein fehlgeschlagener Versuch wird jetzt nach der Periode wiederholt, statt die Wiederholungen bis zum erneuten Verbinden des Eingangs zu beenden; bei einem Pro-MPEG-Eingang werden auch die FEC-Streams erneut abonniert (Eingang).

  • Adressprüfung für UDP- und RTP-Eingänge — bei einer Änderung wird eine Adresse, die keine IPv4-Adresse ist (zum Beispiel 999.999.1.1), mit der Meldung Incorrect IPv4 address abgelehnt. Bereits gespeicherte Einstellungen werden beim Start nicht erneut geprüft (Eingang).

  • RIST-Multicast-Eingang — tritt der Gruppe auf der Schnittstelle aus der Spalte Interface bei; bisher wurde immer die Standardroute verwendet. Beim RIST-Multicast-Ausgang wirkt die Schnittstelle weiterhin nicht: Der Datenverkehr geht über die Systemroute zur Gruppe (Die Peer-Liste).

  • RIST ohne Abstürze — ein Sender für RIST, dessen Datenblöcke kein Vielfaches von 188 Byte groß sind, hält den Dienst nicht mehr an: Solche Blöcke werden verworfen, und ein Protokolleintrag erscheint höchstens einmal pro Minute. Auch das Ersetzen aller Eingänge oder Ausgänge eines Streams in einer einzigen Änderung bei laufendem RIST-Eingang oder -Ausgang führt nicht mehr zum Absturz des Dienstes.

  • RTSP-Eingang — bei einer Adressänderung, einer Pause, dem Wechsel auf einen Reserveeingang oder einem erneuten Verbindungsaufbau schließt der Eingang die vorherige Sitzung jetzt tatsächlich. Bisher konnte er den Stream weiterhin von der alten Quelle empfangen.

  • DVB: keine periodischen Stream-Abbrüche — ein unvollständiges Lesen von Daten vom DVB-Gerät führt nicht mehr zum Neustart des Eingangs und zur erneuten Abstimmung des Tuners, durch die ein Stream von DVB-T/S periodisch unterbrochen wurde (DVB-Empfänger).

  • Langsamer Empfänger von file-, pipe- und std-Ausgängen — bleibt der Empfänger längere Zeit hinter dem Stream zurück, geht der Ausgang in den Fehler Output queue full über und startet neu, wie Ausgänge anderer Typen; die übertragenen Daten bleiben in der richtigen Reihenfolge. Bisher gingen TS-Pakete in dieser Situation stillschweigend verloren und wurden vertauscht (Externe Anwendungen (std)).

  • std-Ausgang mit umfangreicher stderr-Ausgabe — eine Anwendung, die viel nach stderr schreibt, bleibt nicht mehr nach 64 KB Ausgabe stehen und startet nicht mehr endlos neu. Bei einem Fehler erscheint das Ende ihrer stderr-Ausgabe im Fehlertext (Externe Anwendungen (std)).

  • Beschädigte Tabellen im Eingangsstream — beschädigte Sektionen von PAT, PMT, CAT, NIT, EIT und TOT und die Deskriptoren darin verwirft der Knoten; zum Absturz bringen können sie den Dienst nicht mehr.

  • ESCR-Marke in PES — Streams mit einer ESCR-Marke in den PES-Headern werden korrekt ausgewertet; früher brach ihre Auswertung mit einem Fehler ab.

  • Hinzufügen eines Streams mit Transcoder — das Hinzufügen eines Streams, dessen transcoder-Eingang mit einem bereits laufenden Decoder verbunden ist, führt nicht mehr zum Absturz des Dienstes (Verschaltung).

  • HTTP/3: gestreamte Antworten kommen unverfälscht an — über HTTP/3 werden MPEG-TS over HTTP (/http/) und die Teile von LL-DASH im Live-Betrieb vollständig übertragen, genau wie über HTTP/1.1. Bisher kam der Body einer solchen Antwort beschädigt an: Er begann nicht an einer TS-Paketgrenze, Fragmente fehlten oder wiederholten sich, und die Player verloren die Synchronisation. HLS- und DASH-Segmente sowie andere Dateien waren nicht betroffen (HTTP/3 (QUIC)).

  • OTT — die Auslieferung von DASH und LL-HLS wird nach einem Wechsel der Video-PID im Stream fortgesetzt (bisher erst nach einem Neustart von OTT); die Auslieferung von MPEG-TS over HTTP setzt den Eingang bei einer kurzzeitigen Verlangsamung der DVR-Festplatte nicht mehr zurück.

  • Das Löschen eines Eingangs oder Ausgangs hält die DVR-Aufzeichnung nicht an — nach dem Löschen eines Eingangs oder Ausgangs des Streams wird das DVR-Archiv weiter aufgezeichnet. Früher stoppte die Aufzeichnung bis zur nächsten Änderung der OTT-Einstellungen des Streams.

  • DVR: beschädigter Indexeintrag — ist ein einzelner Eintrag des Archivindex beschädigt (zum Beispiel nach einem Stromausfall), überspringt der Knoten ihn und lädt das übrige Archiv; verloren geht nur dieses Fragment. Bisher verschwand alles danach Aufgezeichnete bei jedem Neustart aus dem Archiv, und die Dateien wurden anschließend gelöscht (DVR-Speicher).

  • DVR: Bereinigung von MP4-Archiven — bei Überschreitung der Grenze der Festplattenbelegung werden auch die ältesten Segmente der MP4-Archive (DASH und LL-HLS) entfernt. Bisher wurde nur das TS-Archiv bereinigt, und eine Festplatte mit reinen MP4-Archiven blieb übervoll.

  • DVR: Untertitel — das Archiv der WebVTT-Untertitel bleibt bei einem Neustart erhalten; bisher ging es verloren (WebVTT-Untertitel).

  • DVR: Notfall-Freispeicher — das Feld „Notfall-Freispeicher, GiB“ der DVR-Speicher hat sich nie auf den Betrieb ausgewirkt und tut es auch jetzt nicht: Der Wert wird gespeichert, ein Anhalten der Aufzeichnung wegen des freien Speicherplatzes gibt es aber nicht. Das Feld ist jetzt als reserviert beschrieben; innerhalb der Grenze hält die Festplatte die Bereinigung nach Speicherplatz, die kein Archiv anrührt, das jünger als das geschützte Minimum ist (DVR-Speicher).

  • Weitere Verbesserungen und Fehlerbehebungen.

Version 2.0.2.408

19.10.2026

  • Eine defekte DVR-Festplatte stoppt die Live-Auslieferung nicht — eine volle, schreibgeschützte oder fehlerhafte DVR-Festplatte beendet die Live-Auslieferung eines Streams über HLS und DASH nicht mehr. Bisher stoppte ein Schreibfehler des Archivs, ohne Protokolleintrag, sowohl die Live-Auslieferung als auch das Archiv bis zum Neustart, und das Löschen des Archivs half nicht. Jetzt vermerkt das Protokoll Beginn und Ende eines Schreibfehlers, und nach Behebung der Störung wird das Archiv wieder geschrieben, auch nach dem Löschen des Archivs des Streams (Stream-Statistik). Dasselbe gilt für das Untertitelarchiv.

  • Das Ändern von Einstellungen blockiert die API nicht — das Bearbeiten eines Streams (ein Parameter, ein Ausgang, das Löschen des Streams) kann bei einem ausgefallenen oder untätigen Eingang oder unter Last nicht mehr hängen bleiben. Bisher reagierten damit auch alle Konfigurationsanfragen und die Stream-Liste in der Weboberfläche nicht mehr.

  • Speichern der Einstellungen ohne Verluste — eine Änderung, die unmittelbar vor einem regulären Beenden oder Neustart des Dienstes vorgenommen wurde, geht nicht mehr verloren; ein fehlgeschlagenes Schreiben der Einstellungsdatei wird alle 10 Sekunden wiederholt, und das Protokoll nennt die Ursache; eine Änderung, die vor dem automatischen Neustart nach einer Wiederherstellung aus einer Sicherung vorgenommen wurde, überschreibt die wiederhergestellte Konfiguration nicht mehr.

  • Erneutes Verbinden von Ein- und Ausgängen — nach einem erneuten Verbindungsversuch kann ein Eingang oder Ausgang nicht mehr in einem Startversuch hängen bleiben, ohne etwas geöffnet zu haben, bis zum Neustart des Dienstes oder einer Änderung der Einstellungen. Am häufigsten betraf das einen SRT-Eingang im Modus listener; betroffen waren auch PS1, RTMP/RTMPS, RTSP, der HLS-Eingang, TCP und der Transcoder.

  • SRT: Eine falsche Passphrase sperrt den Eingang nicht — rufende Seiten, die sich immer wieder mit einer falschen oder ganz ohne Passphrase mit einem SRT-Port im Modus listener verbinden, belegen nicht mehr alle Verbindungsplätze: Ein Sender mit der richtigen Passphrase verbindet sich sofort.

  • Paket-Repository über HTTPS und signiert — das Repository arbeitet über HTTPS, Pakete und Metadaten sind mit dem Repository-Schlüssel signiert. Die neuen Befehle zum Einbinden stehen unter Installation auf Systemen der RHEL-Familie und Installation auf Systemen der Debian-Familie; ein früher eingebundenes Repository funktioniert weiter.

  • Anlegen eines Streams mit einem ungültigen Wert — eine Anfrage zum Anlegen eines Streams über die HTTP API mit einem ungültigen Parameterwert wird als Ganzes abgelehnt, und es wird kein Stream angelegt. Bisher wurde der Wert verworfen und der Stream angelegt (Wie Fehler eintreffen).

  • Die Reihenfolge des Schlüssels ``mpts`` spielt keine Rolle — mpts wird vor den übrigen Schlüsseln eines Stream-Eintrags angewandt, wo immer er steht. OTT-Parameter und andere Einstellungen eines Streams mit einem Programm, die beim Anlegen eines Streams über die HTTP API ohne mpts übergeben oder in der Einstellungsdatei oberhalb davon eingetragen wurden, gehen nicht mehr verloren (Die Reihenfolge der Schlüssel innerhalb eines Objekts ist bedeutsam).

  • SIGHUP ist ein reguläres Beenden — das Signal SIGHUP beendet den Dienst genauso wie SIGTERM: Die Streams werden gestoppt, die letzte Änderung der Einstellungen wird gespeichert. Bisher wurde der Prozess sofort beendet.

  • Pro-MPEG-Eingang im Meshwork-Katalog — ein Pro-MPEG-Eingang, der eine Multicast-Gruppe empfängt, wird im gemeinsamen Ressourcenkatalog der Domäne genauso angekündigt wie UDP- und RTP-Eingänge (Gemeinsamer Ressourcenkatalog).

  • Weitere Verbesserungen und Fehlerbehebungen.

Version 2.0.2.399

01.10.2026

  • T-STD-Puffer nur noch als Metrik — das Modell des Videopuffers lieferte Fehlalarme bei einwandfreien Streams, daher bleibt sein Messwert zur Diagnose in der Statistik, löst aber keinen Alarm (Code 11) mehr aus und geht nicht in das zusammengefasste TR-101-290-Urteil (Code 49) ein (Katalog der Alarmcodes).

  • OTT ohne CBR-Füllung — die NULL-Pakete, mit denen die konstante Bitrate aufgefüllt wird, werden an keinen OTT-Client ausgeliefert, auch nicht bei der Auslieferung über HTTP ohne Segmentierer. Die konstante Bitrate bleibt nur an den Transportausgängen erhalten — UDP, SRT, PS1, RIST.

  • LL-HLS-Parts an Schlüsselbildern — jedes IDR eröffnet einen neuen Part mit dem Merkmal INDEPENDENT, sodass ein Player, der sich an der Live-Kante verbindet, innerhalb einer GOP einen Einstiegspunkt findet.

  • Viele HLS-Eingänge auf einem Knoten — HLS-Eingänge laden Segmente über einen gemeinsamen Pool: Ein geöffneter Eingang hält keine eigenen Worker-Threads mehr, und bei ausgelastetem Pool wird das Laden eines Segments aufgeschoben, statt den Eingang neu zu starten.

  • Weitere Verbesserungen und Fehlerbehebungen.

Version 2.0.2.362

06.09.2026

  • Menü des CI-Moduls — das eigene Menü des Moduls wird ausgelesen: Kartenstatus, Abonnements, Seriennummer, PIN-Eingabe und Servicepunkte sind direkt vom Hardware-Bildschirm aus verfügbar — dasselbe, was das Modul auf dem Fernsehbildschirm zeigen würde. Ebenda kam der Modulausweis hinzu — Hersteller, Produktcode und EN-50221-Anwendungstyp —, und den Modulnamen dekodiert der Knoten, sodass kyrillische Namen nicht mehr verstümmelt ankommen (Modulmenü).

  • Entschlüsselung durch ein eigenständiges CI-Modul — ein Modul in einem eigenständigen Kartenleser bedient jeden Eingang eines Streams und nicht nur den Empfang von einer DVB-Karte: Der gesamte Transport des Eingangs läuft durch es hindurch, während die Programmliste lediglich angibt, welche davon zu entschlüsseln sind. Der Slot wird am Eingang selbst zugewiesen, und ebendort ist zu sehen, welcher Eingang ihn belegt (CI/CAM am Eingang eines Streams).

  • Mehrere CI-Slots an einem Eingang — ein Multiplex wird nacheinander durch mehrere Module geführt, mit einem eigenen Programmsatz je Slot. Die Taktfrequenz des CI-Busses wird anhand der tatsächlichen Bitrate des Eingangs gewählt, und ein belegt gebliebener Slot wird auf Anforderung vom Hardware-Bildschirm aus freigegeben.

  • Diensttabellen beim Demultiplexen — die Netz- und Zeittabellen sowie die übrigen Dienst-PIDs des Ursprungsmultiplex gehorchen nun denselben Schlüsseln mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary und mpegts-filter-cat wie auf den übrigen Pfaden, statt bedingungslos verworfen zu werden. Der Standardwert hat sich damit geändert: Ein aus einem Multiplex herausgelöster Stream führt die Netz- und Zeittabellen, die er zuvor nicht führte — ein Empfänger hinter einem solchen Stream, und ein CI-Modul in erster Linie, erwartet sie zu sehen. Das frühere Verhalten stellt mpegts-filter-nit wieder her.

  • Eine PCR-Diskontinuität leert den Jitterpuffer nicht mehr — ein Eingang, der einen PCR-Sprung nach vorn aufgefangen hat, versetzt den Synchronisationspunkt im laufenden Betrieb, ohne die Warteschlange abzulassen; die Diskontinuität kostet daher ein einziges Stocken statt eines erneuten Auffüllens des Puffers. Das Fenster, jenseits dessen ein Sprung als Diskontinuität gilt, wird automatisch gewählt (Synchronisation).

  • Schneller Start eines HLS-Eingangs — eine Live-Playlist wird am Ende aufgegriffen: In die Warteschlange gelangen nur die letzten Segmente, die für den eingestellten Jitter nötig sind, und nicht das ganze Fenster; der Eingang geht daher mit einer Verzögerung von einigen Segmenten statt eines vollständigen Playlist-Fensters auf Sendung. Eine abgeschlossene Playlist (VOD) wird nach wie vor von Anfang an wiedergegeben.

  • Unterdrückung von Alert-Flattern — ein Alert, der immer wieder ausgelöst und behoben wird, wird zu einem einzigen Vorfall zusammengefasst: Der Knoten hält ihn über die Ruhephase hinweg und schließt ihn erst, wenn das Flattern tatsächlich aufgehört hat. Ein Sturm von Wiederholungen verbreitet sich weder über das Protokoll noch über die externen Kanäle. Eine einmal erkannte flatternde Quelle bleibt auch nach der Ruhephase als solche erkannt: Ihre nächste Serie wird schon ab der ersten Wiederholung gehalten.

  • Bearbeiten eines EPG-Kanals — für einen Kanal werden die XMLTV-Kennung getrennt vom Anzeigenamen sowie Bezeichnungen je Sprache festgelegt, und ein nicht mehr benötigter Kanal wird vollständig gelöscht: Mit ihm verschwinden seine Bezeichnungen, seine Ereignisse und seine Zugehörigkeit zu Sätzen.

  • Weitere Verbesserungen und Fehlerbehebungen.

Version 2.0.2.335

27.08.2026

  • Meshwork (Multi-Domain) — mehrere Server werden zu benannten Domains zusammengeschlossen, und die Domain dient als Isolationsgrenze: die Mitgliedschaft der Knoten, der Ressourcenkatalog und die Alerts verbreiten sich nur innerhalb der eigenen Domain, zwischen den Domains wird nichts übertragen. Ein Knoten kann gleichzeitig mehreren Domains angehören, ohne deren Daten zu vermischen. Ausführlich — Meshwork.

  • Automatische Knotenerkennung — es genügt, die Domain und einen einzigen Einstiegspunkt anzugeben: die Knoten tauschen Nachbarlisten aus und bauen selbstständig ein vollvermaschtes Netz direkter Verbindungen auf. Der gemeinsame Domain-Schlüssel wird automatisch erzeugt und ausschließlich über einen geschützten Kanal übertragen — TLS oder ein vertrauenswürdiges Segment des lokalen Netzes.

  • Verteilte Ressourcenbibliothek — die Ausgänge UDP, RTP, Pro-MPEG und RIST, die Multicast-Eingänge UDP, RTP und RIST sowie die PS1- und SRT-Verbindungen werden im gemeinsamen Katalog der Domain (/data/library) veröffentlicht: eine einheitliche Liste der Multicast-Gruppen, Ports, VLANs, SSM-Quellen und Punkt-zu-Punkt-Verbindungen mit Angabe von Knoten und Stream. Am Katalog ist ersichtlich, welche Adressen und Ports bereits belegt sind, und ein neuer Eingang wird direkt daraus angebunden — durch Auswahl eines Streams, der auf einem anderen Knoten der Domain bereits ausgeliefert wird, ohne die Adresse manuell einzugeben.

  • Übersicht der Domain-Knoten — zu jedem Knoten werden Status, Zeitpunkt des letzten Kontakts, Rolle, Region, Build-Version, Betriebszeit seit dem Start, CPU-Auslastung, Datenverkehr je physischer Schnittstelle und die Anzahl der Streams auf Sendung angezeigt, zu jeder Verbindung zwischen Knoten über PS1 oder SRT — Bitrate, RTT, Anteil der Wiederholungen und Verluste sowie ein Urteil über den Zustand. Ein ausgefallener Knoten verschwindet nicht aus der Liste: er bleibt dort sieben Tage lang als nicht erreichbar samt seinem Alert stehen, ein außer Betrieb genommener wird mit einem eigenen Befehl aus der Übersicht entfernt.

  • Betrieb hinter NAT — ein Knoten hinter NAT nimmt vollwertig und ohne Weiterleitung eingehender Ports an der Domain teil: er baut die Verbindung selbst auf, sein öffentlicher Zugangspunkt wird aus der tatsächlich sichtbaren Adresse und dem angekündigten Port abgeleitet, und seinen Zustand geben die Nachbarn einen Hop weiter — der Knoten ist auch für diejenigen sichtbar, die ihn nicht direkt erreichen können.

  • Knotenname aus dem Zertifikat — ein Knoten ohne konfigurierten Hostnamen kündigt den Peers den Namen an, den sein eigenes Zertifikat abdeckt, und erst nachdem dieser Name wieder auf ihn aufgelöst wird; das Prüfergebnis ist in den Serverdaten als cert-host und cert-host-refused sichtbar.

  • Automatische Anmeldung der Verbindungen innerhalb der Domain — für PS1- und SRT-Verbindungen zwischen Knoten derselben Domain müssen nicht für jede Verbindung Benutzername und Passwort angelegt werden: auf der rufenden Seite (PS1-Eingang, SRT-Eingang, SRT-Ausgang im caller-Modus) genügt es, die Einstellung „Meshwork peer auth“ zu aktivieren, und die Autorisierung erfolgt über das gemeinsame Domain-Geheimnis. Der bestätigte Partnerknoten und dessen Stream sind in der Ressourcenbibliothek und in der Sitzungsliste sichtbar.

  • Low-Latency HLS und MPEG-DASH über CMAF — der neue Auslieferungsmodus „OTT / LL-HLS / DASH“: der integrierte Multiplexer erzeugt fragmentiertes MP4 (CMAF), über das MPEG-DASH unter /dash und Low-Latency HLS unter /llhls ausgeliefert werden; adaptive Bundles werden auch für diese Formate zusammengestellt. Ausführlich — Auslieferungsmodi.

  • Geringe Latenz bei LL-HLS — die Medien-Wiedergabeliste wird in Teile zerlegt, das blockierende Neuladen der Wiedergabeliste und der Preload-Hinweis werden eingesetzt, sodass der Player mit der Wiedergabe beginnt, ohne die Fertigstellung eines vollständigen Segments abzuwarten. Die CMAF-Segmente führen Producer Reference Time mit, das DASH-Manifest kündigt UTCTiming und die Ziellatenz an, und die Einstellung „LL-Part-Zieldauer (ms)“ wird im laufenden Betrieb wirksam, ohne den Stream neu zu starten.

  • HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS und MPEG-TS over HTTP werden über QUIC auf einem eigenen UDP-Port ausgeliefert, mit optionalem 0-RTT; den Wechsel zu QUIC fordert der Client mit dem Parameter ?h3 an. QUIC funktioniert nur über TLS: bei ausgeschaltetem TLS wird der Listener nicht gestartet und dem Client nicht angeboten, und der tatsächliche Zustand des Listeners ist in den Daten des HTTP-Servers sichtbar, nicht nur in der Einstellung. Die administrativen Routen bleiben ausschließlich auf TCP.

  • Segmentausrichtung an IDR — der Segmentierer unterscheidet ein IDR- von einem gewöhnlichen I-Frame: bei Quellen mit closed-GOP beginnt jedes Segment mit einem vollwertigen Einstiegspunkt, sodass der Player den Stream an jedem beliebigen Segment öffnet; bei Quellen mit open-GOP dient das nächstgelegene I-Frame als Grenze.

  • Inhaltsschutz (DRM) — die OTT-Auslieferung eines Streams kann verschlüsselt werden: HLS AES-128 mit einem Schlüssel vom Server selbst oder von einem externen Key-Server und mit optionaler Rotation nach Zeitfenstern, oder MPEG Common Encryption (ISO/IEC 23001-7) nach den Schemata cenc und cbcs für CMAF und DASH. Die Verschlüsselung erfolgt einmalig, im Moment der Segmentbildung, daher wird das DVR-Archiv verschlüsselt gespeichert und übersteht beliebig viele Schlüsselrotationen. Ausführlich — Inhaltsschutz (DRM).

  • Jede MPEG-TS-over-HTTP-Verbindung ist eine eigene Sitzung — die Clientliste des Streams enthält nun eine Zeile je Verbindung mit eigener sess-id, die Einzelheiten stehen unter /data/stream/http-clients/<sess-id>, eine einzelne Verbindung wird mit POST /data/kick?sess-id=<id> geschlossen, und die Grenze max-conn wird auch bei Werten über eins eingehalten.

  • DVR (Netzwerkarchiv) — jeder OTT-Kanal wird parallel zur Auslieferung auf die Festplatte geschrieben, mit derselben Segmentierung und ohne separaten Rekorder; im Modus geringer Latenz wird das Archiv in zwei Linien geführt, MPEG-TS und CMAF, sodass die Aufzeichnung im selben Container wie die Live-Ausstrahlung verfügbar ist. Ausführlich — DVR.

  • Archivwiedergabe (VOD) — das Archiv wird über dieselben HLS-, DASH- und LL-HLS-URL ausgeliefert wie die Live-Ausstrahlung: t=<Zeit> schaltet den VOD-Modus ein und legt den Beginn des Fensters fest, d=<Sekunden> dessen Dauer. Die HLS-Wiedergabeliste ist dabei geschlossen, das DASH-Manifest statisch, Aufzeichnungslücken werden als separate Perioden ausgewiesen; adaptive Bundles geben das Archiv mit denselben Parametern wieder.

  • Catch-up über EPG — statt t und d genügt es, epg=<Zeit> zu übergeben: der Server findet auf dem verknüpften EPG-Kanal selbst die zu diesem Zeitpunkt laufende Sendung und übernimmt deren Beginn und Dauer als Grenzen des Wiedergabefensters.

  • Untertitel im Archiv — WebVTT-Spuren werden zusammen mit den Segmenten auf die Festplatte geschrieben und in VOD über dieselben URL wiedergegeben; Fenster ohne Untertitelzeilen belegen keinen Speicherplatz auf der Festplatte.

  • DVR-Speicher — es kann mehrere Speicher geben, jeder mit einer eigenen Füllgrenze und einer eigenen Bereinigungsreihenfolge. Die Archivtiefe („Aufbewahrung (Stunden)“, bis zu 90 Tage) und das geschützte Minimum werden für jeden Stream separat festgelegt, und die Bereinigung nach freiem Speicherplatz rührt weder das geschützte Minimum noch die Fenster offener VOD-Sitzungen an.

  • DVR-Monitor — ein separater Bildschirm zeigt Zustand und Füllung der Speicher, Umfang und Tiefe des Archivs je Stream sowie die Lese- und Schreiblatenzen, und das Abdeckungshistogramm (/data/dvrstat) markiert nicht nur die Lücken im Archiv, sondern auch deren Ursache — Abriss des Eingangs, PMT-Wechsel, Verwürfelung, Auslösen der Bereinigung. Von hier aus werden auch das Archiv eines einzelnen Streams und die Verzeichnisse gelöschter Streams entfernt.

  • Ein Plattenfehler im Archiv hält den Knoten nicht mehr an — ein Fehler bei der Bedienung des DVR-Archivs bleibt auf den Speicher und den Schritt beschränkt, in dem er auftrat: die übrigen Streams und die übrigen Aufzeichnungslinien laufen weiter, und das betroffene Archiv wird als wiederaufbaubedürftig markiert.

  • Alerter — der neue Benachrichtigungsdienst: jede Störung wird zu einem Vorfall, der automatisch ausgelöst, aktualisiert und behoben wird, und der deduplizierte aktive Satz zeigt nur das, was gerade geschieht. Der Schweregrad wird über eine einheitliche Skala festgelegt — von rein informativ bis hin zu „erfordert einen Administrator-Eingriff“; ein solcher Vorfall wird durch die Bestätigung des Bedieners behoben. Ausführlich — Benachrichtigungen (Alerter).

  • Katalog der Alert-Codes — mehr als fünfzig Vorfalltypen in einer einzigen Liste: Streams samt ihren Eingängen und Ausgängen, Verstöße gegen TR 101 290, Ressourcen des Knotens, DVR-Speicher und Zustand der Aufnahme, DVB- und CI/CAM-Empfang, Transcoder, OTT, Zertifikate und Knoten der Domain. Die Auslöseschwellen werden im Benachrichtigungsbereich konfiguriert.

  • Externe Zustellung von Benachrichtigungen — die Alerts verlassen die Web-Konsole: per E-Mail über SMTP (STARTTLS, implicit TLS, AUTH), per Nachricht an Telegram und durch den Start eines beliebigen Befehls, dem der Vorfall über Umgebungsvariablen und als vollständiges JSON auf der Standardeingabe übergeben wird. Jeder Kanal hat einen eigenen Schalter und einen eigenen Schweregrad-Schwellenwert.

  • Alerts der gesamten Domain — der Diensthabende sieht die Alerts jedes Knotens von jedem anderen aus: der aktive Satz wird zusammen mit dem Keep-alive repliziert und wird sofort behoben, sobald er an der Quelle verschwunden ist, und in jeder Zeile ist der Ursprungsknoten angegeben. Hardware- und System-Alerts bleiben standardmäßig lokal und werden über eine separate Einstellung auf die Domänenebene angehoben.

  • Protokoll in der Datenbank — die Meldungen des Dienstes werden in SQLite geschrieben: typisierte Einträge mit Quelle und Schweregrad, Zusammenfassung aufeinanderfolgender Wiederholungen zu einer Zeile mit Zähler, Begrenzung der Aufbewahrung nach Dauer und nach Umfang. Im Unterschied zum aktiven Alert-Satz übersteht das Protokoll einen Neustart.

  • Zentraler Schalter für Benachrichtigungen — ist enable in den Einstellungen des Alerters ausgeschaltet, löst der Knoten keine eigenen Alerts aus und versendet nach außen überhaupt nichts, auch nicht die von Peers der Domain erhaltenen Alerts; in der Liste und im Ereignisstrom bleiben nur die über die Domain verteilten Alerts der Peers.

  • Die Schwere eines E/A-Alerts richtet sich nach den Folgen — ein Eingang, der ausfällt, während er den Stream nicht trägt, erhält die Stufe Error, ein tragender Eingang, jeder Ausgang und ein Ausfall ohne Sendung die Stufe Critical; die Bewertung wird neu berechnet, solange der Alert offen ist, und folgt der Umschaltung auf die Reserve.

  • Farbe in externen Benachrichtigungen — dem Meldungstext wurde eine Farbmarkierung der Stufe hinzugefügt (rot für Fehler, gelb für Warnungen, grün für die Entwarnung, blau für Informationen), und die E-Mail geht in zwei Varianten zugleich hinaus: als reiner Text und als HTML mit farbigem Balken.

  • Telegram-Benachrichtigungen überstehen einen Sturm — die aufgelaufenen Alerts werden zu der kleinsten Anzahl von Nachrichten zusammengefasst, die das Limit von 4096 Zeichen zulässt, und bei einer Antwort über eine Ratenbegrenzung wartet der Knoten die angegebene Zeit ab und wiederholt den Versand, statt die Benachrichtigung zu verwerfen.

  • Die Benachrichtigungsverzögerung gilt jetzt auch für den Reserveeingang — die Warnung, dass ein Stream auf dem Reserveeingang läuft, wird nur ausgelöst, wenn der Zustand länger als alert-delay angehalten hat; eine Quelle, die sich erholt und wieder ausfällt, erzeugt daher keine Kette von Auslösungen und Entwarnungen mehr. Bei alert-delay gleich null bleibt das Verhalten wie bisher.

  • TR 101 290-Monitor — die fortlaufende Kontrolle der Konformität des Eingangsstreams mit dem Standard: ein einziges Urteil („Gut“, „Schlecht“, „Prüfung läuft…“) und ein strukturierter Bericht nach den Prioritäten 1, 2 und 3, in dem für jeden Indikator der Abschnitt des Standards, der gemessene Wert und der Grenzwert angegeben sind. Ein MPTS-Multiplex wird als Ganzes bewertet — über alle PID, Programme und SI-Tabellen. Der Stream wird automatisch als CBR oder VBR klassifiziert, und die Prüfungen, die nur bei konstanter Bitrate sinnvoll sind, werden auf einer VBR-Quelle nicht bewertet und erzeugen keine Fehlauslösungen. Ausführlich — TR 101 290-Monitor.

  • Drift des Referenzoszillators — das systematische Weglaufen der Taktfrequenz der Quelle wird durch lineare Regression in ppm bei einer Toleranz von ±30 ppm nach ISO/IEC 13818-1 gemessen und als separate Metrik ausgegeben. Ein langsames Weglaufen wird durch sanfte Mikroverschiebungen des Synchronisationspunkts ausgeglichen („Sync-Drift-Kompensation“, standardmäßig aktiviert), sodass es am Ausgang keine Sprünge gibt.

  • T-STD-Puffermodell — die Analyse des Videopuffers des Referenzdecoders nach ISO/IEC 13818-1 mit Zählern für Überläufe und Unterläufe für MPEG-2, H.264 und HEVC; die Zeitrechnung erfolgt nach der PCR-Uhr, und die Entleerungsrate richtet sich nach der tatsächlichen Videobitrate. Wird über die Einstellung „T-STD-Videopuffer analysieren“ aktiviert.

  • Analyse für die Werbeeinblendung — die Auswertung von SCTE-35-Sektionen mit Splice-Ereignissen, Splice-Punkte auf Transportebene mit konfigurierbarer Vorabbenachrichtigung sowie Random-Access-Marken. Die Daten werden bei aktivierter Tiefenanalyse in der Stream-Statistik ausgegeben.

  • Reklamationsassistent — für einen Stream mit anhaltenden Verstößen wird ein fertiger Aufgabentext für einen KI-Chat erzeugt, aus dem dieser ein förmliches Reklamationsschreiben an den Anbieter des Streams verfasst: die Liste der anhaltenden Verstöße, die gemessenen Werte, die Abschnitte des Standards und die Auswirkung auf den Decoder. Der Aufgabentext wird über die Anfrage GET /data/stream/<id>/ai-complaint-prompt ausgeliefert; der Name des Streams und die Adresse der Quelle werden nicht in den Text aufgenommen.

  • CI/CAM (EN 50221) — ein integrierter Common-Interface-Host: Erkennung des Moduls, Auslesen seines Namens und der Liste der unterstützten CA_system_id, Auswahl der zu entschlüsselnden Programme und Übergabe der CA_PMT für jedes von ihnen. Ein mit dem DVB-Empfänger kombiniertes Modul entschlüsselt die ausgewählten Programme des empfangenen Multiplexes inline, mehrere gleichzeitig; der Zustand der Slots und das Urteil zu jedem Programm sind in der Oberfläche sichtbar.

  • Software-Entschlüssler BISS-1 / BISS-E — wird nicht nur auf den Empfang von einer DVB-Karte angewendet, sondern auf jeden Stream-Eingang: der Schlüssel wird für das gesamte SPTS oder je Programm des Multiplexes festgelegt und im laufenden Betrieb geändert, ohne den Eingang neu zu starten. Beim Empfang von einer DVB-Karte wird das Ergebnis zusätzlich anhand des Streams selbst geprüft, sodass ein falscher Schlüssel nicht wie eine erfolgreiche Entschlüsselung aussieht, sondern einen eigenen Alert auslöst.

  • Bereinigung des bedingten Zugriffs beim DVB-Empfang — aus einem von einer DVB-Karte empfangenen Multiplex werden über eine separate Adaptereinstellung die ECM- und EMM-PID entfernt und aus der PMT die CA-Deskriptoren der offenen Programme: weiter im Signalweg läuft ein sauberer FTA-Stream. Bei Verlust des Schlüssels kehrt die Signalisierung des bedingten Zugriffs zurück, damit ein weiter unten in der Kette liegender Empfänger den Zugriff erneut anfordern kann.

  • Transcoder-Telemetrie — zu jedem Encoder werden die Medieninformationen des transcodierten Ausgangs veröffentlicht: Bildformat, Videocodec, Satz der Audiocodecs und aktuelle Bitrate, und zu jedem Prozess — CPU-Auslastung und belegter Speicher.

  • RTMP und RTMPS — ein Kanal wird an einen beliebigen RTMP-Empfänger veröffentlicht, einschließlich YouTube und Facebook: Video in H.264 oder HEVC (HEVC — über Enhanced RTMP) und eine AAC-Spur; für rtmps:// verbindet sich der Knoten als TLS-Client. In der Gegenrichtung holt der Eingang den Stream selbst von einer Quelle rtmp:// oder rtmps:// und remultiplexiert FLV nach MPEG-TS.

  • Nahtlose Quellenumschaltung — beim Wechsel des aktiven Eingangs am Sender verbinden sich die empfangenden PS1-Peers nicht neu: Nummerierung und Zeitstempel bleiben durchgängig, ein Warteschlangenstoß wird durch das Verwerfen der ältesten Pakete abgefangen, und die Lücke wird durch die reguläre Retransmission nachgeholt.

  • Adaptive PS1-Retransmission — der Empfänger misst die tatsächliche RTT zum Sender und passt die Intervalle der Wiederholungsanfragen selbst daran an; die gemessene RTT, das aktuelle Intervall der erneuten Anfrage und das Merkmal einer zu geringen Latenz werden in der Verbindungsstatistik ausgegeben. Die Latenz des Empfangstunnels wird direkt in Millisekunden festgelegt statt wie bisher als Vielfaches der RTT.

  • Die Zustände „Verbindung wird wiederhergestellt“ und „Admin-Aktion“ — ein Eingang oder Ausgang, der seine Quelle verloren hat, wird an Ort und Stelle wieder geöffnet und bleibt für die gesamte Dauer der Versuche im Zustand „Verbindung wird wiederhergestellt“, wobei er eine Warnung je Episode auslöst statt einer Meldung bei jedem Versuch. Eine Ursache, die sich durch Wiederholung nicht beheben lässt — ein belegter Port, eine fehlende Schnittstelle, Daten, die kein MPEG-TS sind, ein SRT-Fehlschlag bei der Verschlüsselung —, versetzt der Knoten in den Zustand „Admin-Aktion“ mit einem haftenden Alert, während eine Änderung der Einstellungen sofort wirksam wird.

  • Datum des letzten Fehlers — neben dem Text des letzten Fehlers eines Ein- oder Ausgangs wird dessen Zeitpunkt veröffentlicht (last-error-ts, dasselbe Feld gibt es auch im Ereignisstrom), sodass eine alte Ursache, die an einem pausierten Eingang hängen geblieben ist, getrennt von der aktuellen Störung sichtbar ist.

  • Diagnose bei unbrauchbarem Inhalt am Eingang — die Meldung über den Verlust der MPEG-TS-Synchronisation nennt die wahrscheinliche Ursache: Pakete wurden gefunden, sind aber um eine bekannte Anzahl Bytes versetzt, oder es gibt überhaupt keine MPEG-TS-Struktur; für PS1- und Pro-MPEG-Eingänge kommt ein Hinweis auf die Passphrase der Verschlüsselung hinzu.

  • Tatsächliche Größe des Empfangspuffers — der Eingang veröffentlicht socket-buffer-actual, die vom Kernel zugeteilte Größe, während socket-buffer-size nur eine Anforderung bleibt und vom Systemlimit gekürzt wird; die Abweichung ist damit sofort sichtbar und äußert sich nicht erst als Verluste bei hoher Bitrate.

  • MPTS-Multiplexer: ursprüngliche Identität — die Programme können ihre ursprünglichen PID behalten, und die Reihenfolge der Programme in PAT, SDT und NIT wird manuell festgelegt, sodass ein Multiplex ohne Änderung der Stream-Identität für die Empfangsgeräte auf Perfect Streamer migriert wird. Programme mit TS-Verwürfelung werden mit ihren ursprünglichen Zeitstempeln übernommen.

  • Automatische PID-Nummerierung für SPTS — enable-autopid verschiebt zusammen mit autopid-base das gesamte Programm in ein vorhersagbares Fenster von 64 Bezeichnern, beginnend mit der PMT und danach Video, Audio und die übrigen Elementarströme in der Reihenfolge der Ausgangstabelle; ein Programm, das nicht in das Fenster passt, behält seine ursprünglichen PIDs vollständig.

  • Die Datagrammgröße lässt sich an allen Ausgängen einstellen — die Einstellung packets gilt nun nicht mehr nur für SRT, sondern auch für die Ausgänge UDP, RTP, Pro-MPEG und RIST, und bei der Ausgabe in eine Datei und in den Standardstrom bestimmt sie die Größe des geschriebenen Blocks. Die Standardwerte entsprechen dem bisherigen Verhalten, eine Konfiguration, in der der Schlüssel nie gesetzt wurde, ändert sich also nicht; einen gespeicherten Wert, der vom Standard abweicht, haben frühere Builds ignoriert, und jetzt wird er schon beim ersten Neustart wirksam — prüfen Sie ihn vor dem Update.

  • Integration mit externem Billing — jede Zuschauersitzung wird in einem externen Billing- oder CRM-System autorisiert, durch periodische Re-Autorisierung gehalten und nach ihrem Ende demselben System gemeldet: ein Lebenszyklus Start / Interim / Stop im RADIUS-Stil, ein Widerruf des Abonnements bricht die Sitzung mitten im Betrachten ab. Erfasst sind OTT, das PS1-Peering und die SRT-Ausgänge, und das Billing-System selbst wird über Vorlagen für die Anfrage und die Auswertung der Antwort angebunden, ohne Anpassung der Software.

  • Integrierter ACME-Client (Let’s Encrypt) — Ausstellung und automatische Verlängerung der Zertifikate für den Webserver, den HTTP/OTT-Server und den EPG-Server: ein Zertifikat wird für jeden konfigurierten Hostnamen bestellt, die Verlängerung wird täglich geprüft, bei einem Fehlschlag wird ein Alert ausgelöst. Unterstützt werden eine beliebige Zertifizierungsstelle und die externe Kontobindung, und ein neues Zertifikat wird ohne Neustart des Dienstes wirksam.

  • Schnelles Beenden des Dienstes — das Anhalten wartet nicht mehr auf einen Client, der aufgehört hat, Daten zu lesen: unter derselben Last beendet sich der Knoten in 2–4 Sekunden statt in etwa einer Minute, ein Neustart dauert also Sekunden und lässt die Sendung nicht ausfallen.

  • pss_lic 2.0 — das Kommandozeilen-Dienstprogramm zur Lizenzverwaltung wurde auf die Befehle apply, c2v, fingerprint, recipient, keys, detach, rehost und cancel mit langen Optionen umgestellt: es wendet ein zugesandtes Lizenz-Update an, exportiert den Zustand des Schlüssels für den Anbieter und überträgt die Lizenz von Knoten zu Knoten, auch vorübergehend, und jede Datei nimmt es von der Standardeingabe an und gibt sie auf der Standardausgabe aus. Ausführlich — pss_lic.

  • Konfigurationsdatei von Hand bearbeiten — zusammen mit der Dokumentation wird ein JSON Schema für pss.json veröffentlicht (streng und kompatibel), dazu eine Schritt-für-Schritt-Anleitung zum Bearbeiten und Übertragen der Datei: die Konfiguration eines gestoppten Knotens darf jetzt direkt bearbeitet und zwischen Installationen und Versionen übertragen werden, sofern das Ergebnis gegen das Schema geprüft wurde, während zuvor die HTTP API der einzige unterstützte Weg war. Ausführlich — Die Einstellungsdatei pss.json.

  • Neue Weboberfläche — die Verwaltung des Knotens wurde auf eine neue Konsole umgestellt, die unter der Adresse des Knotens geöffnet wird (Pfad /admin): Übersicht, Streams, Systemüberwachung, DVB, DVR, Transcoder, Clients, Protokoll, Alerts und alle Servereinstellungen. Eigene Diagramme zeigen die Topologie der Meshwork-Domain und den Signalweg des ausgewählten Streams von den Eingängen bis zu den Ausgängen. Die frühere Oberfläche bleibt unter /classic erhalten. Ausführlich — Weboberfläche.

  • Einmalige Anmeldung in der Domain — einem Konto kann die automatische Anmeldung erlaubt werden: nach einer Anmeldung mit Passwort öffnet der Browser 14 Tage lang das Panel dieses Knotens ohne Anmeldeformular und übersteht einen Neustart. Ein Link aus diesem Panel übergibt die Sitzung an einen benachbarten Knoten der Domain, sofern die Bedingungen der Übergabe erfüllt sind (Webserver & Konten); eine von Hand eingegebene Adresse eines Nachbarn überträgt die Sitzung nicht. Ein Skript oder ein fremdes Panel weist denselben Schlüssel im Header X-Auth-Token oder im Parameter auth-token vor, und ein Administrator widerruft die automatische Anmeldung sofort in der gesamten Domain.

  • CORS für die administrative API — die Knoten einer Meshwork-Domain sind ohne jede Einstellung zugelassen, die übrigen Ursprünge werden in web-server/cors-origin aufgeführt (der Wert * lässt jeden Ursprung zu, none schaltet den Mechanismus ab), sodass die Oberfläche eines Knotens die API eines anderen anspricht; eine domänenübergreifende Anfrage muss das Token ausdrücklich mitführen — Cookie und Digest wirken in ihr nicht.

  • Token der eigenen Sitzung — GET /data/auth-token liefert dem Client sein eigenes Token und die absolute Gültigkeitsdauer, und in /data/server kam das Feld web-login-expires hinzu, sodass die Oberfläche anzeigt, bis wann die Anmeldung gilt, ohne das Token selbst zu lesen.

  • Beenden einer Autologin-Sitzung — POST /data/auth-tokens/revoke?login=<login> schließt alle laufenden Sitzungen eines Kontos, ?id=<hex> eine einzelne anhand des Bezeichners aus der Sitzungsliste; in der Antwort kommt die Anzahl der geschlossenen Sitzungen, und der Widerruf verbreitet sich über die gesamte Domain.

  • Grund der Ablehnung beim Wechsel auf einen benachbarten Knoten — hat der Wechsel keine automatische Anmeldung ergeben, gibt der Knoten in der Adresse den Parameter jump mit dem Wert no-session, foreign-domain, autologin-off oder token-refused zurück, statt stillschweigend das Passwortformular anzuzeigen.

  • Aktualisierung in Echtzeit — der Knoten liefert seinen Zustand als Ereignisstrom unter /data/events: beim Verbinden trifft eine vollständige Momentaufnahme ein, danach werden im Sekundentakt die Frames der Streams, der Systemressourcen, der Clients und der DVB-Adapter aktualisiert, während Alerts und Zustandswechsel als Ereignisse eintreffen. Die Oberfläche und externe Dashboards arbeiten ohne periodische Abfrage.

  • Kontextbezogene Hilfe — jeder Bildschirm und jedes wichtige Fenster der neuen Oberfläche verfügt über einen Hilfeaufruf, der genau den Dokumentationsabschnitt zu dem öffnet, was gerade geöffnet ist: die allgemeine Hilfeschaltfläche für den Bildschirm, die Schaltfläche „?“ in der Fensterkopfzeile für dieses Fenster. Der Abschnitt wird in der Sprache der Oberfläche geöffnet.

  • Sprachen, Designs und Layouts — die Oberfläche ist in sechs Sprachen übersetzt (Russisch, Englisch, Deutsch, Französisch, Spanisch, Portugiesisch), unterstützt ein helles und ein dunkles Design und passt die Layoutdichte selbst an Telefon, Tablet, Arbeitsplatzrechner und Videowand an.

  • Zugang ohne Beschränkung der Verbindungszahl — die Verbindungsgrenzwerte des Empfängers haben einen dritten Zustand bekommen, „Ohne Beschränkung“, neben „Protokoll verboten“ und „Höchstens“ mit einer Zahl; früher wurde unbeschränkter Zugang durch eine bewusst große Zahl dargestellt. Null bedeutet nach wie vor ein Verbot des Protokolls, sodass sich die Bedeutung der gespeicherten Einstellungen nach dem Update nicht ändert. Ausführlich — Benutzer: hinzufügen und bearbeiten.

  • Die Bearbeitung des Stream-Zugangs berührt fremde Sitzungen nicht — das Hinzufügen eines Streams zur Liste der erlaubten und die Rückkehr zu einer leeren Liste reißen keine einzige Sitzung ab, und eine Verengung der Liste schließt die PS1- und SRT-Sitzungen nur auf den Streams, die aus ihr verschwunden sind. Früher schaltete jede Bearbeitung der Liste das Konto vollständig auf allen Protokollen ab.

  • Lizenzaktivierung über die Weboberfläche — der Bildschirm „Lizenz“ hat einen Abschnitt „Aktivierung“ bekommen: den Export des Schlüsselzustands für den Anbieter — als C2V-Datei oder in die Zwischenablage — und das Anwenden des zugesandten V2C-Schlüssels per Datei oder durch Einfügen des Textes. Das Anwenden des Schlüssels startet den Knoten neu. Ausführlich — Lizenz.

  • Warnung vor dem Ablauf der Lizenz — der Knoten löst zwei Wochen vor dem Ende der Frist einen Alert aus und stuft ihn hoch auf die Stufe, die einen Eingriff erfordert, wenn die Frist abgelaufen ist. Der Alert wird domänenweit repliziert, sodass die ablaufende Lizenz eines Nachbarn von jedem Knoten aus zu sehen ist (Benachrichtigungen (Alerter)).

  • Eine als nicht echt erkannte Lizenz stoppt den Node — ein Node, dessen Lizenz als nicht echt erkannt wird, löst einen Alarm aus, der einen Administrator-Eingriff erfordert, startet den Dienst neu, und der Start wird abgelehnt: der Dienst bleibt gestoppt, bis auf dem Node eine echte Lizenz vorliegt. Der Alarm wird über die Domain repliziert (Benachrichtigungen (Alerter)).

  • Rückfall auf die letzte funktionierende Konfiguration — der Node bewahrt eine Kopie der Einstellungen auf, mit denen er zuletzt sauber gestartet ist, und kommt bei einer inakzeptablen pss.json mit dieser Kopie hoch — mit allen seinen Streams und nicht mit den Standardeinstellungen, die keine Streams enthalten. Das Archiv der abgelehnten Dateien wurde in Ordnung gebracht: Namen in UTC, ein Zählsuffix statt Überschreiben, wenn zwei Fehlschläge in dieselbe Sekunde fallen, die zwanzig jüngsten Kopien; den Pfad der archivierten Kopie nennt der Alarm direkt. Ausführlich — Verhalten beim Start und bei Konfigurationsfehlern.

  • Eingangspriorität lässt sich mit der Maus und über die Tastatur bearbeiten — ein Administrator kann die Eingänge eines Streams per Ziehen oder mit Alt+↑ und Alt+↓ umsortieren, auf der Registerkarte „Eingänge“ des Editors und in der aufgeklappten Zeile der Streamliste (auf dem Telefon wird die Reihenfolge nur angezeigt); ein hinzugefügter Eingang steht immer an letzter Stelle und ersetzt nie den Haupteingang (Streams).

  • Die Nummer eines Eingangs ist sein Platz in der Redundanzliste — ein und dieselbe Nummer steht jetzt in der Streamzeile, in der aufgeklappten Zeile, im Editor und im Text des Alarms. Eingänge mit gleichem Prioritätswert behalten die Reihenfolge, in der sie eingetragen sind, auch bei späteren Änderungen der Einstellungen (Quellenredundanz).

  • Der Ausfall eines verlassenen Eingangs liest sich als Historie — der Eingang, den der Stream zugunsten einer Reserve verlassen hat, wird gestoppt, behält aber seinen Grund: die Oberfläche zeigt ihn als gedämpfte Zeile mit Alter an, nicht als aktuellen Fehler, und der Alarm über den Fehler dieses Eingangs wird zurückgenommen. Der Grund ist dabei der eigene, transportbezogene, sofern der Eingang ihn noch selbst melden konnte (Quellenredundanz).

  • Sortierung der Clientliste — auf dem Bildschirm „Clients“ sortiert eine Spaltenüberschrift die Liste: numerische Spalten öffnen absteigend, textuelle von A bis Z, der dritte Klick stellt die Reihenfolge des Nodes wieder her. Sortiert wird die gesamte gefundene Liste, nicht die angezeigte Seite (Clients).

  • Sprung zum Stream vom Transcoder-Bildschirm — die Zeile des Decoders und jedes Encoders hat eine Schaltfläche erhalten, die die Streamliste beim betreffenden Stream öffnet. In jeder Rolle verfügbar (Transcoder).

  • Das Demultiplexer-Programm wird auch für einen DVB-Adapter aus einer Liste gewählt — ein laufender Adapter veröffentlicht seinen Multiplex, und das Feld „PNR“ bietet dessen Programme mit Namen an, einschließlich der inneren T2-MI-Programme unter ihren zusammengesetzten Nummern (Demultiplexer (demuxer)). Auch der Adapter eines dvb-Eingangs wird über den Namen gewählt und nicht als Datensatznummer eingegeben (DVB-Adapter (dvb)).

  • Der DVB-Empfang hängt nicht mehr vom Build ab — der Eingangstyp dvb und der Bereich der DVB-Adapter stehen auf jedem Node zur Verfügung; einzige Bedingung ist ein erkanntes Frontend und ein Treiber, der dem Dienst das Öffnen erlaubt (DVB-Empfänger).

  • Der DVB-Scanner überlässt den Tuner einem konfigurierten Adapter — ein gefundener Multiplex lässt sich anwenden, ohne das Ende des Durchlaufs abzuwarten: der Adapter nimmt sich den Tuner und kommt nach etwa einer Sekunde hoch, während der Suchlauf als abgebrochen endet und seine Ergebnisse auf dem Bildschirm behält. Ein Durchlauf wird mit der Schaltfläche „Stopp“ und durch Schließen des Fensters beendet (Scan).

  • Die Panels der Node-Übersicht richten sich nach dem Vorhandensein des Subsystems — „Transcoder“ und „DVB-Adapter“ erscheinen in der Übersicht dort, wo die Hardware oder die Instanzen vorhanden sind oder wo es einen Ausfall zu melden gibt. Auf einem Node ohne Transcoder und ohne Tuner fehlen diese Panels, und damit auch der Weg in ihre Bereiche von der Übersicht aus (Knotenübersicht).

  • Interface-Adressen im Systemmonitor — die Karte „Netzwerk“ und die Verlaufsdiagramme sind mit der IPv4-Adresse des Interfaces beschriftet, sofern der Node sie meldet, verschachtelte VLANs eingeschlossen (System-Monitor).

  • Ein DVR-Speicherpfad wird ohne abschließendes Trennzeichen geschrieben — die Oberfläche und die HTTP-API lehnen einen solchen Wert ab: zwei Schreibweisen desselben Verzeichnisses würden die Eindeutigkeitsprüfung als zwei verschiedene Speicher passieren (DVR-Speicher).

  • Das Paket benötigt den Schutzdienst 10.33 oder neuer — pstreamer liefert die Bibliotheken des Schutzsystems der neuen Generation, und ein älterer aksusbd nimmt sie nicht an (Systemanforderungen). Der Dienst liegt im selben Repository und wird zusammen mit dem Paket installiert, doch seine Aktualisierung ist unumkehrbar, unabhängig vom Schlüsseltyp — Ablauf und Folgen sind auf den Installationsseiten beschrieben (Installation auf Systemen der RHEL-Familie, Installation auf Systemen der Debian-Familie).

  • Explizite PLP-Auswahl bei DVB-T2 — das Feld „Stream id (ISI/PLP)“ hat den Wert „auto“ (-1) erhalten: es wird kein Filter angewendet, der Tuner nimmt den Standardstream des Treibers, und ein neuer Adapter wird genau so angelegt. Eine ausdrückliche Null ist damit zu einer echten Auswahl des Streams null geworden und nicht mehr „nicht gesetzt“, sodass ein Adapter, bei dem Null in den Einstellungen gespeichert ist, nach der Aktualisierung des Nodes nur noch diesen Stream empfängt (Adapter).

  • Der Scanner findet PLPs — das Feld „PLP prüfen bis“ durchläuft die PLPs auf DVB-T2-Transpondern und führt jeden gefundenen als eigene Zeile mit eigener Programmliste auf; die Nummer wird in den angelegten Adapter übernommen, und die Adapterstatistik hat eine Zeile „PLP / ISI“ erhalten (Scan).

  • Suche in den Scanner-Katalogen — Hunderte von Satelliten und regionalen Bändern sind nach Namen sortiert und werden über eine Suchzeile gefiltert; eine bereits ausgewählte Zeile verschwindet nicht aus der Liste, was auch immer eingegeben wird (DVB-Scan).

  • Korrektur des PCR-Verweises in der PMT — eine neue MPEG-TS-Einstellung für Quellen, deren Tabelle keine brauchbare PCR angibt: der Node trägt in die PMT die PID ein, auf der die PCR tatsächlich übertragen wird (Modifikation des Streams).

  • Wiederaufbau des Jitter-Buffers nach einem Einbruch der Quelle — ein Eingang, der einen Stillstand seiner Quelle überstanden hat, läuft nicht länger mit einer fast leeren Warteschlange weiter und gibt nicht mehr jedes weitere Stocken an die Ausgänge weiter: der Node baut den Buffer einmalig neu auf, um den Preis eines einzigen Aussetzers (Synchronisation).

  • Bitratensteuerungsmodus des Videoencoders — der Transcoder hat die Wahl zwischen einer konstanten Rate und zwei variablen Modi erhalten: die angegebene Zahl wird entweder als mittlere Bitrate gelesen (Spitzen erreichen das Anderthalbfache) oder als harte Obergrenze (die mittlere Rate beträgt dann zwei Drittel davon). Es bleibt dabei bei einer einzigen Zahl — die zweite Grenze leitet der Encoder selbst aus einem festen Spitzen-zu-Mittelwert-Verhältnis von 1,5 ab. In den variablen Modi füllt der Encoder den Elementarstrom nicht mehr auf, sodass Bandbreite nur dort gespart wird, wo der empfangende Stream die Bitrate nicht wieder ausgleicht (Einstellungen des Encoders).

  • Ein Transcoder-Neustart wird im Journal erklärt — jeder Neustart des Kindprozesses nennt seinen Grund und seinen Exit-Code auf der Stufe „Hinweis“, statt still im Trace. Außerdem öffnet der Node einen nicht antwortenden Kanal nicht mehr endlos neu: nach zwei fehlgeschlagenen Versuchen fordert er einen neuen Prozess an (Betriebsüberwachung).

  • Ein gelöschter Stream ist im geöffneten Editor sichtbar — wird ein Stream vom Node gelöscht, während sein Editor oder sein Verarbeitungsschema geöffnet ist, meldet der Node das in einer eigenen Zeile, und das Speichern wird mit derselben Begründung neben der Schaltfläche gesperrt. Zuvor leerten sich bei einem solchen Stream einfach alle Listen, was wie ein Stream ohne konfigurierte Ein- und Ausgänge aussah (Stream konfigurieren).

  • Eine abgelehnte Speicherung nennt ihren Grund — statt eines einzigen Allgemeinsatzes für alle Fälle meldet das Formular, was genau im Weg stand: eine abgelaufene Antwortzeit, eine Rollenbeschränkung oder die eigene Ablehnung des Nodes in dessen eigenen Worten.

  • PID-Beschriftungen und PID-Auswahl in den Filterregeln — jede Nummer ist mit Art und Codec beschriftet und bei einem Multiplex zusätzlich mit dem Programm, zu dem sie gehört; die Hinzufügen-Zeile hat eine Liste der PIDs erhalten, die die Quelle tatsächlich führt. Die manuelle Eingabe bleibt bestehen: der Transport kann eine PID führen, zu der nichts dekodiert wurde (Editor für Eingang und Ausgang).

  • Die DVB-Bildschirme zeigen die adressierbare Programmnummer — bei einem Dienst innerhalb eines T2-MI-Trägers steht in der Programmliste des Adapters und in dessen Statistik die zusammengesetzte PNR, genau jene, mit der das Programm in der Auswahl beim Demultiplexer, bei BISS und bei CAM adressiert wird. Die eigene Nummer innerhalb des Trägers wiederholt sich auf einem Transponder mit gespiegelten Gruppen bei jedem Träger und verweist auf nichts (Adapter-Statistik).

  • Ein BISS-Slot wird immer als Liste angeboten — unverschlüsselte Programme sind zuletzt hinzugekommen, gekennzeichnet mit · clear ·, sodass die Liste auf einem Multiplex ohne ein einziges verschlüsseltes Programm nicht mehr leer bleibt: der Schlüssel wird häufig im Voraus eingetragen, und ein Event-Feed ist zwischen den Ereignissen unverschlüsselt (Entschlüsselung).

  • Von der Streamstatistik zum Transcoder und zu dessen Quelle — wurde der aktive Eingang eines Streams von einem Transcoder erzeugt, ist sein Wert zu einem Link auf den Transcoder-Bildschirm mit aufgeklappter Zeile der betreffenden Instanz geworden, und daneben ist eine Plakette mit dem Namen des Streams erschienen, den diese Instanz dekodiert. Beide Links sind in jeder Rolle verfügbar (Stream-Statistik).

  • Lauf-Grenzen im Journal — jeder Start des Dienstes ist im Verlauf durch eine eigene Zeile mit dem Zeitpunkt des Starts und dem Build gekennzeichnet, auf dem der Lauf hochgekommen ist: beim aktuellen Lauf steht daneben dessen Uptime, bei vergangenen, wie lange der Lauf gearbeitet hat und wie lange der Node bis zum nächsten Start stillstand, und ein ohne regulären Stopp beendeter Lauf wird besonders markiert. Der Trenner wird auch bei eingeschaltetem Schweregradfilter gesetzt (Logs).

  • Größenbegrenzung der Statistikdatenbank — die Metrikdatenbank wird nicht nur durch das Aufbewahrungsfenster begrenzt, sondern auch durch die Größe. Der Node berichtet über die letzte Bereinigung — wie viel Historie geblieben ist, wie groß die Datenbank ist und wie lange die Bereinigung gedauert hat — und sagt es ausdrücklich, wenn sich die Größenbegrenzung als strenger erwiesen hat als das eingestellte Fenster (Server-Einstellungen).

  • Beim Laden beschnittene Werte werden sofort angesagt — hat der Node beim Lesen der Einstellungen einen Wert an die zulässige Grenze herangezogen, meldet er das gleich nach dem Start auf dem Bildschirm und nicht nur in einer Zeile im Journal (Verhalten beim Start und bei Konfigurationsfehlern).

  • Eine Lizenz einer veralteten Generation wird nicht angenommen — ein Node mit einer echten Lizenz der vorigen Generation startet nicht und löst einen eigenen Alarm aus. Das ist weder eine abgelaufene Frist noch eine Fälschung: Generation 2 wird nur als befristete Testlizenz angenommen, deshalb wird eine unbefristete Lizenz dieser Generation sofort abgelehnt und lebt nicht bis zu ihrem Datum (Katalog der Alarmcodes).

  • Das automatische Auffüllen berechnet sein Ziel aus dem Inhalt — im automatischen Bitratenmodus geht der Node von der tatsächlichen Rate des Inhalts aus und nicht vom eigenen Ausgang, sodass das Ziel nicht mehr ohne Rückkehr nach oben kriecht und wieder sinkt, sobald der Inhalt erneut in die eingestellte Rate passt (Bitratensteuerung).

  • Das Fenster der Driftkompensation ist dem Buffer angemessen — das weiche Fenster ist auf ein Viertel der Zielgröße des Jitter-Buffers begrenzt, jedoch nie unter 100 ms: ein Eingang mit dem Standardbuffer arbeitet nicht mehr ohne Reserve, die Kompensation zieht die Synchronisation früher nach, und der Notfall-Neuaufbau des Buffers bei Leerlauf greift endlich (Synchronisation).

  • Weitere Verbesserungen und Fehlerbehebungen.