Tricolor Card Sharing Einrichtung: CCcam& OScam Anleitung

Tricolor-Kanäle über einen Card Sharing-Server zu empfangen, ist ein einfacher Prozess, sobald Sie verstehen, was jeder Konfigurationsparameter tatsächlich tut. Aber die meisten Anleitungen fügen einfach eine C-Line ein und sind fertig, was Sie im Stich lässt, sobald etwas nicht funktioniert. Diese Anleitung behandelt die vollständigeTricolor Card Sharing Einrichtung (CCcam/OScam) — echte Konfigurationsdateipfade, korrekte CAID/Ident-Werte, funktionierende Blocksyntax und einen Diagnosepfad für den Fall, dass Kanäle schwarz bleiben oder einfrieren. Ich werde auch die Randfälle behandeln, die andere Anleitungen völlig überspringen.

Tricolor im Card Sharing: Was Sie brauchen, bevor Sie beginnen

Bevor Sie eine Konfigurationsdatei bearbeiten, müssen Sie das Verschlüsselungssystem verstehen, die richtige Hardware haben und tatsächlich in der Lage sein, die Serverzeile zu lesen, die Ihnen gegeben wurde. Wenn Sie einen dieser Schritte überspringen, verbringen Sie am Ende zwei Stunden mit der Fehlersuche bei einem Problem, das nie mit der Konfiguration zu tun hatte.

Verschlüsselungssystem und CAID, die von Tricolor verwendet werden

Tricolor TV sendet vonEutelsat 36E (36.0° Ost) und verwendetDRE Crypt Verschlüsselung — manchmal als DGCrypt geschrieben. Die primäre CAID ist0x4AE1. Einige Pakete oder Transponder können auf0x4AE5 verweisen. Das ist wichtig, weil jede Zeile, die Sie von einer Card Sharing-Quelle erhalten, nur für die CAIDs gültig ist, die die Karte dieser Quelle tatsächlich hält. Eine Zeile, die auf einer anderen CAID basiert, wird keine ECMs von Ihrer Box anfordern oder wird sie anfordern und nichts zurückbekommen.

Um die aktive CAID auf Ihrer Enigma2-Box zu bestätigen, stimmen Sie auf einen Tricolor-Transponder ein, öffnen Sie das Dienstinformationsfeld (normalerweise durch langes Drücken von Info) und überprüfen Sie das CA-Beschreibungsfeld. Sie sollten sehen4AE1 aufgeführt. Wenn nicht, sind Sie entweder auf der falschen Satellitenposition oder der Transponder ist nicht verschlüsselt.

Die Identifikation (Provider-ID) für Standard-DRE-Crypt-Zeilen ist typischerweise4AE1:000000. Sie benötigen diesen genauen Wert in OScam-Leser- und Benutzerblöcken.

Hardware- und OS-Voraussetzungen

Sie benötigen einenDVB-S2-Tuner, der auf Eutelsat 36E eingestellt ist. Klingt offensichtlich, aber eine Box, die auf 13E oder 19.2E ausgerichtet ist, wird den verschlüsselten Transponder niemals empfangen, egal wie perfekt Ihre CCcam-Konfiguration ist. Überprüfen Sie mit einem Signalmeter: ein sauberer Empfang bei 36.0E mit>70% Qualität auf einem Tricolor-Bestrahlungs-Transponder ist die Basislinie.

Für das Betriebssystem benötigen Sie Enigma2 (OpenATV, OpenPLi, OpenVision usw.) oder einen beliebigen Linux-basierten Receiver mit Softcam-Unterstützung. CCcam und OScam laufen beide als Daemons auf diesen Plattformen. SSH- oder Telnet-Zugriff auf die Box ist unverzichtbar — Sie werden Konfigurationen bearbeiten und Protokolle über die Befehlszeile lesen.

Ihre Box benötigt auch eine funktionierende Internetverbindung. Testen Sie mitping 8.8.8.8 bevor Sie etwas anderes tun. Der Card Sharing-Verkehr hat eine niedrige Bandbreite, ist aber latenzempfindlich, sodass eine instabile Verbindung ständiges Einfrieren verursacht, selbst mit einer perfekten Konfiguration.

