Best CCcam Plugin for Enigma2: Setup & Tuning Guide

What 'best' Actually Means for an Enigma2 Card-Sharing Plugin

There isn't one universal answer to enigma2 cccam plugin best questions, and anyone who tells you otherwise is skipping the part where your box's CPU, your image, and your actual use case matter. I've run this stuff on everything from a single-core Vu+ Solo to an octagon box with cores to spare, and the "right" softcam changes depending on what you're actually doing with it.Here's the honest breakdown. Pure CCcam is closed source, simple, and fine if you're strictly a client pulling from C-lines. OScam is open source, actively maintained, and handles way more protocols — newcamd, cs378x, CCcam emulation, you name it. Then you've got hybrid setups running OScam as the backend with CCcam-compatible output, which is what a lot of experienced users land on eventually.For 2026, I'd point most people toward OScam unless you have a very specific reason not to. It gets patched more often, the webif gives you actual visibility into what's happening, and it doesn't care whether your provider speaks CCcam or newcamd — it just works with both. CCcam still has its place for dead-simple client-only setups where you don't need the extra moving parts.

Wenn du tatsächlich beurteilst, welches Plugin zu deinem Receiver passt, achte speziell auf diese Dinge:

• Wie es mit Reader-IDs und mehreren gleichzeitigen Kartenquellen umgeht
• ECM/EMM-Verarbeitungsgeschwindigkeit — das bestimmt die Zapping-Verzögerung
• Protokollierungsqualität (kannst du tatsächlich einen Freeze debuggen, oder ist es eine Black Box)
• Reconnect-Verhalten, wenn ein Share ausfällt
• Idle-CPU-Verbrauch, wenn der Receiver einfach nur dasitzt

Zapping-Geschwindigkeit vs. Stabilitätskompromisse

CCcam hat den Ruf, schnelles Zapping bei einfachen Setups zu bieten, weil es weniger Overhead gibt — es jongliert nicht fünf Protokolle gleichzeitig. OScam kann diese Geschwindigkeit erreichen, sobald es richtig eingestellt ist, aber out of the box mit aktivierter Debug-Protokollierung und falsch konfiguriertem Cacheex wird es sich träge anfühlen. Dies ist der Kompromiss, den niemand erwähnt: Die Flexibilität von OScam bedeutet mehr Konfigurationsoberfläche, was mehr Möglichkeiten bedeutet, es falsch zu machen, bevor es schnell wird.

Protokollunterstützung: CCcam vs. newcamd vs. cs378x

CCcam spricht das CCcam-Protokoll, Punkt. OScam spricht CCcam, newcamd, cs378x, radegast und kann auch lokale Karten über einen physischen Reader lesen. Wenn dein Anbieter nur CCcam-Linien anbietet, spielt das nicht viel Rolle. Aber wenn du Quellen mischst — sagen wir, eine newcamd-Linie von einem Ort und eine CCcam-Linie von einem anderen — ist OScam die einzige realistische Option, da es beide Reader-Typen gleichzeitig in derselben Konfiguration betreiben kann.

CPU- und RAM-Footprint auf Low-End-Boxen

Auf etwas wie einem originalen Vu+ Duo oder einer älteren Dreambox mit 256-512 MB RAM sind beide Plugins leicht genug, um gut zu laufen — der Daemon selbst ist nicht das Problem. Das Problem ist, was du darauf montierst. OScam mit hochgedrehtem cs_debug und Cacheex-Modus 3, der über zehn Reader läuft, wird eine Single-Core-Box beim Zapping absolut stottern lassen. Wenn du die Protokollierung reduzierst und die Reader-Gruppen sinnvoll hältst, läuft es identisch zu CCcam auf derselben Hardware.

Bildkompatibilität (OpenATV, OpenPLi, VTi)

