Focus SAT CCcam/OScam Einrichtung: Konfiguration& Fehlerbehebung

Wenn Sie einen Softcam-Server betreiben und Ihre Focus-SAT-Kanäle ständig auf einem schwarzen Bildschirm landen, alle paar Sekunden einfrieren oder ECM-Fehler im Protokoll ausgeben, liegt das Problem fast sicher nicht an Ihrer Schüssel. Neun von zehn Malen ist es ein falsch konfiguriertes Reader-Block, eine nicht übereinstimmende CAID oder ein Timeout, das entweder gültige CWs stranguliert oder so lange wartet, dass der Kanal bereits mitten im Einfrieren ist, bevor der Schlüssel ankommt.

Dieser Artikel richtet sich an Personen, die bereits dabei sind, dies einzurichten — Sie haben eine Zeile, Sie haben einen laufenden Server und etwas Bestimmtes ist kaputt. Das Focus-SAT-Paket befindet sich hauptsächlich auf Hot Bird 13E und Thor 0.8W/1W, je nach Region, und die Verschlüsselungseinrichtung hat einige Eigenheiten, die selbst erfahrene Konfigurationen durcheinanderbringen.

Beginnen Sie damit, die live CAID zu erfassen, bevor Sie etwas anderes anfassen. Statische Werte, die in Foren gepostet werden, sind unzuverlässig — Betreiber rotieren sie, und eine zuvor funktionierende Konfiguration kann über Nacht stillschweigend fehlschlagen.

Identifizierung der Focus SAT CAID und Provider-IDs

Hier überspringen die meisten Leute und verbringen dann Stunden damit, das falsche Problem zu beheben. Die CAID und die Provider-ID sind die Grundlage — wenn Sie sie falsch haben, wird nichts downstream funktionieren, egal wie sauber Ihroscam.Server aussieht.

CAID/Provider von der Kanalinfo-Anzeige lesen

Stimmen Sie auf einen verschlüsselten Focus-SAT-Kanal ein, von dem Sie wissen, dass er entschlüsselt werden sollte. Drücken Sie auf den meisten Enigma2-Bildern zweimal die Info-Taste oder halten Sie sie gedrückt, um die technische Detailansicht zu erhalten. Sie möchten die CA-Systemzeile — sie zeigt etwas wie0B00:000000 oder ein ähnliches Hex-Paar. Die erste Hälfte ist die CAID, die zweite ist die Provider-ID.

Auf OpenPLi und OpenATV zeigt der erweiterte Info-Bildschirm (normalerweise über die blaue Taste zugänglich> Signal) die aktiven CA-Deskriptoren im PMT an. Auf Vuplus-Bildern, die Black Hole ausführen, befinden sich dieselben Daten unter Menü> Informationen> Tune-Status. Der genaue Pfad variiert je nach Skin, aber jedes moderne Enigma2-Bild zeigt dies irgendwo an.

Notieren Sie sich die genauen Hex-Werte. Gehen Sie nicht von Annahmen aus. Die Provider-ID variiert insbesondere zwischen Transpondern, die dasselbe Paket transportieren, und sie falsch zu bekommen, ist die häufigste Ursache dafür, dass ein Kanal als FTA erscheint, aber eingefroren ist.

Bestätigung der CAID mit OScam webif (Reader> Berechtigungen)

Wenn Sie das OScam webif (Standardport 8888) ausführen, gehen Sie zu Readers und klicken Sie auf Ihren aktiven Reader. Die Registerkarte Berechtigungen zeigt, was die Karte oder Zeile tatsächlich bereitstellt. Überprüfen Sie dies mit dem, was der Receiver gemeldet hat.

Das nützlichere Diagnosewerkzeug ist das Live-Protokoll. Grep das OScam-Protokoll nach ECM-Aktivität auf diesem Kanal:

grep -i ecm /var/log/oscam/oscam.log | tail -50

Oder wenn Sie oscam mit dem Protokoll, das über Ihr Init-System an stdout geht, ausführen:

journalctl -u oscam -f | grep -i "ecm\|caid\|reader"

Jede ECM-Zeile gibt Ihnen das vollständige CAID:provid:srvid-Triplett — zum Beispiel0B00:004A01:1234. Die Service-ID (srvid) ist kanal-spezifisch. Der provid ist das, was Sie im Ident-Feld Ihres Readers benötigen.ident Feld.

Warum die falsche CAID dazu führt, dass Kanäle als FTA, aber eingefroren erscheinen

Hier ist ein Szenario, das viele Menschen erwischt: Der Kanal hat eine unverschlüsselte Komponente (wie ein kostenloses Vorschaufenster oder eine andere Transponderfrequenz, die denselben Dienst FTA überträgt). Der Receiver sperrt sich darauf, der Kanal scheint zu spielen, und dann friert er ein oder pixelt, weil der Hauptstream tatsächlich verschlüsselt ist und kein CW ankommt.

Achten Sie auch auf Kanäle, die auf einem Transponder FTA und auf einem anderen, der dieselbe Service-ID trägt, verschlüsselt sind. Wenn Ihr Scan zuerst die FTA-Version erfasst hat, könnte der Receiver ECM-Anfragen an den falschen Eintrag in seiner Kanalliste weiterleiten. Das Löschen und erneute Scannen nur des verschlüsselten Transponders behebt dies normalerweise.

Wenn das Protokoll von OScam zeigt, dass die ECM-Anfrage ankommt, aber kein passender Reader gefunden wird, oder zeigt, dass der Reader sie ablehnt, ist das ein CAID- oder Identitäts-Mismatch — kein Netzwerkproblem.

OScam Reader- und ECM-Konfiguration

OScam-Konfigurationsdateien befinden sich an verschiedenen Orten, je nach Ihrem Bild. Auf OpenPLi ist es typischerweise/etc/tuxbox/config/oscam/. Bei Bildern, die das Tuxbox-Layout verwenden, könnte es sein, dass/var/config/oscam/. In einigen OpenATV-Bauten finden Sie es unter/etc/oscam/. Überprüfen Sie, auf welches Verzeichnis Ihre laufende Instanz zeigt mit:

ps aux | grep oscam

Die-c Argument in der Prozesszeile zeigt Ihnen das Konfigurationsverzeichnis an.

oscam.server Leserblock: caid, ident, gruppe

Hier ist ein sauberer Ausgangspunkt für einen Leserblock für einen Remote-Protokoll-Share — dies deckt newcamd undcccam Leser ab, passen Sie die Protokollzeile nach Bedarf an:

[reader]

Dieident Zeile ist die, die die meisten Konfigurationen falsch haben. Sie benötigt das CAID-Präfix, gefolgt von einem Doppelpunkt und der Anbieter-ID, die Sie aus dem Live-Log erfasst haben. Wenn der Anbieter mehrere aktive IDs hat, listen Sie diese kommagetrennt auf:ident = 0B00:004A01,004A02.

Diegroup Zahl muss mit der Gruppe übereinstimmen, die dem Benutzer in oscam.user zugewiesen ist — diese Gruppenabweichung ist die andere Hauptursache für "keine übereinstimmenden Leser"-Einträge, die die Leute stundenlang verfolgen.

oscam.user mit au und Gruppenbindung

Ihr Benutzerkonto inoscam.user benötigt die gleiche Gruppennummer und den richtigen CAID-Bereich:

[account]

Wenn Sie mehrere Leser in verschiedenen Gruppen haben, muss der Benutzer in der Gruppe sein, die den Leser enthält, der dieses Paket trägt. Wenn der Leser in Gruppe 1 und der Benutzer in Gruppe 2 ist, wird OScam das ECM protokollieren, als käme es an, hat aber keinen Ort, um es weiterzuleiten. Der Protokolleintrag sieht aus wie "keine übereinstimmenden Leser" oder "abgelehnt" — kein Authentifizierungsfehler, nur ein Routing-Fehler.

ECM-Timeout und lb_retry-Verhalten in oscam.conf einstellen

