CCcam-Alternativen: OScam, mgcamd& Mehr Verglichen

Wenn Sie das lesen, friert Ihr CCcam-Server wahrscheinlich bei Kanalwechseln ein, hat Zeitüberschreitungen bei ECMs während der Hauptsendezeit oder Sie sind einfach müde davon, eine Closed-Source-Binärdatei zu betreuen, die seit Jahren kein echtes Update mehr gesehen hat. Es ist nicht falsch, woanders zu suchen. Dieser Artikel behandelt die tatsächlichen Alternativen zur CCcam-Setup, die es gerade gibt — OScam, mgcamd, NCam — was jede von ihnen anders im Hintergrund macht und wie Sie Ihre bestehende Konfiguration übertragen können, ohne alles am ersten Tag zu brechen.

Ich habe alle drei auf Enigma2-Boxen und ein paar kopflose Linux-Server über die Jahre betrieben. Keine von ihnen ist perfekt, aber die Unterschiede sind wichtig, je nachdem, ob Sie einen Reader, einen Client oder beides betreiben. Lassen Sie uns darauf eingehen.

Warum über CCcam hinausblicken?

CCcam 2.3.0 — die letzte Version, die die meisten Leute tatsächlich verwenden — ist Closed-Source. Es gibt kein öffentliches Repository, keine Commit-Historie zur Überprüfung und keine Community, die Fehler behebt, wenn sie auftreten. Die Entwicklung ist vor Jahren praktisch zum Stillstand gekommen. Wenn ein neues CAS-Update etwas im Handling Ihres Anbieters kaputt macht, warten Sie. Es gibt keine andere Option, da niemand außerhalb des ursprünglichen Autors den Quellcode hat.

Diese geschlossene Natur beißt am stärksten bei der ECM-Verarbeitung. CCcam verarbeitet Kartenanfragen auf eine Weise, die nicht gut skalierbar ist, wenn ein Peer oder Reader beschäftigt ist — Sie werden Kanalwechsel erleben, die mehrere Sekunden oder länger dauern, auf Servern mit vielen gleichzeitigen Clients. Es ist nicht mehrfädig, wie es moderne Alternativen sind, sodass ein langsamer Reader alles downstream davon verlangsamen kann.

Es gibt Ihnen auch keine feinkörnige Kontrolle über lokale Hardware. Wenn Sie einen Smargo- oder Phoenix-Reader an einen USB-Port angeschlossen haben und möchten, dass CCcam direkt mit ihm kommuniziert und das Protokoll richtig verarbeitet, sind Sie aufgeschmissen. CCcam wurde hauptsächlich als Netzwerk-Sharing-Client/Server entwickelt, nicht als Plattform zur Verwaltung von Lesegeräten.

Das Closed-Source-, Stillstand-Entwicklungsproblem von CCcam

Kein öffentlicher Quellcode bedeutet keine Möglichkeit, zu überprüfen, was tatsächlich im Inneren der Binärdatei passiert, und keinen Weg für die Community, Dinge zu beheben, wenn ein Satellitenbetreiber sein CAS-Handling ändert. Sie sind vollständig von Binärdateien abhängig, die vor Jahren kompiliert wurden und immer noch korrekt mit aktuellen ECM-Formaten funktionieren. Bisher tun sie das größtenteils — aber "größtenteils" ist keine großartige langfristige Wette.

Wo CCcam immer noch funktioniert (und warum die Leute es behalten)

Ich werde ehrlich sein — wenn Sie nur einen dummen Client benötigen, der sich mit ein oder zwei CCcam-Protokollleitungen verbindet und entschlüsselte Kanäle ausgibt, macht CCcam diesen Job immer noch gut. Die Konfiguration ist eine einzige flache Datei, sie ist leicht im RAM und es gibt nichts zu optimieren. Für eine Box, die einfach nur dasitzt und eine Leitung empfängt und keine lokalen Reader berührt, ist es nicht immer den Aufwand wert, sie herauszureißen.