CCcam vs OScam für diesen Anbieter wählen

CCcam ist einfacher einzufügen: eine Konfigurationsdatei, Ihre C-Line einfügen, den Daemon neu starten, fertig. OScam erfordert mehr Dateien und mehr Wissen, bietet Ihnen jedoch eine granulare CAID/Ident-Kontrolle, viel bessere Protokollierung und viel einfachere Fehlersuche.

Meine Empfehlung: Verwenden Sie OScam, insbesondere wenn Sie Einfrier- oder Dekodierungsfehler diagnostizieren. Die Protokollausgabe von OScam sagt Ihnen genau, was passiert — ob eine ECM angefordert wurde, welcher Leser sie bearbeitet hat, wie viele Millisekunden es gedauert hat und warum es fehlgeschlagen ist. CCcam gibt Ihnen fast nichts davon. Für DRE Crypt, wo CAID/Ident-Mismatches eine häufige Quelle für schwarze Bildschirme sind, ist die Sichtbarkeit von OScam die zusätzliche Einrichtungszeit wert.

So lesen Sie eine Serverzeile, die Ihnen gegeben wurde

Eine CCcam C-Line sieht so aus:C: hostname port benutzername passwort. Der Hostname ist die Serveradresse, der Port ist typischerweise 12000, und die Anmeldedaten sind spezifisch für Ihr Konto. Eine N-Zeile (newcamd-Format) fügt am Ende einen 14-Byte-DES-Schlüssel hinzu:N: hostname port benutzername passwort 01 02 03 04 05 06 07 08 09 10 11 12 13 14.

Wenn Ihnen eine Zeile gegeben wurde und keine der Felder Sinn macht, sehen Sie entweder die OScam-Leserblock-Syntax (ganz anderes Format) oder einen beschädigten Eintrag. Raten Sie nicht. Fragen Sie denjenigen, der Ihnen die Zeile gegeben hat, um das Format zu bestätigen, bevor Sie Zeit mit dem Debuggen eines Tippfehlers verbringen.

CCcam für Tricolor konfigurieren

Die Konfiguration von CCcam befindet sich unter/usr/keys/CCcam.cfg auf den meisten Enigma2-Images. Einige ältere Builds verwenden/etc/CCcam.cfg oder/var/etc/CCcam.cfg. Überprüfen Sie, welchen Pfad Ihr Image verwendet mitfind / -name CCcam.cfg 2>/dev/null bevor Sie Änderungen vornehmen.

CCcam.cfg bearbeiten und das C-Zeilenformat

Das C-Zeilenformat ist einfach:

C: server.example.com 12000 meinbenutzername meinpasswort

Optionale Flags in der C-Zeile umfassen ein Hop-Limit und eine Block-Server-Direktive, aber für eine grundlegende Tricolor-Zeile benötigen Sie diese nicht. Fügen Sie die Zeile genau so ein, wie sie gegeben wurde, eine Zeile pro Serververbindung.

Sie können einen Debug-Log-Pfad hinzufügen:

LOGGER DATEINAME : /tmp/CCcam.log

Level 1 reicht aus, um Verbindungsereignisse zu sehen. Level 12 erzeugt eine Wand aus Lärm — verwenden Sie es nicht in der Produktion.

Den Listenport und die Verbindungsoptionen festlegen

Wenn Ihre Box als CCcam-Server fungiert (eine lokale Karte an andere Clients teilt), setzen Sie den Listenport:

SERVER LISTEN PORT : 12000

Wenn Sie nur ein Client sind — sich mit der Karte eines anderen zu verbinden — benötigen Sie dies nicht. Der Port muss nur auf Ihrem Router geöffnet/weitergeleitet werden, wenn eingehende Verbindungen erwartet werden.

Für Verbindungsresilienz fügen Sie hinzu:

RECONNECT ON TIMEOUT : ja

