CCcam DVBAPI Delayer: Fehlerbehebung bei Einfrierungen& Einrichtungsanleitung

Wenn Sie hier gelandet sind, weil Ihre Kanäle alle 10 Sekunden genau einfrieren, haben Sie es mit einem Timing-Rennen zu tun — nicht mit einer schlechten Linie. DerCCcam dvbapi delayer Konfiguration ist der Regler, der es behebt. Diese Anleitung behandelt genau, wie man es einstellt, wie man die Protokolle liest, um es richtig abzustimmen, und wann es nicht hilft, damit Sie nicht drei Stunden mit der falschen Sache verschwenden.

Was der DVBAPI Delayer tatsächlich tut

Die DVBAPI-Schnittstelle ist, wie Ihr Set-Top-Box (oder Linux-basierter Receiver, der Enigma2 ausführt, zum Beispiel) seinen CA-Entschlüsseler für die Benutzersoftware bereitstellt. Anstatt ein physisches CAM zu verwenden, schreibt ein DVBAPI-Client wie OScam oder CCcams integriertes DVBAPI-Plugin Steuerwörter (CWs) direkt in den Demuxer über/dev/dvb/adapterX/caY.

Der Delayer fügt eine Pause ein — gemessen in Millisekunden — zwischen dem Moment, in dem die Software ein entschlüsseltes CW erhält, und dem Moment, in dem sie dieses CW an die Hardware schreibt. Ohne diese Pause kann das CW schneller ankommen, als der Demuxer bereit ist, es zu verarbeiten. Das Ergebnis: ein schwarzer Bildschirm, ein Einfrieren oder ein kurzes Stottern bei jedem Schlüsselwechsel.

ECM-zu-Steuerwort-Timing in CCcam DVBAPI

Kurze Definitionen, damit wir auf derselben Seite sind. EinECM (Entitlement Control Message) ist ein kurzes verschlüsseltes Paket, das im DVB-Stream gesendet wird. Ihr Sharing-Client sendet es upstream, die Karte entschlüsselt es und gibt einSteuerwort — den tatsächlichen 8-Byte-Schlüssel, den Ihr Entschlüsseler benötigt, um das Video zu dekodieren, zurück. Diese gesamte Rundreise dauert je nach Ihrer Leitung einige Millisekunden.

Die meisten Pay-TV-Anbieter rotieren ihre Schlüssel in einemKrypto-Zeitraum von etwa 10 Sekunden. Wenn der Zeitraum wechselt, kommt ein neues ECM an, ein neues CW wird abgerufen, und der DVBAPI-Client muss es genau im richtigen Moment an den Demuxer schreiben. Zu früh und die Hardware verwirft es. Zu spät und Sie erhalten eine Einfrierpause.

Warum eine Verzögerung erforderlich ist, bevor das CW an den Demuxer geschrieben wird

Die Demuxer-Hardware auf vielen Receivern — insbesondere älteren Dreambox-Geräten und Budget-Enigma2-Boxen — hat ein kleines Zeitfenster, in dem sie ein neues CW akzeptiert. Wenn Ihr Sharing-Client schnell ist (was normalerweise eine gute Sache ist), kann er das Rennen gegen die Hardware gewinnen und schreiben, bevor der Demuxer mit dem Übergang zum neuen Krypto-Zeitraum fertig ist.

Der Delayer zwingt die Software, das CW für N Millisekunden zu halten, bevor es geschrieben wird. Dieser Spielraum lässt die Hardware aufholen. Es klingt kontraintuitiv — die Reaktion zu verlangsamen, um ein Problem zu beheben — aber es funktioniert, und es funktioniert konsequent, wenn es richtig abgestimmt ist.

Wie sich CCcam von OScams dvbapi-Verarbeitung unterscheidet

CCcams native DVBAPI-Unterstützung ist ziemlich grundlegend. Es funktioniert, aber die Konfigurierbarkeit ist begrenzt — Sie erhalten eine globale Verzögerung, und das war's. OScams dvbapi-Implementierung ist erheblich ausgereifter: pro-CAID-Verzögerungen, pro-SID-Überschreibungen, eine Weboberfläche, die die ECM-Zeiten in Echtzeit anzeigt, und bessere Adapter-Zielauswahl.