Signale, dass es Zeit ist zu migrieren: Einfrieren, ECM-Zeitüberschreitungen, keine Flexibilität bei lokalen Lesern

Achten Sie speziell auf diese drei Dinge. Erstens, wiederholte Einfrierungen von 3-5 Sekunden oder mehr beim Zappen zwischen Kanälen während der Hauptabendstunden — das ist das ECM-Queueing, das sich staut. Zweitens, Zeitüberschreitungen in Ihrem Protokoll, die immer wieder denselben Peer treffen, obwohl Ihre Verbindung stabil ist. Drittens, wenn Sie einen lokalen Reader gekauft haben und CCcam ihn einfach nicht so betreiben kann, wie Sie es benötigen — das ist Ihr Zeichen, sich eine Alternative zum CCcam-Setup anzusehen, anstatt gegen die Software zu kämpfen, die Sie bereits haben.

Die Haupt-CCcam-Alternativen im Vergleich

Es gibt wirklich drei Softcams, die es wert sind, als Alternative zum CCcam-Setup im Jahr 2026 in Betracht gezogen zu werden: OScam, mgcamd und NCam. Jede nimmt eine andere Nische ein, und die falsche Wahl für Ihren Anwendungsfall schafft nur neue Kopfschmerzen.

OScam — das Open-Source-Arbeitstier (Reader, Protokolle, Webif)

OScam ist diejenige, auf der die meisten Leute landen. Es ist Open-Source, aktiv gepflegt und mehrfädig — was bedeutet, dass ein langsamer Reader oder Peer nicht alles andere zum Stillstand bringt. Es spricht newcamd (typischerweise pro Reader ab Port 15000 gebunden, obwohl Sie dies selbst festlegen), das native CCcam-Client/Server-Protokoll, camd35, radegast und gbox-Protokolle alles aus derselben Binärdatei. Es kann lokale Smargo- und Phoenix-Reader über seriell/USB (normalerweise als /dev/ttyUSB0 aufgelistet) betreiben und wird mit einer ordentlichen Weboberfläche für die Live-Überwachung geliefert. Wenn Sie eine Softcam möchten, die alles tut, was CCcam tut, plus lokale Reader-Verwaltung und Multi-Protokoll-Unterstützung, dann ist dies sie.

OScam-Emu / NCam-Forks — wenn Sie Emulation oder zusätzliche CAS benötigen

NCam ist ein Fork von OScam, der zusätzliche CAS-Unterstützung und Emulationsfunktionen (konstante CW / SoftCam.Key-Verarbeitung) schneller integriert, als es die Hauptversion von OScam manchmal tut. OScam-Emu-Zweige existieren aus ähnlichen Gründen. Wenn Ihr Anbieter oder Setup Emulationsunterstützung benötigt, die das Vanilla-OScam noch nicht integriert hat, ist einer dieser Forks einen Versuch wert — das Konfigurationsformat ist nahezu identisch mit OScam, sodass die Migration zwischen ihnen trivial ist.

mgcamd — leichter newcamd-Client

mgcamd ist klein, schnell zu konfigurieren und rein ein Client — es hat keine Serverrolle und kann lokale Smartcard-Reader nicht betreiben. Die Konfiguration lebt in zwei Dateien: newcamd.list für Ihre Leitungs-Einträge und mg_cfg für globale Einstellungen. Wenn Sie eine Box mit niedrigen Spezifikationen haben oder einfach nur einen dünnen Client möchten, der ein oder zwei newcamd-Leitungen mit minimalem RAM-Verbrauch abruft, ist mgcamd wirklich gut in diesem einen Job. Erwarten Sie nicht, dass es OScam für irgendetwas darüber hinaus ersetzt.

gbox und Legacy-Optionen — größtenteils historisch