Öffnen Sieoscam.conf und suchen Sie den[global] Abschnitt. Die Schlüsselwerte:

[global]

Dielb_mode = 1 aktiviert das Lastenausgleich nach ECM-Antwortzeit. Das ist, was Sie wollen, wenn Sie mehrere Leser haben — es wird den schnellsten bevorzugen. Aber setzen Sielb_nbest_percaid zu hoch (3 oder 4) und es beginnt, langsam oder tot Leser unnötig abzufragen, was tatsächlich die Frequenz von Freezes während der Spitzenlast erhöht. Beginnen Sie mit 1 und erhöhen Sie es nur, wenn Sie bestätigte redundante Leser haben.

lb_retrylimit in Millisekunden sagt OScam, wann ein Reader als zu langsam betrachtet werden soll und ein anderer versucht werden soll. 800 ms sind für einen lokalen Netzwerk-Reader mit niedriger Latenz angemessen. Für entfernte Peers mit variabler RTT sollte dies auf 1200–1500 ms erhöht werden. Eine Einstellung von 200 ms bei einem entfernten Reader führt dazu, dass ständig neu versucht wird und ein Timeout auftritt.

Die per-CAID-Überschreibunglb_retrylimits = 0B00:1200 ermöglicht es Ihnen, speziell für dieses Paket zu optimieren, ohne andere zu beeinträchtigen.

Cache- und CW-Verwaltung für stabile Ausgaben

Der CW-Cache von OScam (cwcache) kann tatsächlich eine spezifische Art von Einfrieren verursachen: Der Receiver erhält einen gültigen CW, spielt gut, Sie wechseln den Kanal und kommen zurück, und es ist für ein paar Sekunden schwarz. Das ist der Cache, der einen veralteten CW aus der vorherigen Sitzung auf demselben SRVID bereitstellt. Der kryptografische Schlüssel hat gewechselt, aber der Cache ist nicht abgelaufen.

Wenn Sie dieses Muster speziell bei Kanalwechseln sehen, fügen Sie hinzuoscam.conf:

[cache]

Eine Cache-Lebensdauer von 15 Sekunden ist normalerweise sicher für standardmäßige 10-Sekunden-CW-Rotationsperioden. Höhere Werte riskieren, veraltete Schlüssel bereitzustellen.

CCcam-Konfiguration und Linienpriorität

Wenn Sie CCcam anstelle von OScam als Ihre primäre Softcam verwenden, befindet sich die Konfiguration in/etc/CCcam.cfg. Die Syntax ist anders, aber die Konzepte sind die gleichen — Sie müssen CCcam mitteilen, durch welche Verbindung welche CAID geleitet werden soll, und Sie müssen das Hop-Verhalten steuern.

CCcam.cfg C-Line- und F-Line-Grundlagen

Eine C-Line ist Ihre ausgehende Client-Verbindung zu einem Sharing-Server. Eine F-Line ist ein eingehender Peer, der sich mit Ihnen verbinden darf. Für die Dekodierung des Pakets benötigen Sie eine C-Line:

# Verbindung zu einem Sharing-Server herstellen

Port 12000 ist der Standard von CCcam und die meisten Server verwenden ihn. Wenn Sie stattdessen zu einemnewcamdServer verbinden, verwenden Sie eine N-Line mit Port 15050 (auch ein gängiger Standard). Überprüfen Sie, ob Ihre Linie tatsächlich verbunden ist, indem Sie die CCcam-Infoseite aufrufen — typischerweise unterhttp://receiver-ip:16001 — und den Abschnitt Verbundene Server überprüfen. Grün bedeutet verbunden, rot bedeutet, dass der Handshake fehlgeschlagen ist.

Verwendung von CAID/Ident-Priorität und Ignorierlinien

CCcam hat P: (Priorität) und I: (Ignorieren) Direktiven, die das Routing für spezifische CAIDs steuern. Wenn Sie mehrere C-Lines haben und eine eindeutig besser für dieses Paket ist, verwenden Sie:

# Priorisieren Sie diesen Server für CAID 0B00

Ohne diese Direktiven round-robin CCcam zwischen verbundenen Servern und Sie erhalten inkonsistente Dekodierzeiten. Während der Hauptsendezeit, wenn ein Server abnimmt, verursacht dies intermittierende Einfrierungen, die zufällig erscheinen, aber tatsächlich lastbedingt sind.

Einen bestimmten Reader-Hop für das Paket erzwingen

Die Hop-Anzahl ist entscheidend für die Dekodierzuverlässigkeit. Ein Hop-1-Reader bedeutet, dass die Karte direkt mit dem Server verbunden ist, mit dem Sie sprechen. Hop-2 bedeutet einen Relay zwischen Ihnen und der Karte. In meinen Tests sind Hop-1 und Hop-2 im Allgemeinen gut für stabiles Dekodieren. Hop-3 und höher führt zu Latenzvariationen, die sich als Einfrierungen während schneller ECM-Rotationen zeigen.

CCcam zeigt Hop-Informationen auf seiner Statusseite an. Unter Verbundene Karten sehen Sie die Hop-Anzahl für jeden CAID-Eintrag. Wenn das Paket Hop-4 oder höher anzeigt, erhält dieser Server seine Karte nicht direkt — es wird über mehrere Knoten weitergeleitet. Entweder finden Sie eine bessere Quelle oder akzeptieren die Instabilität.

Sie können auch einschränken, welche Hops CCcam verwenden wird:

ALLOW SIDMAPPING = no

DieIGNORE RESHARE DISTANCEEinstellung sagt CCcam, CWs abzulehnen, die von mehr als N Hops entfernt ankommen. Eine Einstellung von 2 filtert hoch-hoppenden Müll heraus, auf Kosten der Reduzierung Ihrer Fallback-Optionen.

Fehlerbehebung bei Einfrierungen, schwarzen Bildschirmen und ECM-Fehlern

Bevor Sie die Softcam beschuldigen, schließen Sie immer zuerst das Signal aus. Schalten Sie auf einen Free-to-Air-Kanal auf demselben Transponder. Wenn dieser auch pixelig oder abbricht, liegt Ihr Problem am LNB/Satellitenschüssel, nicht an der Konfiguration. Beginnen Sie erst mit der Fehlersuche in der Softcam, wenn Sie bestätigt haben, dass der Transponder gesperrt ist und die FTA-Kanäle sauber sind.

ECM-Antwortzeiten im Protokoll lesen

OScam protokolliert ECM-Antwortzeiten in Millisekunden auf jeder CW-Zeile. Ein gesundes Dekodieren sieht so aus:

2026/06/03 21:14:02 c [SRVID 1234] ECM antwortete (0B00/004A01) von focus_peer1 (220ms)

Unter 400ms ist solide. 400–1000ms ist grenzwertig, aber normalerweise in Ordnung für eine 10-sekündige CW-Rotation. Alles, was wiederholt 3000ms+ erreicht, bedeutet, dass der Leser Schwierigkeiten hat. Wenn Sie 9000ms gefolgt von einem Timeout sehen, hat der Leser aufgegeben — das ist Ihr Freeze direkt dort.

Das Muster, auf das man achten sollte, ist CW gefunden, aber verspätet angekommen. Der Kanal scheint zu spielen, stockt jedoch jedes Mal, wenn der Schlüssel rotiert. OScam fand das CW, aber es dauerte 2800ms in einem 2500ms Fenster. Die Lösung ist entweder eine schnellere Leserquelle oder ein höherer ecmtimeout, um langsamen Lesern mehr Zeit zu geben.

Behebung wiederkehrender 'kein passender Leser' / 'abgelehnt' Einträge

Wenn das Protokoll konstant "kein passender Leser" für ein bestimmtes CAID:provid-Paar anzeigt, arbeiten Sie dies der Reihe nach ab:

1. Überprüfen Sie, ob der Leserblock in oscam.server die korrektencaid undident Werte hat, die mit dem übereinstimmen, was Sie live erfasst haben
2. Überprüfen Sie, ob diegroup Nummer des Lesers mit dergroup des Benutzers in oscam.user übereinstimmt
3. Bestätigen Sie, dass der Leser tatsächlich verbunden ist — überprüfen Sie die Webif-Seite der Leser auf den Status "verbunden"
4. Wenn Sie cacheex verwenden, überprüfen Sie, ob der Cache eine Ablehnung von einem vorherigen fehlgeschlagenen Versuch bedient

"Abgelehnt" ist anders — es bedeutet normalerweise, dass der Leser verbunden war, aber die Karte oder der Server aktiv das ECM abgelehnt hat. Dies geschieht, wenn Sie ECM-Anfragen für ein CAID senden, das der Server nicht führt, oder wenn der Identfilter am entfernten Ende Ihre Anfrage blockiert.

Netzwerk- und MTU-Probleme über entfernte Peers

Das ist leicht zu übersehen. Wenn Ihre Freezes speziell bei HD-Streams und speziell bei entfernten Peers (nicht lokalen Netzwerklesern) auftreten, ist MTU-Fragmentierung ein starker Kandidat. HD-Streams haben größere ECM-Nutzlasten, und eine entfernte Verbindung mit MTU, die auf 1500 eingestellt ist, aber über PPPoE oder einen VPN-Tunnel mit niedrigerem effektivem MTU geht, fragmentiert diese Pakete. Fragmentierte CW-Pakete kommen oft unvollständig an, was ein Timeout auslöst.

Testen Sie es:ping -M do -s 1472 your.peer.server. Wenn Sie "Fragmentierung erforderlich" Fehler sehen, senken Sie Ihre MTU. Unter Linux setzen Sie es auf der Schnittstelle:

ip link set eth0 mtu 1400

Oder setzen Sie es dauerhaft in Ihrer Netzwerkkonfiguration. 1400 gibt genug Spielraum für die meisten Tunnel-Overheads. Nach der Änderung starten Sie oscam neu und beobachten, ob die HD-only Freezes verschwinden.

Unterscheidung von Signal/LNB-Problemen und Softcam-Problemen

Ein schneller Entscheidungsbaum:

• FTA-Kanäle auf demselben Transponder frieren ein → Signal/LNB-Problem. Hier stoppen, Ihre Schüssel reparieren.
• FTA in Ordnung, verschlüsselte Kanäle sofort schwarzer Bildschirm → Softcam verbindet sich nicht, wahrscheinlich CAID-Mismatch oder Leser nicht verbunden.
• Spielt 10–30 Sekunden und friert dann ein → CW-Rotations-Timeout. ECM ist langsam oder schlägt bei der Schlüsselrotation fehl.
• Friert nur während der Hauptsendezeit ein → Quellserver überlastet. In der Nebensaison ist es in Ordnung. Überprüfen Sie die ECM-Zeiten während beider Zeiträume.
• Funktioniert nach dem Neustart, bricht nach Kanalwechseln ab → veralteter CW-Cache. Siehe die cwcachetime-Behebung oben.

Der eigene ECM-Cache des Receivers kann auch Probleme vorübergehend maskieren. Einige STBs speichern das letzte gültige CW für einige Sekunden, nachdem es abgelaufen ist. Dies lässt eine fehlerhafte Konfiguration direkt nach einem Neustart funktionieren, dann 10–15 Sekunden später fehlschlagen, sobald der zwischengespeicherte Schlüssel abläuft und ein frisches ECM benötigt wird.

Wählen einer zuverlässigen Sharing-Quelle (generische Kriterien)

Wenn Sie eine Quelle für das Focus-Sat-Paket — oder ein beliebiges Paket — bewerten, sind die technischen Indikatoren wichtiger als alles andere. Eine schnelle ECM-Antwort um 2 Uhr morgens bedeutet nichts, wenn der Server um 20 Uhr zusammenbricht, wenn die Hälfte seiner Abonnenten gleichzeitig online ist.