Deshalb verbinden die meisten Produktions-Setups CCcam mit OScam: CCcam verwaltet das Protokoll und das Kartenteilungsnetzwerk, aber OScam kümmert sich um das eigentliche Entschlüsseln. Wenn Sie CCcam DVBAPI noch nativ ausführen und gegen Einfrierungen kämpfen, ist der OScam-Migrationspfad es wert, in Betracht gezogen zu werden — mehr dazu im letzten Abschnitt.

Schritt-für-Schritt Delayer-Konfiguration

DieCCcam dvbapi delayer Konfiguration richtig zu bekommen, beginnt mit dem Wissen, welche Datei zu bearbeiten ist. Der Pfad variiert je nach Ihrem Image und ob Sie CCcams integriertes DVBAPI oder die Verbindung über OScam verwenden.

Konfiguration finden: CCcam.cfg vs oscam.dvbapi

Für reines CCcam DVBAPI befindet sich die Hauptkonfiguration unter/var/etc/CCcam.cfg auf den meisten Enigma2-Images (OpenATV, OpenPLi, OpenViX). Bei älteren Setups oder auf Gemini-basierten Images finden Sie es möglicherweise unter/etc/CCcam.cfg. Überprüfen Sie beide, wenn Sie sich nicht sicher sind.

Wenn Sie OScam mit einem CCcam-Reader verwenden (das häufigere Setup), befindet sich die Verzögerung in/etc/tuxbox/config/oscam/oscam.dvbapi oder/var/etc/oscam.dvbapi, abhängig von deinem Image. OpenATV verwendet tendenziell/var/etc/. OE-Alliance-Images legen es manchmal unter/etc/oscam/. Führefind / -name oscam.dvbapi 2>/dev/null aus, wenn du es nicht finden kannst.

Einstellung des Verzögerungswerts (DELAY: Parameter und ms-Bereiche)

InCCcam.cfg sieht die Zeile so aus:

DELAY : 150

Das sind Millisekunden. Beginne bei100–300 ms und passe von dort aus an. Wenn die Kanäle bei einem Schlüsselwechsel weiterhin einfrieren, erhöhe es in 50 ms-Schritten. Wenn das Zappen träge wirkt — du drückst eine Taste und wartest einen Moment zu lange — bist du zu hoch gegangen, bringe es in 25 ms-Schritten wieder nach unten.

Inoscam.dvbapi ist das Format anders. Eine globale Verzögerungszeile sieht so aus:

DELAY : 150

Aber du kannst auch spezifische Einträge anvisieren. Das vollständige Format pro Eintrag ist:

P: CAID:ProvID:SID:PMT_PID:ECM_PID : DELAY

Zum Beispiel, um eine Verzögerung von 200 ms für eine spezifische CAID/Provider-Kombination festzulegen, während alles andere bei 100 ms bleibt:

DELAY : 100

Wo einige Receiver eine Weboberfläche für CCcam bereitstellen (der integrierte HTTP-Server läuft standardmäßig auf Port 16001), findest du dort möglicherweise auch ein Feld "DVB API DELAY". Verlasse dich nicht nur darauf — Änderungen über die Web-UI überstehen nicht immer einen Daemon-Neustart, es sei denn, die zugrunde liegende Konfigurationsdatei wird ebenfalls aktualisiert.

Pro-Kanal- und pro-CAID-Verzögerungsüberschreibungen

Das ist es, was die meisten Anleitungen übersehen. Eine globale Verzögerung ist grob — sie verlangsamt jede Kanaländerung über jeden CAID. Aber in der Praxis ist das Timing-Problem fast immer CAID-spezifisch oder sogar transponder-spezifisch. Die Krypto-Periode eines Anbieters synchronisiert sich gut bei 100 ms; ein anderer benötigt 250 ms, weil ihre ECMs im Vergleich zum Schlüsselwechsel leicht verspätet ankommen.

OScam'soscam.dvbapi ermöglicht es dir, Verzögerungen genau festzulegen. Wenn du die CAID (z.B. 0963 oder 1810) des problematischen Pakets kennst, setze eine höhere Verzögerung nur für diesen Eintrag und lasse die globale niedriger. Dein Sportpaket zapt schnell; dein Film-Paket bleibt stabil. Beide funktionieren.