Beide Plugins installieren sich sauber über das Feed auf OpenATV, OpenPLi und VTi — die drei Images, die die meisten Leute 2026 verwenden. OpenATV wird mit einem SoftCam-Panel geliefert, das alles auflistet, was installiert ist, und es dir ermöglicht, das aktive CAM mit einem Klick zu wechseln. Der Plugin-Manager von OpenPLi funktioniert auf die gleiche Weise. VTi tendiert dazu, standardmäßig eine etwas ältere OScam-Version zu bündeln, also überprüfe die Version und aktualisiere über das Feed, wenn du auf neuere Cacheex-Funktionen angewiesen bist.

Ein Softcam auf Enigma2 richtig installieren

Die Installation ist der Punkt, an dem die meisten Leute entweder in fünf Minuten alles richtig machen oder einen Nachmittag damit verbringen, Berechtigungsfehler zu bekämpfen. Lass uns beide Wege durchgehen — Feed-Installation und manuelle Installation — denn du wirst auf Situationen stoßen, die jeweils erforderlich sind.

Installation über Feed vs. manuelles IPK

Die Feed-Methode empfehle ich im Grunde jedem. SSH in die Box und führe aus:

opkg update&&opkg install enigma2-plugin-softcams-oscam

Tausche den Paketnamen gegen enigma2-plugin-softcams-cccam aus, wenn du diesen Weg gehst, oder überprüfe zuerst die verfügbaren Pakete mit opkg list | grep softcam, da die Benennung je nach Image leicht variiert (oscam vs oscam-emu vs oscam-trunk-Bauten erscheinen alle separat).

Verwendung des SoftCam-Managers / Softcam-Panels

Sobald installiert, drücke die blaue Taste auf deiner Fernbedienung und suche nach dem SoftCam-Panel (die Benennung variiert leicht — OpenATV nennt es Softcam-Manager). Diese Benutzeroberfläche listet jedes installierte CAM auf und lässt dich auswählen, welches aktiv ist. Was auch immer du auswählst, wird in /etc/enigma2/settings geschrieben, sodass es nach einem Neustart erhalten bleibt — du musst es nicht jedes Mal neu auswählen, wenn die Box neu startet.

Platzierung von Binärdateien und Starten des Daemons

Binärdateien befinden sich typischerweise in /usr/bin/ (oscam oder cccam, je nachdem, was du installiert hast). Das Init-Skript kümmert sich um das Starten und Stoppen, und das Wechseln im SoftCam-Panel löst ein Stoppen dessen aus, was gerade lief, und ein Starten des neuen. Wenn du dies manuell zum Testen machst, kannst du die Binärdatei direkt mit einem Vordergrund-Flag ausführen, um die Ausgabe live zu beobachten, bevor du die Kontrolle wieder an das Init-Skript übergibst.

Überprüfen, ob es läuft (Prozessprüfung und Weboberfläche)

Vertraue nicht nur der Benutzeroberfläche — bestätige auf Prozessebene. SSH rein und führe aus:

ps | grep oscam

Du solltest den Daemon mit einer PID aufgelistet sehen. Wenn er nicht da ist, überprüfe /var/log auf einen Absturzgrund — normalerweise einen Syntaxfehler in der Konfiguration. Für OScam speziell öffne einen Browser zu http://BOXIP:8888 und du solltest auf das Webinterface gelangen. Das ist dein bester diagnostischer Werkzeug für die Zukunft — Statusseite, Reader-Seite, ECM-Historie, all das findest du dort.

Anatomie der Konfigurationsdatei: CCcam.cfg und oscam.conf/server/user

Das ist der Teil, der tatsächlich bestimmt, ob Kanäle geöffnet werden, und es ist der Teil, den die meisten Anleitungen völlig überspringen. Lassen Sie uns in die echten Dateien eintauchen.

CCcam.cfg C-Line und F-Line Struktur

CCcam liest seine Konfiguration von /usr/keys/CCcam.cfg in den meisten Builds, obwohl einige Images es stattdessen in /etc/CCcam.cfg ablegen — überprüfen Sie beide, wenn Sie sich nicht sicher sind, welches aktiv ist, da die Binärdatei in einer festen Reihenfolge sucht und stillschweigend das verwendet, was sie zuerst findet.

C: 185.xx.xx.xx 12000 meinbenutzername meinpasswort