DES-Schlüssel / N-Zeilenfälle und wann sie gelten

Die meisten modernen DRE Crypt-Zeilen verwenden das CCcam C-Zeilenprotokoll, das verbindungsbasiert ist und keinen DES-Schlüssel benötigt. Wenn Sie jedoch stattdessen eine Verbindung zu einem newcamd-Server herstellen, verwenden Sie eine N-Zeile mit diesem 14-Byte-Schlüssel. Der Schlüssel sieht aus wie eine Sequenz von Hex-Paaren:01 02 03 04 05 06 07 08 09 10 11 12 13 14. Diese müssen genau dem entsprechen, was der Server erwartet. Ein einzelnes falsches Byte bedeutet einen stillen Authentifizierungsfehler — keine Fehlermeldung, einfach keine verarbeiteten ECMs.

Wenn Sie sich nicht sicher sind, welches Protokoll Sie benötigen, fragen Sie die Quelle. CCcam C-Zeilen sind für diesen Anbieter häufiger.

Den Daemon neu starten und die Verbindung bestätigen

Nach der Bearbeitung starten Sie CCcam neu:

killall -9 CCcam&& sleep 2&& /etc/init.d/softcam restart

Oder auf Images mit Softcam-Manager:

/etc/init.d/softcam neu starten

Geben Sie ihm 10–15 Sekunden, überprüfen Sie dann die Web-Infoseite unterhttp://<box-ip>:16001. Eine verbundene Zeile zeigt ihre aktiven Karten und die Hop-Zahl an. Hop 1 bedeutet eine direkte Karte; Hop 2 bedeutet, dass Ihr Server sie von einem anderen Server erhalten hat. Wenn die Karte angezeigt wird, die Tricolor-Kanäle jedoch weiterhin schwarz sind, stimmt die CAID nicht überein — was OScam viel besser handhabt.

OScam für Tricolor konfigurieren

Die Konfigurationsdateien von OScam befinden sich in einem von drei Pfaden, abhängig von Ihrem Image:/etc/tuxbox/config/,/var/etc/oscam/, oder/etc/oscam/. Die Dateien, mit denen Sie arbeiten werden, sindoscam.conf,oscam.server,oscam.user, und optionaloscam.dvbapi. Jede Datei behandelt ein bestimmtes Stück des Systems.

oscam.server Reader-Block für einen CCcam-Protokoll-Peer

Dies ist der Block, der Ihre Verbindung zur Kartenfreigabequelle definiert:

[reader]

DascccversionFeld muss mit dem übereinstimmen, was der entfernte CCcam-Server erwartet. Versionskonflikte führen zu einem stillen Handshake-Fehler — die Verbindung scheint abgeschlossen zu sein, aber keine ECMs werden jemals beantwortet. Wenn Sie wissen, dass der Server CCcam 2.1.4 verwendet, setzen Siecccversion = 2.1.4. Im Zweifelsfall funktioniert 2.3.0 mit den meisten modernen Implementierungen.

Dasinactivitytimeoutvon 30 Sekunden löst eine Wiederverbindung aus, wenn kein ECM-Verkehr fließt. Das ist in Ordnung für aktives Ansehen. Setzen Sie es höher (120–300), wenn Sie unnötige Wiederverbindungs-Schleifen bei Kanälen sehen, die Sie kontinuierlich ansehen.

oscam.user und Kontoeinrichtung

Wenn OScam auch lokale Enigma2-Clients über dvbapi bedient, benötigen Sie ein Benutzerkonto. Inoscam.user:

[account]

Einschränkung des Kontos auf CAID4AE1 und ident4AE1:000000 verhindert, dass dieses Konto ECMs für Verschlüsselungssysteme anfordert, mit denen es nichts zu tun hat. Hält die Protokolle sauber und beschleunigt die Fehlersuche.

oscam.conf Webif, Ports und globale Einstellungen

Die Hauptkonfiguration inoscam.conf:

[global]