Auf einem Transponder mit gemischten CAIDs — sagen wir, ein Free-to-Air-Paket, das mit einem verschlüsselten multiplexiert ist — stelle sicher, dass deine CAID-Zielsetzung präzise ist, sonst verlangsamst du das Zappen auf Kanälen, die es nicht benötigen.

Neustart des Daemons und Bestätigung der Ladeänderung

CCcam lädt die Konfiguration nicht im laufenden Betrieb neu. Nach der Bearbeitung vonCCcam.cfg starte es neu:

killall -9 CCcam&& sleep 2&& CCcam

Oder über dein Init-Skript, wenn du eines eingerichtet hast (/etc/init.d/CCcam neu starten). Überprüfen/tmp/CCcam.log oder welchen Protokollpfad Sie konfiguriert haben und suchen Sie nach der DELAY-Zeile, die beim Start analysiert wird.

Für OScam ist ein sanfter Neustart ausreichend:

killall -HUP oscam

Oder verwenden Sie die OScam-Weboberfläche unter Port 8888 → Neustart. Überprüfen Sie, ob die Informationsseite bestätigt, dass Ihr dvbapi-Verzögerungswert dem entspricht, was Sie erwarten.

Protokolle lesen, um die richtige Verzögerung zu finden

Das Raten von Verzögerungswerten ist Zeitverschwendung. Die Protokolle sagen Ihnen genau, was passiert, und fünf Minuten Lesen schlagen eine Stunde Versuch und Irrtum.

Debug-Protokollierung aktivieren (loghistorysize, Protokollebene)

In OScamsoscam.conf, unter[global]:

[global]

Stufe 64 gibt Ihnen ECM-Ebene Details, ohne das Protokoll mit Rauschen zu überfluten. Wenn Sie mehr benötigen, kombinieren Sie es:loglevel = 64+32 fügt Leser-Debug-Informationen hinzu. Alles, was höher ist, benötigt eine größereloghistorysize oder die Historie füllt sich, bevor Sie sie lesen können.

Für CCcam wird die Protokollausführlichkeit inCCcam.cfg:

DEBUG LEVEL : 1

Stufe 1 ist normalerweise ausreichend, um CW-Lieferereignisse zu sehen. Stufe 3 zeigt den gesamten ECM-Verkehr, erzeugt jedoch eine Menge Ausgabe.

Interpretation der Dekodier-/Einfrierzeit im Protokoll

Was Sie suchen, ist die Zeit zwischen ECM-Ankunft und CW-Lieferung und wie sich das mit Ihren Einfrierereignissen korreliert. In OScam-Protokollen sieht jede Dekodierzeile ungefähr so aus:

[reader] (ecm time: 87 ms) CW gefunden [0963/000000/1234]

Diese 87 ms-Zahl ist Ihre Hin- und Rückfahrt-ECM-Zeit. Wenn Ihre Krypto-Periode 10 Sekunden beträgt und Ihre ECMs konstant bei 87 ms Dekodierzeit ankommen, deckt eine Verzögerung von 100–150 ms die Lücke mit Spielraum ab. Wenn diese Zahl gelegentlich auf 400 ms ansteigt (Netzwerkproblem, überlasteter Server), benötigen Sie entweder eine höhere Verzögerung oder eine bessere Leitung.

Vergleichen Sie die Zeitstempel der Einfrierungen in Ihrem Receiver-Protokoll mit dem Schlüsselwechselintervall. Wenn Einfrierungen konstant in Abständen von 9,8–10,2 Sekunden auftreten, handelt es sich um ein Timing-Problem, und der Verzögerer wird es beheben. Wenn Einfrierungen zufällig sind — alle paar Minuten, kein Muster — ist das kein Timing-Problem.

Werkzeuge: tail -f, oscam-Statusseite, ECM-Zeitspalte

Die OScam-Weboberfläche unterhttp://[receiver-ip]:8888 hat einen ECM/EMM-Tab, der die aktuellen Dekodierzeiten pro CAID anzeigt. Diese "msec"-Spalte ist die Grundlage für Ihre Verzögerungseinstellung. Sie aktualisiert sich in Echtzeit.

Für das Beobachten von Rohprotokollen:

tail -f /tmp/oscam.log | grep "ecm time"