gbox existiert immer noch und einige alte Hasen schwören auf sein Peer-to-Peer-Modell, aber es ist zu diesem Zeitpunkt eine Nischenwahl — größtenteils am Leben gehalten von Menschen, die ihr Netzwerk vor einem Jahrzehnt darum herum aufgebaut haben. OScam unterstützt das gbox-Protokoll nativ, wenn Sie in ein bestehendes gbox-Netzwerk ohne das Ausführen von gbox selbst überbrücken müssen.

Funktionsmatrix: Protokollunterstützung, lokale Reader-Unterstützung, Lastenhandling, aktive Entwicklung

Migration von CCcam.cfg zu OScam

Dies ist der Teil, den die meisten Vergleichsartikel völlig überspringen, und es ist der Teil, der tatsächlich wichtig ist, wenn Sie wechseln. Ihre vorhandene CCcam.cfg hat Zeilen wie diese für jeden Peer, mit dem Sie sich verbinden:

C: 123.45.67.89 12000 myuser mypass

Das entspricht einem OScam[reader]Block in oscam.server:

DascccversionFeld ist wichtiger, als die Leute denken. Einige Peers handshaken nur korrekt bei 2.0.11, andere erwarten 2.1.1 oder 2.3.0 — wenn Sie es falsch machen, sehen Sie eine Verbindung, die hergestellt wird und dann sofort abbricht. Wenn ein Peer, den Sie migriert haben, stillschweigend fehlschlägt, ist das das erste, was Sie überprüfen sollten.

Mapping einer CCcam C-Zeile zu einem OScam [reader] Block

Jede C-Zeile in Ihrer alten Konfiguration wird zu einer Reader-Strophe. Geben Sie jeder einen eindeutigenlabelund weisen Sie es einergroupNummer zu — Gruppen sind, wie Sie steuern, welche Clients später in oscam.user Zugriff auf welche Reader erhalten. Wenn Sie zehn C-Zeilen hatten, haben Sie zehn Reader-Blöcke, was mühsam klingt, aber es ist ein fünfminütiger Such- und Ersetzungsjob, sobald Sie das Muster sehen.

Die Kernkonfigurationsdateien: oscam.conf, oscam.server, oscam.user, oscam.services

OScam verteilt die Konfiguration auf mehrere Dateien anstelle einer flachen Datei wie CCcam.cfg. oscam.conf enthält globale Einstellungen unter Abschnitten wie[global],[cs357x],[cccam], und[webif]. oscam.server enthält Ihre Reader-Definitionen (was die C-Zeilen in CCcam.cfg früher gemacht haben). oscam.user definiert die Clients, die sich mit Ihrer Box verbinden dürfen, ihre AU (Auto-Update)-Einstellungen und welche Reader-Gruppen sie erreichen können. oscam.services dient der SID-Filterung, auf die wir weiter unten eingehen werden. Auf den meisten Enigma2-Images befinden sich diese unter /etc/tuxbox/config/oscam/, obwohl einige Images stattdessen /var/keys/ oder /usr/keys/ verwenden — überprüfen Sie mitfind / -name "oscam.server" 2>/dev/null wenn Sie sich nicht sicher sind, welches Ihr Image verwendet.

Aktivieren der Weboberfläche (httpport = 8888) für die Live-Überwachung

Unter[webif] in oscam.conf, setzen Siehttpport = 8888 und einen Benutzernamen/Passwort. Starten Sie OScam neu und öffnen Sie einen Browser auf die IP Ihrer Box über Port 8888. Dieses einzelne Feature ist es wert, dafür zu wechseln — Sie erhalten den Live-Reader-Status, ECM-Zeiten pro Client und Verbindungsprotokolle, ohne Textdateien über SSH zu verfolgen.

Einrichten des Cache-Austauschs (CSP) und der Anti-Freeze-Optionen