Das Webif ist Ihre primäre Diagnoseschnittstelle. Greifen Sie darauf zu unterhttp://<box-ip>:8888. Der Live-Log-Tab zeigt die ECM-Dekodierungsaktivität in Echtzeit. Der Readers-Tab zeigt den Verbindungsstatus für jeden Eintrag in oscam.server. Beschränken Siehttpallowed auf Ihren LAN-Bereich.

Eine Sache, die viele Leute beißt: Wenn die Uhrzeit der Box falsch ist, kann die Keepalive- und TLS-nahe Handshake-Logik von OScam stillschweigend brechen. Leser erscheinen verbunden, aber ECMs laufen ab. Führen Siedate auf der Box aus und überprüfen Sie, ob sie mit UTC übereinstimmt. Fügen Sie bei Bedarf eine NTP-Synchronisation zu Ihren Startskripten hinzu.

Mapping der Tricolor CAID und Provider-IDs

Inoscam.dvbapi (wenn Sie dvbapi für die Enigma2-Integration verwenden):

[dvbapi]

DieP: Zeile legt die Priorität fest — OScam verwendet den Leser, der zur CAID4AE1 und ident000000 passt, zuerst. Wenn Sie sowohl eine lokale Karte als auch einen entfernten Leser haben, die beide diese CAID beanspruchen, bestimmt diese Datei, welcher die ECM-Anfrage erhält. Ohne eine explizite Priorität trifft OScam eine eigene Wahl, die oft die falsche ist, wenn auch eine lokale Karte vorhanden ist.

Lesen des OScam-Logs zur Bestätigung der ECM-Dekodierung

Überwachen Sie das Protokoll live:

tail -f /tmp/.oscam/oscam.log

Eine funktionierende ECM-Dekodierung sieht so aus:

2026/06/24 14:23:01 s ECM 4AE1/000000 von tricolor_reader (125 ms)

Diese 125 ms-Zahl ist Ihre Hin- und Rücklaufzeit für ECM. Unter 300 ms ist für die meisten Inhalte in Ordnung. Über 600 ms führt zu sichtbarem Einfrieren. Über 1000 ms werden die Kanäle unanschaubar. Wenn SieECM nicht gefunden stattdessen sehen, hat der Leser die Verbindung, aber die entfernte Karte hält dieses Paket nicht — CAID-Mismatch oder Paketberechtigungsproblem.

Fehlerbehebung bei schwarzen Bildschirmen, Einfrieren und keiner Dekodierung

Der schnellste Weg, ein Problem zu diagnostizieren, besteht darin, Ihr Symptom einer Ursache zuzuordnen. Hier ist die Tabelle, mit der ich arbeite:

Kanal bleibt schwarz: ECM nicht gefunden vs. nicht angefordert

Dies sind zwei verschiedene Probleme. Wenn keine ECM-Anfrage im Protokoll erscheint, wenn Sie zu einem Tricolor-Kanal umschalten, sendet die Box die Anfrage überhaupt nicht. Überprüfen Sie, ob dvbapi aktiviert ist, ob der CAID-Filter nicht blockiert4AE1und ob Sie auf die richtige Satellitenposition eingestellt sind (36E, nicht 19.2E oder 13E).

Wenn das Protokoll ECM-Anfragen zeigt, diese aber "nicht gefunden" zurückgeben, hält die upstream-Karte dieses Paket nicht. Es hat nichts mit Ihrer Konfiguration zu tun — die Quelle hat es einfach nicht. Überprüfen Sie, ob Ihre Linie das spezifische Tricolor-Paket abdeckt, das Sie ansehen möchten.

Bild friert alle paar Sekunden ein

Einfrieren, das mit dem ECM-Intervall übereinstimmt (alle 8–12 Sekunden ist typisch für DRE Crypt), bedeutet fast immer, dass die Dekodierung zu langsam erfolgt. Beobachten Sie die ms-Zahl im OScam-Protokoll einige Minuten lang. Wenn Sie konstant 800 ms+ sehen, liegt das Problem an der Netzwerk-Latenz zum Server. Ein geografisch näherer Server wird dies schneller beheben als jede Konfigurationsänderung.