Führen Sie das aus, während Sie umschalten und nach Einfrierungen Ausschau halten. Die praktische Abstimmungsmethode: Beginnen Sie hoch (sagen wir, 300 ms), beobachten Sie die Verzögerung beim Umschalten, reduzieren Sie alle paar Minuten um 50 ms, während Sie nach Einfrierereignissen überwachen. Wenn Einfrierungen wieder auftreten, fügen Sie 75 ms als Sicherheitsmarge hinzu und beenden Sie es.

Häufige Fehlkonfigurationen und wie man sie behebt

Die meisten Einfrierprobleme, die die Leute dem Verzögerer zuschreiben, sind tatsächlich etwas anderes. Hier ist, was ich konsequent sehe.

Globale Verzögerung eingestellt, wenn nur ein CAID es benötigt

EinstellungVERZÖGERUNG : 300 global, um ein hartnäckiges Kanalpaket zu beheben, bedeutet, dass jeder einzelne Kanalwechsel 300 ms länger dauert. Wenn Sie während eines Sportereignisses 15 Kanäle in 30 Sekunden wechseln, summiert sich das zu spürbarem Lag.

Lösung: Identifizieren Sie den CAID, der Probleme verursacht (überprüfen Sie das ECM-Protokoll), setzen Sie die hohe Verzögerung nur für diesen CAID inoscam.dvbapi und bringen Sie die globale zurück auf 100 ms oder weniger.

Falscher Adapter/Demux-Index für Multi-Tuner-Boxen

Bei einem Dual-Tuner-Empfänger – häufig bei Vu+ Duo2, Dreambox DM920 oder ähnlichem – haben Sie/dev/dvb/adapter0 und/dev/dvb/adapter1, jeder mit seinem eigenenca0 Gerät. Wenn Ihr DVBAPI-Client aufadapter0/ca0schreibt, aber der aktive Tuneradapter1ist, erhalten Sie einen vollständigen Entschlüsselungsfehler, unabhängig von den Verzögerungswerten.

In OScamsoscam.dvbapisetzen Sie den Adapter mit:

BOXTYPE : dreambox

Und überprüfen Sie die Adapterenumeration in/proc/bus/pci/ oder überls /dev/dvb/. Einige Images nummerieren Tuner nach einem Kernel-Update unterschiedlich. Wenn sich Ihre Konfiguration nicht geändert hat, aber die Entschlüsselung plötzlich nicht mehr funktioniert, überprüfen Sie, ob sich die Adapterindizes verschoben haben.

Konflikte zwischen CCcam DVBAPI und einer parallelen OScam-Instanz

Das ist überraschend häufig. Jemand installiert OScam neben einer laufenden CCcam-Konfiguration, ohne CCcams integrierte DVBAPI zu deaktivieren. Beide versuchen gleichzeitig,/dev/dvb/adapter0/ca0zu öffnen. Das Ergebnis ist unvorhersehbar – manchmal gewinnt einer, manchmal kämpfen sie, was immer zu Instabilität führt.

Sie benötigen genau einen aktiven DVBAPI-Client. Wenn Sie OScam verwenden, deaktivieren Sie DVBAPI in CCcam, indem Sie dieDVBAPI : 1 Zeile (oder das Äquivalent) inCCcam.cfgentfernen oder auskommentieren. Wenn Sie CCcams native DVBAPI verwenden, stellen Sie sicher, dass OScam nicht als dvbapi-Client konfiguriert ist.

Receiver-seitige Caching maskiert das eigentliche Problem

Einige Enigma2-Images – insbesondere ältere OpenPLi-Bauten – cachen das zuletzt verwendete CW kurzzeitig. Das kann den Anschein erwecken, dass die Dekodierung funktioniert, während tatsächlich veraltete Schlüssel für ein oder zwei Sekunden bereitgestellt werden, bevor sie fehlschlägt. Das Symptom: kein Einfrieren beim ersten Anschauen, aber schnelles Zappen verursacht kurze schwarze Bildschirme, die sich selbst beheben.

Deaktivieren Sie das CW-Caching, wenn Ihr Image diese Option bietet, oder aktualisieren Sie auf einen aktuellen Image-Bau, bei dem dies besser gehandhabt wird. OpenATV 7.x und OpenPLi 9.x sind hier zuverlässiger als alles aus 2022 oder früher.