Der Cache-Austausch (cacheex) ermöglicht es OScam-Servern, bereits dekodierte Steuerwörter miteinander zu teilen, was die ECM-Belastung erheblich reduziert, wenn Sie mehrere Boxen betreiben. Modus 1 sendet nur, Modus 2 empfängt nur, und Modus 3 macht beides. Seien Sie vorsichtig mit Modus 3 zwischen mehr als zwei Servern — wenn Sie die cacheex-Hop-Limits nicht korrekt einstellen, können Sie CW-Stürme erhalten, die dieselben Cache-Einträge in Schleifen zwischen Servern zurückwerfen, was tatsächlich die Last erhöht, anstatt sie zu reduzieren. Beginnen Sie mit Modus 1/2 zwischen zwei Boxen, bevor Sie ein vollständiges Modus 3-Netzwerk ausprobieren.

CCcam und OScam während des Übergangs nebeneinander betreiben

Sie müssen nicht blind umschalten. Führen Sie OScam auf einem anderen Port-Set aus (sagen wir newcamd auf 15001 anstelle von CCcams üblichem 12000), während CCcam weiterhin auf seinem ursprünglichen Port läuft. Auf Enigma2 legen Sie fest, welcher Softcam für die Entschlüsselung im Softcam-Manager des Images "aktiv" ist, aber beide Binaries können gleichzeitig installiert und konfiguriert sein. Testen Sie Ihre OScam-Konfiguration einige Tage lang mit echten Kanälen, bevor Sie den Schalter umlegen und CCcam vollständig deaktivieren. Dies ist der sicherste Weg, um eine alternative CCcam-Einrichtung zu validieren, ohne das Risiko von Ausfallzeiten auf einer Box, auf die Sie tatsächlich angewiesen sind.

Testen und Fehlersuche bei Ihrer neuen Einrichtung

Sobald OScam läuft, verbringen Sie die meiste Zeit mit der Fehlersuche auf der Webif-Statusseite. Jede Client-Verbindung zeigt eine ECM-Zeit in Millisekunden — unter 400 ms ist gesund und Sie sollten keine Verzögerung beim Zappen von Kanälen bemerken. Wenn Sie konstant 800 ms oder mehr sehen, stimmt etwas upstream nicht, entweder ein überlasteter Peer oder ein Reader, der Schwierigkeiten hat.

Lesen der OScam-Webif-Statusseite (ECM-Zeit, CW, rc-Codes)

Die rc (Rückgabecode)-Spalte zeigt Ihnen, was tatsächlich mit jeder Anfrage passiert ist. rc=0 bedeutet gefunden und sauber geliefert. Alles andere benötigt Aufmerksamkeit, und die beiden, die Sie beim Troubleshooting einer frischen Migration am häufigsten sehen werden, sind unten aufgeführt.

Häufige Fehlercodes: abgelehnt (rc=E2), keine Karte, ECM-Timeout

rc=E2 bedeutet abgelehnt — der Reader oder Peer hat die Anfrage ausdrücklich abgelehnt, normalerweise weil der Client nicht berechtigt ist, auf diese SID zuzugreifen oder die Leitung diesen Kanal nicht tatsächlich bereitstellt. "Keine Karte" bedeutet, dass der Reader selbst nicht reagiert, was bei lokaler Hardware normalerweise eine schlechte USB-Verbindung oder eine falsch eingesetzte Karte bedeutet. ECM-Timeout bedeutet, dass die Anfrage gesendet wurde und nichts rechtzeitig zurückkam — überprüfen Sie, ob der Peer überlastet ist oder ob Ihre cccversion-Inkompatibilität stille Abbrüche verursacht.

Überprüfen der Reader-Berechtigungen und SID-/Service-Filterung

oscam.services ermöglicht es Ihnen, genau festzulegen, auf welche Service-IDs (SIDs) ein gegebener Reader oder Client zugreifen kann. Dies ist wichtig, wenn Sie einen Reader mit anderen teilen — ohne Filterung können Peers nach Kanälen suchen, die Ihre Leitung nicht tatsächlich bereitstellt, was unnötige abgelehnte Anfragen erzeugt und Ihre Protokolle überfüllt. Setzen Sie explizite SID-Listen pro Gruppe, anstatt alles weit offen zu lassen.