Wenn die Latenz in Ordnung aussieht, Sie aber trotzdem einfrieren, überprüfen Sie die ECM-Caching-Einstellungen in oscam.conf:

[cache]

Das Aktivieren des Caches bedeutet, dass ein wiederholtes ECM vom selben Kanal aus dem Speicher beantwortet wird, anstatt erneut über das Netzwerk zu gehen. Reduziert die Einfrierhäufigkeit erheblich bei stabilen Linien.

Verbindungsabbrüche und Wiederverbindungsloops

Wenn das Protokoll wiederholte Verbindungs-/Trennzyklen alle 30–60 Sekunden zeigt, wird dasinactivitytimeoutauf einem Kanal ausgelöst, den Sie nicht aktiv ansehen. Erhöhen Sie es auf 120 oder 300. Wenn die Wiederverbindungen während des Ansehens auftreten, haben Sie ein Netzwerkproblem — Paketverlust, NAT-Timeout oder einen überlasteten Server.

Die Uhrzeitsynchronisation der Box ist hier ein weiterer stiller Killer. Wenn/etc/localtimeum mehr als eine oder zwei Minuten falsch ist, interpretiert eine serverseitige Handshake-Logik die Zeitstempel als ungültig und trennt die Verbindung. Eine falsche Uhr, die dies verursacht, ist frustrierend zu diagnostizieren, da der Fehler nicht im OScam-Protokoll erscheint.

Falsche CAID-Priorität und konkurrierende Reader

Dieses Problem betrifft Personen mit einer lokalen Karte und einer Remote-Linie, die beide denselben CAID abdecken. OScam wählt den Reader basierend auf den Prioritätsregeln, und wenn diese Regeln nicht explizit festgelegt sind, könnte es konsequent die Remote-Linie (die langsamer ist) der lokalen Karte vorziehen. Schlimmer noch, wenn die Remote-Linie den CAID in ihrem Profil hat, die Remote-Karte jedoch nicht das spezifische Tricolor-Paket hat, erhalten Sie "ECM nicht gefunden", während Ihre lokale Karte untätig bleibt.

Setpreferlocalcards = 1 in[global] und verwenden Sie explizite Priorität inoscam.dvbapi. Wenn Sie die Remote-Leitung als primär und die lokale Karte als Fallback möchten, kehren Sie die Lesergruppennummern um und konfigurieren Sie die dvbapi-Priorität entsprechend.

Firewall-, NAT- und Port-Forwarding-Fallen

Die meisten Heimbenutzer sind CCcam-Kunden — ihre Box verbindet sich outbound mit einem Server. Outbound-Verbindungen erfordern kein Port-Forwarding. Aber wenn Ihre Box der Server ist und ein anderes Gerät inbound verbindet, muss Port 12000 (oder was auch immer Sie konfiguriert haben) durch Ihren Router zur LAN-IP der Box weitergeleitet werden.

Das größere Problem ist ISP CGNAT. Wenn Ihr ISP Ihnen eine gemeinsame öffentliche IP zuweist (häufig bei Mobilfunkanbietern und einigen Glasfaser-ISPs), sind inbound-Verbindungen ohne ein VPN-Tunnel oder einen Relay-Dienst unmöglich. Überprüfen Sie, obtraceroute zu Ihrer öffentlichen IP mehr als einen Hop von privaten RFC1918-Adressen zeigt — das ist CGNAT. Outbound-only Client-Setups funktionieren gut hinter CGNAT. Inbound-Server-Setups tun dies nicht, Punkt.

Wie man eine Sharing-Quelle bewertet, ohne verbrannt zu werden

Die technische Konfiguration ist nur die halbe Miete. Ein perfektes OScam-Setup, das mit einer Müllquelle verbunden ist, wird immer noch schwarze Bildschirme und Freezes produzieren. Hier ist, worauf Sie achten sollten, bevor Sie sich für eine Linie für dasTricolor-Karten-Sharing-Setup (CCcam/OScam) entscheiden, das Sie betreiben.