Das ist Hostname, Port, Benutzername, Passwort — nichts Aufwendigeres als das. Eine F-Line ist das Gegenteil: so teilen Sie Karten mit jemandem, der sich mit Ihnen verbindet:

F: ihrbenutzername ihrpasswort 1 0 0 0

Diese nachfolgenden Zahlen steuern die CAID/Ident-Filterung und Verbindungsgrenzen — lassen Sie sie auf den Standardeinstellungen, es sei denn, Sie müssen speziell einschränken, was ein nachgelagerter Client sehen kann.

oscam.conf, oscam.server, oscam.user Aufschlüsselung

OScam verteilt die Konfiguration über mehrere Dateien, die normalerweise in /etc/tuxbox/config/oscam/ oder /usr/keys/ je nach Konvention Ihres Images zu finden sind. Drei Dateien sind am wichtigsten:

[global]

oscam.server ist der Ort, an dem Sie jede Kartenquelle definieren, mit der Sie sich verbinden — jeder Leser erhält seinen eigenen Block. oscam.user ist der Ort, an dem Sie definieren, wer lokal auf Ihre Box zugreifen darf, wobei [account]-Blöcke den Zugriff und die Gruppenberechtigungen pro Client steuern.

Mapping einer CCcam C-Line in einen OScam [reader] Block

Das ist wirklich das, was ich bei der Migration von CCcam am häufigsten sehe, dass Leute Schwierigkeiten haben. Nehmen Sie diese gleiche C-Line von früher und hier ist das OScam-Äquivalent in oscam.server:

[reader]

Hostname und Port werden zu einer einzigen durch Kommas getrennten Gerätezeile, Benutzername/Passwort bleiben gleich, und Sie fügen eine Gruppennummer hinzu. Diese Gruppennummer ist das Stück, das die Leute ständig durcheinander bringt — sie muss mit einer Gruppennummer in Ihrem oscam.user-Konto-Block übereinstimmen oder der Leser wird sich zwar gut verbinden, aber nichts wird tatsächlich entschlüsselt. Mehr dazu im Abschnitt über Fehler, weil es eine eigene Hervorhebung verdient.

Ports: newcamd Standard 15000, cs378x und CCcam 12000

Schnellreferenz, da diese oft verwechselt werden: CCcams Standard-Listen/Verbindungsport ist 12000. newcamd läuft normalerweise auf 15000 und höher (einige Anbieter stapeln mehrere newcamd-Leser auf aufeinanderfolgende Ports wie 15001, 15002). cs378x hat keinen festen Standard — es ist der Port, den Sie in oscam.conf und der entsprechenden Client-Konfiguration festlegen. Welchen Port Sie auch verwenden, er muss auf beiden Seiten genau übereinstimmen, und wenn Sie einen Server betreiben, muss dieser Port über Ihren Router/NAT weitergeleitet werden, damit externe Benutzer Sie erreichen können.

Wählen eines Linienanbieters, ohne verbrannt zu werden

Ich werde Sie nicht auf bestimmte Verkäufer oder Liniengeschäfte hinweisen — teilweise, weil ich das hier nicht verantwortungsbewusst tun kann, und teilweise, weil die Kriterien wichtiger sind als jeder Name es ohnehin wäre. Hier ist, was Sie tatsächlich bewerten sollten.

Kriterien, die tatsächlich wichtig sind (Uptime, Lokal vs. Reshare, Hops)

Der größte Faktor ist die Hop-Tiefe. Eine lokale Karte (Hop 1) bedeutet, dass der Linieninhaber diese Smartcard physisch in einem Leser auf seiner Box hat. Jeder weitere Hop danach ist ein Reshare — jemand, der einen Anteil eines Anteils teilt. Hop 1 und Hop 2 sind im Allgemeinen in Ordnung. Ab Hop 3 oder darüber fügen Sie echte Latenz hinzu, und jeder zusätzliche Link in dieser Kette ist ein weiterer Ausfallpunkt.

Lesen der Share-Ausgabe: Hop-Anzahl und Kartentiefe