Wenn der Delayer nicht hilft (und was helfen wird)

Dies ist der Abschnitt, den die meisten Anleitungen überspringen, und er ist wichtig.Die CCcam dvbapi Delayer-Konfiguration behebt genau ein Problem: ein Timing-Rennen zwischen CW-Lieferung und der Bereitschaft des Demuxers. Es behebt keine Netzwerkprobleme, schlechte Leitungen oder Hardwarebeschränkungen.

Einfrieren verursacht durch Netzwerklatenz, nicht durch Timing

Wenn Ihre ECM-Roundtrip-Zeiten im OScam-Log zufällig zwischen 80 ms und 1200 ms springen, ist das Netzwerkinstabilität. Vielleicht ist der Share-Peer überlastet. Vielleicht hat Ihre Internetverbindung Paketverluste. Der Delayer hat hier nichts beizutragen — Sie können ihn nicht hoch genug einstellen, um einen 1,2-Sekunden-Spike abzudecken, ohne dass das Zappen kaputt wirkt.

Diagnose von Netzwerkproblemen mitping -i 0.2 [server-ip] während Sie Fernsehen. Wenn Sie Ausreißer-Pings sehen, die mit Einfrierereignissen zusammenfallen, ist die Verzögerungseinstellung irrelevant. Beheben Sie das Netzwerk oder finden Sie eine stabilere Share-Quelle.

Krypto-Perioden-/Schlüsselwechselprobleme vs. Verzögerungsprobleme

Timingbezogene Einfrierungen folgen einem Muster: Sie treten in vorhersehbaren Intervallen auf, die mit der Krypto-Periode übereinstimmen. Wenn Sie ein Einfrieren um 10:01:10 und ein weiteres um 10:01:20 und ein weiteres um 10:01:30 bemerken, ist das eine 10-Sekunden-Krypto-Periode und ein Verzögerungsproblem. Beheben Sie es mit dem Delayer.

Wenn Einfrierungen um 10:01:12, 10:04:47, 10:09:03 auftreten — kein Muster — ist das kein Timing-Problem beim Schlüsselwechsel. Passen Sie den Delayer nicht an, untersuchen Sie etwas anderes.

Hardware-Demux-Beschränkungen bei älteren Receivern

Einige ältere Receiver — Dreambox 500s, erste Generation AZBox-Geräte, bestimmte No-Name-Chinesische Boxen — haben Hardware-Demuxer, die einfach keine softwareseitig gelieferten CWs schnell genug akzeptieren können, unabhängig davon, wie der Delayer eingestellt ist. Das Fenster ist zu eng oder die Hardware hat Eigenheiten, die kein Software-Delay ausgleichen kann.

Auf diesen Boxen ist das Einfrieren oft nur ein paar Frames und kein harter schwarzer Bildschirm, und es passiert bei jedem einzelnen Schlüsselwechsel, egal was Sie einstellen. Wenn das Ihre Situation ist, ist die Hardware der Engpass. Ein moderner Vu+, Gigablue oder AX-Receiver wird dasselbe Setup ohne Probleme bewältigen.

Migration von CCcam DVBAPI zu OScam für Stabilität

Wenn Sie CCcams native DVBAPI verwenden und bei den Konfigurationsoptionen auf Grenzen stoßen, ist die Migration zu OScam als DVBAPI-Handler, während Sie CCcam als Sharing-Protokoll beibehalten, der richtige Schritt. Die Brücke ist auf hoher Ebene einfach: OScam verbindet sich über das newcamd- oder CCcam-Protokoll auf Port 10000 (oder welchem Port Ihr CCcam-Server auch immer verwendet) mit CCcam als Leser und übernimmt dann die gesamte lokale DVBAPI-Entschlüsselung selbst.

Inoscam.server sieht Ihr CCcam-Leser so aus:

[reader]

OScam übernimmt dann die DVBAPI-Seite mit vollständiger Verzögerungssteuerung, gezielter CAID-Ansprache und der Weboberfläche, um alles zu überwachen. Die Einfrierprobleme, die aus CCcams grundlegender DVBAPI-Implementierung resultieren, verschwinden normalerweise sofort, wenn Sie diesen Wechsel vornehmen.