Allgemeine Kriterien: Uptime, ECM-Zeit, Serverstandort, Hop-Zahl

Die ECM-Zeit ist das objektivste Qualitätsmaß. Unter 200 ms ist ausgezeichnet. 200–400 ms ist akzeptabel. Über 600 ms verursacht sichtbare Probleme. Lassen Sie einen Kanal eine Stunde lang laufen und beobachten Sie die ms-Werte in Ihrem OScam-Log — überprüfen Sie es nicht nur 30 Sekunden lang.

Der Serverstandort ist wichtig wegen der physischen Latenz. Ein Server in Osteuropa hat niedrigere Round-Trip-Zeiten zu einer Box in Russland oder den GUS-Ländern als ein Server in Nordamerika. Geografie schlägt Bandbreite immer beim Kartensharing.

Hop-Zahl: Hop 1 bedeutet, dass die eigene Karte des Servers Ihre ECMs beantwortet. Hop 2 bedeutet, dass sie sie von einem anderen Server erhält. Jeder Hop fügt Latenz und einen potenziellen Ausfallpunkt hinzu. Bevorzugen Sie Hop 1-Quellen. Alles über Hop 2 ist ein Warnsignal.

Warnsignale in Angeboten und Linien

Wenn eine Linie behauptet, jedes Satellitenpaket über mehrere Anbieter zu einem unrealistisch niedrigen Preis abzudecken, seien Sie skeptisch. Eine einzelne Karte deckt nur die Pakete ab, für die diese Karte tatsächlich abonniert ist. Eine Linie, die Tricolor Full HD verspricht, plus mehrere andere große Anbieter, plus kostenlose Updates, wird entweder von Dutzenden von Benutzern geteilt (was die ECM-Zeit unter Last zerstört) oder ist einfach betrügerisch.

Achten Sie auch auf: keine Testphase angeboten, Weigerung, den Serverstandort/die Region zu teilen, und Linien, die von Ihnen verlangen, ungewöhnliche Ports zu konfigurieren oder Skripte auszuführen, die Sie nicht geschrieben haben. Legitime Quellen lassen Sie vor der Zahlung testen und verlangen nicht, dass Sie unbekannten Code ausführen.

Eine Linie testen, bevor Sie sich darauf verlassen

Richten Sie die Linie in OScam als einzelnen Leser ein. Öffnen Sie das Protokoll mittail -f /tmp/.oscam/oscam.log. Schalten Sie auf fünf verschiedene Tricolor-Kanäle über verschiedene Transponder. Zeichnen Sie die ECM-Dekodierzeit für jeden auf. Lassen Sie dann einen Kanal 60 Minuten lang laufen und zählen Sie, wie viele Wiederverbindungsereignisse im Protokoll erscheinen.

Führen Sie einen Channel-Zap-Stresstest durch: Blättern Sie schnell durch 10 Kanäle. Jeder Zap löst eine neue ECM-Anfrage aus. Wenn Sie konsistente Dekodierungen unter 400 ms über alle Kanäle hinweg erhalten, ist die Linie solide. Wenn Sie 3-Sekunden-Freezes bei jedem Kanalwechsel sehen, ist der Server überlastet oder geografisch ungeeignet.

Eine Testsitzung ist nicht genug. Anbieter drosseln manchmal unbekannte IPs während der Evaluierungsphasen. Führen Sie den Test zu verschiedenen Tageszeiten durch, einschließlich der Abendspitzenzeiten, wenn der Server unter maximaler Last steht.

Richtig gemacht, dauert der gesamteTricolor-Karten-Sharing-Setup (CCcam/OScam) Prozess — von der Hardwareüberprüfung über die Konfiguration bis zur Linienbewertung — beim ersten Mal ein paar Stunden. Danach reduzieren sich die meisten Probleme auf drei Dinge: falsche CAID/Identifikation, hohe ECM-Latenz oder eine Quelle, die einfach nicht das Paket hat, das Sie benötigen. Das OScam-Log sagt Ihnen innerhalb von Sekunden, welches es ist.