Öffnen Sie das OScam-Webinterface und gehen Sie zur Leserstatusseite. Jeder verbundene Leser zeigt Ihnen die Hop-Anzahl und typischerweise die ECM-Antwortzeit in Millisekunden. Unter etwa 400 ms ist solide für eine lokale oder Hop-1-Quelle. Wenn Sie konstant 800 ms+ oder wild inkonsistente Zahlen sehen, ist das ein tiefes Reshare oder eine überlastete Quelle, und es wird sich als Einfrieren bei allem zeigen, was anspruchsvoll ist, insbesondere bei HD-Inhalten.

Warnsignale in einem C-Line-Angebot

Einige Dinge sollten Sie sofort skeptisch machen: eine einzelne Linie, die behauptet, Hunderte von nicht verwandten CAIDs über völlig verschiedene Regionen und Anbieter abzudecken (so funktioniert der echte Kartenzugang nicht), keine Testphase, die angeboten wird, bevor Sie sich zu irgendetwas verpflichten, oder jemand, der Sie bittet, das Logging auf Ihrer eigenen Box zu deaktivieren. Letzteres ist ein großes Warnsignal — es gibt keinen legitimen Grund, warum jemand anderes Ihre Protokolle deaktiviert haben muss.

Testen einer Linie, bevor Sie sich verpflichten

Verwenden Sie Ihre eigenen Diagnosen, nicht die Ansprüche anderer. Fügen Sie den Leser hinzu, beobachten Sie die ECM-Historie des Webinterfaces für ein paar Tage über die tatsächlichen Kanäle, die Ihnen wichtig sind, und überprüfen Sie die Hop-Anzahl und die Antwortzeit unter realer Last — nicht nur um 3 Uhr morgens, wenn alles ruhig ist. Wenn es während der Hauptzeiten bei HD-Inhalten stabil bleibt, ist das ein echtes Signal.

Feinabstimmung für schnelles Zappen und null Einfrieren

Das Plugin zu installieren, ist der einfache Teil. Es tatsächlich schnell zu zapppen und nicht bei HD-Kanälen einzufrieren, ist der Teil, in dem die echte Feinabstimmung stattfindet.

ECM-Caching und Cacheex-Grundlagen

Das Cacheex-System von OScam ermöglicht es Lesern, ECM-Cache-Daten miteinander zu teilen, was das Zappen beschleunigt, wenn mehrere Boxen oder Clients von derselben Quelle abrufen. Modus 1 ist einfaches Caching, Modus 2 fügt ein Push-Verhalten zwischen Peers hinzu, Modus 3 ist ein vollständiger bidirektionaler Austausch. Hier ist jedoch das Problem — wenn Sie nur ein einzelner Client ohne nachgelagerte Freigabe sind, fügt Cacheex Overhead ohne Nutzen hinzu. Lassen Sie es ganz aus, es sei denn, Sie betreiben tatsächlich ein Multi-Client-Setup, bei dem das Cache-Sharing hilft.

Lesergruppe und Prioritätsreihenfolge

Richten Sie Ihre caidtab und Gruppenreihenfolge so ein, dass Ihre schnellste, zuverlässigste Quelle (normalerweise Ihre lokale Karte, wenn Sie eine haben) zuerst für einen bestimmten Kanal ausprobiert wird. OScam überprüft die Leser in der Reihenfolge, in der sie definiert sind, und nach Gruppenpriorität, also setzen Sie Ihre beste Quelle an die Spitze, anstatt sie durch drei unzuverlässige Reshares suchen zu lassen, bevor sie auf die trifft, die tatsächlich funktioniert.

Anti-Kaskade und Wiederverbindungs-Timer

Setzen Sie reconnecttimeout in Ihrem Leserblock auf etwas Vernünftiges — 20-30 Sekunden sind typisch — damit eine unterbrochene Verbindung sich erholt, ohne dass Sie minutenlang auf einem schwarzen Bildschirm sitzen. Keepalive-Einstellungen helfen hier ebenfalls, indem sie die Quelle regelmäßig anpingen, sodass Sie eine tote Verbindung bemerken, bevor Sie tatsächlich versuchen, etwas zu sehen.

Leerlauf-CPU und Protokollrauschreduzierung