Protokollierungsstufen-Anpassung und wo oscam.log gespeichert ist

Standardmäßig protokolliert OScam in oscam.log im selben Konfigurationsverzeichnis (/etc/tuxbox/config/oscam/oscam.log auf den meisten Enigma2-Images). Wenn Sie ein spezifisches Verbindungsproblem debuggen, erhöhen Sieloglevel = 4 entweder in oscam.conf oder live über die Webif, reproduzieren Sie das Problem, und setzen Sie es dann wieder auf 1 oder 2 zurück. Das permanente Aktivieren der ausführlichen Protokollierung wird den Flash-Speicher auf Boxen mit begrenztem Speicherplatz schnell aufbrauchen — ich habe gesehen, dass dies einen 512 MB internen Flash innerhalb weniger Wochen auf einem stark frequentierten Multi-Client-Server füllt.

Wählen eines Leitungsanbieters für Ihre alternative Softcam (allgemeine Kriterien)

Egal, welche Softcam Sie verwenden, die Qualität Ihrer Einrichtung ist nur so gut wie die Leitungen, die sie speisen. Dieser Teil ist wichtig, unabhängig davon, ob Sie CCcam, OScam oder etwas anderes verwenden — und es ist wert, es klar zu sagen: dies gilt nur für das Teilen Ihrer eigenen rechtmäßig erworbenen Abonnementkarten in einem privaten/lokalen Netzwerk. Sie sind dafür verantwortlich, sicherzustellen, dass Sie ein gültiges Abonnement für alles haben, was Sie entschlüsseln, und die Bedingungen Ihres Anbieters sowie das lokale Recht einzuhalten.

Protokollkompatibilität (spricht die Leitung cccam/newcamd sauber?)

Bestätigen Sie die Protokollversion, bevor Sie die Reader-Konfiguration festlegen. Eine Quelle, die eine alte CCcam-Handshake-Version verwendet, wird gegen einen Reader, der für eine neuere konfiguriert ist, fehlschlagen und umgekehrt — dies ist dasselbe cccversion-Problem, das zuvor behandelt wurde, nur aus der anderen Richtung.

ECM-Antwortzeit und Erwartungen an die Serververfügbarkeit

Beobachten Sie die ECM-Zeiten in Ihrem Webif über ein paar Tage, bevor Sie entscheiden, dass eine Quelle zuverlässig ist. Konsistente Reaktionszeiten unter 400 ms mit gelegentlichen kurzen Spitzen während der Hauptverkehrszeiten sind normal. Ständige Timeouts oder rc=E2-Abweisungen sind ein Zeichen dafür, dass die Quelle überverkauft oder auf deren Seite falsch konfiguriert ist, nicht auf Ihrer.

Lokale Karte vs. gemeinsame Leitung: Latenz- und Zuverlässigkeitskompromisse

Eine lokale Karte in Ihrem eigenen Reader wird immer eine gemeinsame Netzwerkleitung in Bezug auf Latenz und Zuverlässigkeit übertreffen, einfach weil es keinen Netzwerk-Hops oder Konkurrenz mit anderen Clients gibt. Gemeinsame Leitungen sind praktisch, aber Sie sind den Launen der vielen anderen Personen ausgeliefert, die gleichzeitig auf dieselbe Quelle zugreifen.

Warnsignale bei der Bewertung jeder Quelle

Seien Sie vorsichtig bei allem, was unbegrenzte gleichzeitige Verbindungen auf einer einzigen Karte verspricht — so funktioniert Card Sharing technisch nicht, und es bedeutet normalerweise überverkauften Zugang, der während der Hauptzeiten einfriert. Vage Antworten darauf, welches Protokoll oder CAS die Linie tatsächlich unterstützt, sind ein weiteres Warnsignal. Testen Sie, bevor Sie Zeit in eine echte Konfiguration investieren.