Uptime- und Stabilitätsindikatoren, die getestet werden müssen

Führen Sie Ihren OScam-Reader mindestens 24 Stunden lang aus, bevor Sie zu dem Schluss kommen, dass eine Quelle stabil ist. Achten Sie auf die ECM-Antwortzeiten zu diesen bestimmten Zeitfenstern: 7–9 Uhr, 12–14 Uhr, 18–22 Uhr. Das Abendfenster ist der Zeitpunkt, an dem überlastete Quellen ihre tatsächliche Leistung zeigen. Wenn Sie sehen, dass die ECM-Zeiten von 180 ms in der Nebensaison auf 2400 ms zur Hauptzeit springen, wird diese Quelle Ihnen bei den wichtigsten Momenten Einfrieren verursachen.

OScam protokolliert alles. Nach einem Tag Laufzeit führen Sie aus:

grep "focus_peer1" /var/log/oscam/oscam.log | grep -v "not found" | awk '{print $NF}' | sort -n

Das gibt Ihnen eine grobe Verteilung der Antwortzeiten für diesen Reader. Wenn der 95. Perzentil unter 800 ms liegt, sind Sie in guter Verfassung. Wenn er über 2000 ms liegt, erwarten Sie Einfrieren.

Hop-Zahl und lokale vs. entfernte Kartenbegründung

Eine Quelle mit direktem Kartenzugriff (Hop-1 in CCcam-Begriffen) wird immer eine Reshare-Kette unter Last übertreffen. Der Grund ist einfach: Jeder Hop fügt seine eigene Verarbeitungsverzögerung hinzu und führt einen weiteren potenziellen Ausfallpunkt ein. Während der Spitzenlast könnte eine Hop-3-Kette auf zwei Zwischenknoten warten, um zu verarbeiten, bevor Ihr CW ankommt.

Wenn Sie die Möglichkeit haben, wird eine Quelle, bei der der Betreiber die Karte physisch hält und der Server mit ihr co-located ist, konstant besser abschneiden als ein Reshare. Die RTT von Ihrem Empfänger zur Karte bestimmt die ECM-Zeit, und jeder Hop in der Kette trägt dazu bei.

Ein legitimes Setup bedeutet, dass Sie oder Ihre Quelle Anspruch auf die geteilte Karte haben. Behalten Sie das im Hinterkopf, wenn Sie Optionen bewerten – die Verwendung einer Karte, auf die Sie keinen Anspruch haben, ist sowohl ein rechtliches Risiko als auch ein technisches, da Betreiber Sharing-Muster erkennen und die Karte ohne Vorankündigung ungültig machen können.

Warnsignale, die Einfrieren vorhersagen

Gehen Sie von jeder Quelle weg, die diese zeigt:

• ECM-Antwortzeiten, die wild variieren – 150 ms eine Minute, 4000 ms die nächste – deuten auf eine überlastete oder flackernde Verbindung hin
• Hop-Zahl von 3 oder höher im CCcam-Status
• Häufige Wiederverbindungen, die im OScam-Protokoll sichtbar sind (mehr als einmal pro Stunde unter normalen Bedingungen)
• Keine Antwort auf die spezifische CAID/provid-Kombination, die Sie benötigen – der Server teilt Karten, die Ihr Paket nicht abdecken
• Leistung, die eine Stunde stabil ist und dann abnimmt – deutet auf eine Bandbreitenbeschränkung oder ein Sitzungsdrosselung hin

Und ein Randfall, den es wert ist zu wissen: Betreiber rotieren regelmäßig die Anbieter-IDs für Focus Sat und andere Pakete auf Hot Bird. Wenn eine Konfiguration, die monatelang gut funktioniert hat, plötzlich "no matching reader" protokolliert, ohne dass sich an Ihrer Seite etwas geändert hat, überprüfen Sie die aktuellen CAID/provid-Werte erneut. Ihre Identzeile könnte jetzt auf eine veraltete Anbieter-ID zeigen, die der Betreiber zurückgezogen hat.