Das ist wichtiger, als die Leute denken, insbesondere bei Flash-Speicher-Boxen. Setzen Sie logfile = /var/log/oscam.log und schalten Sie cs_debug in der Produktion aus — ausführliches Debug-Logging schreibt ständig auf Flash, was es im Laufe der Zeit abnutzt und CPU-Zyklen verbraucht, die eigentlich der tatsächlichen Entschlüsselung zugutekommen sollten. Setzen Sie loghistorysize auf etwas Modestes anstelle von unbegrenzt. Setzen Sie auch nice = -1 in oscam.conf, um dem Daemon einen Planungsvorrang gegenüber weniger kritischen Prozessen zu geben.

Was nicht funktioniert (und häufige Fehler)

Lassen Sie uns die Fehlermodi durchgehen, die ich immer wieder sehe, denn die meisten davon haben einfache Lösungen, sobald Sie wissen, was tatsächlich passiert.

Zwei CAMs auf demselben Tuner betreiben

Wenn Ihr Image sowohl CCcam als auch OScam vorinstalliert hat und beide irgendwie laufen, erhalten Sie intermittierende Dekodierungen, die zufällig erscheinen, es aber nicht sind – sie greifen beide auf das DVB-Gerät zu und treten sich gegenseitig auf die Füße. Überprüfen Sie mit ps | grep -E 'oscam|cccam' und beenden Sie den, den Sie nicht verwenden, und stellen Sie dann sicher, dass beim Booten nur einer über das SoftCam Panel gestartet wird.

Nicht übereinstimmende Gruppennummern zwischen Reader und Benutzer

Dies ist die häufigste Ursache für "es sagt verbunden, aber nichts wird entschlüsselt." Ihr Reader-Block in oscam.server hat eine Gruppennummer, Ihr Konto-Block in oscam.user hat eine Gruppennummer, und wenn sie sich nicht überschneiden, erhält der Client einfach keine ECMs von diesem Reader, obwohl die Verbindung selbst in Ordnung ist. Überprüfen Sie beide Dateien erneut, wenn eine neue Zeile sich verbindet, aber die Kanäle schwarz bleiben.

Falsches Configverzeichnis oder Dateiberechtigungen

Wenn Sie eine Konfigurationsdatei bearbeiten und die Änderungen nicht zu wirken scheinen, überprüfen Sie zuerst die Berechtigungen. Konfigurationsdateien müssen in der Regel vom Prozess lesbar sein – 644 ist Standard, und wenn ein Konfigurationsverzeichnis schreibgeschützt gemountet wurde oder die Datei nach einer manuellen Bearbeitung dem falschen Benutzer gehört, werden Ihre Änderungen stillschweigend ignoriert. Der Daemon läuft einfach mit der alten Konfiguration im Speicher weiter.

Verlassen auf Hop-5 Reshares für HD/UHD

HD- und UHD-Kanäle verwenden engere Krypto-Zeiträume – ungefähr 10 Sekunden – und wenn Ihre ECM-Rundreise durch vier oder fünf Reshare-Hops dieses Zeitfenster überschreitet, friert es genau dann ein, wenn der Schlüssel rotieren sollte. Das ist genau der Grund, warum die Hop-Tiefe für alles über SD so wichtig ist. Eine Linie, die für die Standarddefinition gut funktioniert, kann aus genau diesem Grund auf einem UHD-Kanal völlig zusammenbrechen.

Ein paar weitere Dinge, die es wert sind, speziell hervorgehoben zu werden: das Bearbeiten von CCcam.cfg unter Windows und das Speichern mit CRLF-Zeilenenden anstelle von LF wird das Parsen bei einigen CCcam-Bauten brechen – bearbeiten Sie immer über etwas, das Unix-Zeilenenden beibehält, oder konvertieren Sie mit dos2unix, bevor Sie hochladen. Die Groß- und Kleinschreibung bei Benutzernamen und nachfolgende Leerzeichen in einer C-Zeile führen ebenfalls zu stillen Authentifizierungsfehlern, die identisch zu einem toten Server aussehen.