Beste OSCam-Konfiguration: Optimaler Einrichtungsleitfaden (2026)

Wenn Sie OSCam seit mehr als einer Woche betreiben, wissen Sie bereits, dass die Standardkonfigurationen, die in Foren kursieren, ein Durcheinander sind. Die Hälfte von ihnen wurde für eine Kartenkonfiguration geschrieben, die niemand mehr verwendet, und die andere Hälfte kopiert Werte, ohne zu erklären, was sie tatsächlich tun. Dieser Leitfaden beschreibt, was ich als die beste OSCam-Konfiguration für eine stabile, latenzarme Reader-Konfiguration im Jahr 2026 bezeichnen würde — nicht die schnellste mögliche Zahl auf einem Benchmark-Bildschirm, sondern eine Konfiguration, die eine Woche echten Datenverkehr übersteht, ohne dass Sie um 2 Uhr morgens per SSH eingreifen müssen, um den Dienst neu zu starten.

Ich gehe davon aus, dass Sie OSCam bereits kompiliert und am Laufen haben. Dies ist kein "Was ist Cardsharing?"-Beitrag. Es geht darum, oscam.conf, oscam.server, oscam.user und oscam.services so zu optimieren, dass die ECM-Zeiten niedrig bleiben und Ihre Reader unter Last nicht ausfallen.

Was 'Beste' OSCam-Konfiguration tatsächlich bedeutet

Hier ist das, was Ihnen niemand im Voraus sagt: Es gibt keine einzige beste OSCam-Konfiguration, die Sie auf jede Box anwenden und dann einfach weggehen können. Ein Raspberry Pi, der eine lokale Karte betreibt, verhält sich völlig anders als ein VPS, der gleichzeitig mit sechs Cache-Ex-Partnern über newcamd und CCcam kommuniziert. Die "besten" Einstellungen für die eine sind auf der anderen aktiv schädlich — das Hochdrehen der Cache-Ex-Threads auf einem 512MB STB führt nur dazu, dass Ihr Prozess OOM-getötet wird.

Optimierung für Dekodiergeschwindigkeit vs. Stabilität

Niedrige ECM-Zeiten sehen in einem Diagramm großartig aus, aber zu aggressiv danach zu streben, führt dazu, dass Menschen instabile Konfigurationen erhalten. Wenn Sie Zeitüberschreitungen zu eng setzen, um 200 ms von der Dekodierzeit abzuziehen, erhalten Sie vorzeitige Reader-Fallbacks und ein Bildausfall, sobald Ihr Netzwerk einen Hänger hat. Eine wirklich gute Konfiguration balanciert beides — schnell genug, dass Kanalwechsel sofort erscheinen, stabil genug, dass Sie keine Support-Tickets über Einfrieren zur Hauptsendezeit erhalten.

Warum es keine einzige universelle Konfiguration gibt

Ihre Hardware, die Anzahl Ihrer Reader und Ihre Protokollmischung (lokale Karte vs. CCcam vs. newcamd vs. gbox) ändern alle, wie "optimal" aussieht. Eine Konfiguration, die für eine lokale DVB-S2-Karte ohne Sharing optimiert ist, sollte nichts mit einer für eine fünf-Reader-lastenausgeglichene Box zu tun haben, die von mehreren Upstream-Quellen zieht. Jeder, der Ihnen eine einzige universelle oscam.conf gibt, ohne nach Ihrer Konfiguration zu fragen, gibt Ihnen einen Ausgangspunkt, kein fertiges Produkt.

Die vier Kern-Dateien und ihre Rollen

Alles lebt in vier Dateien, die zusammenarbeiten.oscam.conf behandelt das globale Verhalten — Protokollierung, Zeitüberschreitungen, die Weboberfläche, Monitorport, Anti-Cascading.oscam.server definiert Ihre Reader: lokale Smartcard-Slots, Proxy-Verbindungen zu CCcam- oder newcamd-Quellen, gbox-Peers.oscam.user definiert, wer sich mit Ihrer Box verbinden darf und was sie sehen können.oscam.services gruppiert CAIDs und Idents in benannte Dienstbündel, die Sie pro Reader und pro Benutzer auf die Whitelist setzen oder blockieren können. Wenn Sie die Beziehung zwischen diesen vier richtig hinbekommen, verschwinden die meisten "keine Kanäle"-Beschwerden von selbst.

Optimale oscam.conf Globale Einstellungen

In den meisten Builds finden Sie oscam.conf unter/etc/tuxbox/config/oscam.conf, obwohl einige Distributionen/var/keys/ oder was auch immer ConfigDir zur Kompilierzeit mit--with-configdir gesetzt wurde, verwenden. Wenn Sie sich nicht sicher sind, überprüfen Sie die Fußzeile der Weboberfläche oder starten Sie OSCam mit-c /path/to/config um es zu erzwingen.

[global] Protokollierungs- und nice/pidfile-Einstellungen

Hier ist ein vernünftiger [global]-Block, den ich als Basis verwende:

[global]

maxlogsize=50 verhindert, dass Ihre Protokolldatei über 50KB hinauswächst, bevor sie rotiert — auf STB-Hardware mit begrenzten Flash-Schreibvorgängen ist das wichtiger, als die Leute realisieren.nice=-1 gibt OSCam einen leichten Prioritätsvorteil bei der Planung gegenüber anderen Prozessen, was die ECM-Antwortzeit auf Boxen, die doppelt genutzt werden, verbessert.preferlocalcards=1 weist OSCam an, immer zuerst eine lokale Karte zu versuchen, bevor auf einen Netzwerkleser zurückgegriffen wird, was genau das ist, was Sie wollen, wenn Sie die Karte besitzen und nur Peers als Backup verwenden.

[webif] aktiviert die Weboberfläche auf Port 8888

[webif]

Port 8888 ist der Standard von OSCam und es gibt keinen Grund, ihn zu ändern, es sei denn, etwas anderes auf der Box verwendet ihn bereits. Was tatsächlich zählt, isthttpallowed — beschränken Sie es auf Ihren LAN-Bereich. Die Weboberfläche auf 0.0.0.0 auf einer Box mit internetzugänglichen Ports offen zu lassen, ist der Grund, warum Leute ihre Kartendaten abgezogen bekommen. Ich werde darauf in den Sicherheits-FAQ zurückkommen, aber behandeln Sie es als nicht verhandelbar.

[monitor] und [anticasc] Abstimmung

[monitor]

Anti-Cascading erkennt, wenn eine einzelne Karte zu vielen gleichzeitigen Clients geteilt wird, und drosselt oder blockiert sie. Es ist wirklich nützlich auf einer gemeinsamen Box mit mehreren unzuverlässigen Benutzern, aber auf Low-RAM STB-Hardware fügt es ständige Überhead für eine Überprüfung hinzu, die Sie wahrscheinlich nicht benötigen, wenn Sie der einzige Client sind. Wenn Sie auf etwas wie einer 512MB Vu+ oder ähnlichen Box laufen, lassen Sieanticasc deaktiviert und verlassen Sie sich aufuniq in oscam.user stattdessen — günstiger und erledigt die meiste gleiche Arbeit für eine Einbesitzer-Konfiguration.

clienttimeout, fallbacktimeout und cachedelay Werte

clienttimeout=15000

clienttimeout (in Millisekunden) ist, wie lange OSCam auf eine Antwort wartet, bevor es die ECM-Anfrage vollständig aufgibt — 15000ms ist eine angemessene Obergrenze.fallbacktimeout ist das, was die Leute ständig falsch verstehen. Es steuert, wie lange OSCam auf den primären Leser wartet, bevor es einen Fallback-Leser für dieselbe ECM versucht. Stellen Sie es zu niedrig ein (sagen wir, unter 1000ms) und Sie erhalten vorzeitigen Fallback — OSCam springt zu einem Backup-Leser, bevor die primäre Karte überhaupt eine faire Chance hatte, was Bandbreite verschwendet und gelegentlich doppelte CW-Anfragen verursacht. Stellen Sie es zu hoch ein und ein kämpfender primärer Leser wird Ihre gesamte Kette zum Stillstand bringen, bevor der Fallback einsetzt. 2500ms ist ein guter Mittelweg für die meisten lokalen Karten plus Backup-Setups; reduzieren Sie es näher auf 1500ms, nur wenn die durchschnittliche ECM-Zeit Ihres primären Lesers konstant unter 500ms liegt.

Konfigurieren von Lesern in oscam.server

Hier findet der Großteil der tatsächlichen Abstimmung statt. Jeder[reader] Block definiert eine Karte oder eine Proxy-Verbindung.

Lokaler Smartcard-Leser (Gerät, mhz, cardmhz)

[reader]

mhz ist die Taktrate, die OSCam verwendet, um mit der Leserhardware zu kommunizieren;cardmhz ist die Taktrate, die es mit der Karte selbst aushandelt. Die meisten Karten funktionieren gut mit der ISO-Baseline von 357/357. Einige Karten unterstützen schnellere Lesevorgänge bei 368, 369 oder sogar 600 — aber wenn Sie cardmhz auf etwas setzen, das die Karte tatsächlich nicht unterstützt, erhalten Sie eine Karteninitialisierungsschleife, bei der der Leser immer wieder zurückgesetzt wird, anstatt sich in ATR einzufinden. Wenn Sie wiederholt "Karteninitialisierung"-Fehler im Protokoll direkt nach einem Neustart sehen, gehen Sie zuerst auf 357/357 zurück, bestätigen Sie, dass es sauber initialisiert, und experimentieren Sie erst dann nach oben.

Hinzufügen von cccam/newcamd/gbox Proxy-Lesern

[reader]

Verwenden Sie Platzhalter-IPs wie diese beim Testen — niemals einen echten Anbieter-Hostnamen in eine gemeinsame Konfiguration einfügen, die Sie öffentlich posten. Für newcamd-Leser, tauschen Sieprotocol = newcamd und fügen Siekey = mit dem DES-Schlüssel hinzu, plusemmcache Einstellungen, wenn Sie EMM-Caching von dieser Quelle wünschen.

CAID, Ident und Dienstfilterung pro Leser

caid = 1802,1801

disablecrccws=1 überspringt die CRC-Prüfung bei Steuerwörtern — gelegentlich notwendig für fehlerhafte Kartenfirmware, die fehlerhafte, aber gültige CWs zurückgibt, aber lassen Sie es auf 0, es sei denn, Sie haben bestätigt, dass Sie es tatsächlich benötigen, da es auch echte Korruption verbirgt.ecmwhitelist schränkt ein, welche ECM PIDs der Leser überhaupt versuchen wird, was unnötige Anfragen auf Multi-CAID-Transpondern reduziert.

group, fallback und cacheex_maxhop Parameter

group ist die am häufigsten missverstandene Einstellung in der gesamten Konfiguration, und ich sage es ganz klar: Die Gruppennummer eines Lesers muss mit der Gruppennummer eines Benutzers übereinstimmen, damit dieser Benutzer jemals Karten von diesem Leser sehen kann. Kein Fehler, keine Warnung — der Client verbindet sich einfach und erhält nichts. Wenn Sie sich an eine Sache aus diesem Artikel erinnern, dann daran.cacheex_maxhop begrenzt, wie viele Hops ein gemeinsames CW durch Ihr Peer-Netzwerk reisen kann, bevor es verworfen wird — mehr dazu im nächsten Abschnitt, denn es falsch zu machen, ist der Grund, warum Cache-Ex-Netzwerke in Duplikat-CW-Stürme umschlagen.

Client-Zugriff und Berechtigungen in oscam.user

Benutzer definieren, Gruppenzuordnung und AU

[account]

Wieder —group = 1 hier muss mit der Gruppe des Lesers übereinstimmen, damit dieser Benutzer etwas von dieser Karte sehen kann.au (Auto-Update) sollte genau auf ein vertrauenswürdiges Leserlabel zeigen, und ehrlich gesagt, sollte nur ein Client pro Karte überhaupt AU aktiviert haben. Wenn Sie AU für dieselbe Karte für zwei verschiedene Client-Konten aktivieren, erhalten Sie gleichzeitige EMM-Schreibvorgänge auf die Karte aus zwei Richtungen — das ist ein schneller Weg, den internen Zustand der Karte zu beschädigen oder Schreibkonflikte zu verursachen, die sich Tage später als zufällige Dekodierungsfehler zeigen.

caidtab, betatunnel und Dienste pro Benutzer

caidtab = 1802:0500,1801:0000

caidtab schränkt einen bestimmten Benutzer auf bestimmte CAIDs ein, selbst wenn der Leser, dem sie zugeordnet sind, mehr hat.betatunnel ist wichtig in gemischten CAID-Umgebungen — wenn Sie eine Nagra (1801/1802) Karte haben und Seca-gekennzeichnete Kanäle dekodieren müssen, die tatsächlich denselben Feed tragen, remappt betatunnel die CAID im laufenden Betrieb, sodass der Empfänger das CW akzeptiert. Ohne es scheitern gemischte Nagra/Seca-Setups einfach stillschweigend daran, bestimmte Kanäle zu dekodieren, obwohl die Karte technisch gesehen ein gültiges CW erzeugen kann.

Ratenbegrenzung mit cccmaxhops und sleep

cccmaxhops = 2

cccmaxhops begrenzt, wie weit ein CCcam-Share durch nachgelagerte Reshares propagieren kann — halten Sie es auf 2, es sei denn, Sie haben einen bestimmten Grund, Karten weiter reisen zu lassen, da jeder zusätzliche Hop Latenz und Last-Risiko hinzufügt.sleep trennt inaktive Clients nach N Minuten, was Verbindungsslots auf einem beschäftigten Server freigibt, anstatt Zombie-Sitzungen festzuhalten.

Sichern von Konten und Deaktivieren ungenutzter Benutzer

uniq = 1 verhindert, dass dasselbe Konto gleichzeitig von zwei Orten angemeldet wird — setzen Sie dies für jedes Konto, es sei denn, Sie haben einen bestimmten Grund, dies nicht zu tun, denn gemeinsame Anmeldeinformationen sind der häufigste Weg, wie ein Konto missbraucht wird. Für Konten, die Sie derzeit nicht verwenden, löschen Sie sie nicht — setzen Sieenabled = 0 stattdessen, damit Sie die Konfigurationshistorie behalten, ohne eine aktive Tür offen zu lassen.

cache-ex, Peering und Leistungsoptimierung

Dies ist der Teil, den die meisten Anleitungen vollständig überspringen, und es ist ehrlich gesagt der Unterschied zwischen einer guten Konfiguration und der besten OSCam-Konfiguration für ein Multi-Reader-Setup. Cache-ex ist das, was OSCam-Boxen ermöglicht, bereits dekodierte Steuerwörter miteinander zu teilen, anstatt dass jede Box ihre eigene Karte für dasselbe ECM abruft.

cacheex Modus 1, 2 und 3 erklärt

Modus 1 ist nur Cache — der Leser speichert CWs, die er sieht, aber drückt oder zieht sie nicht aktiv. Modus 2 drückt CWs nach außen zu Peers (Sie sind die Quelle). Modus 3 zieht CWs von Peers an (Sie sind der Verbraucher). Wenn Sie die Richtung umkehren, überfluten Sie entweder Peers mit CWs, die sie nicht angefordert haben, oder warten auf einen "Pull"-Leser, der niemanden hat, der tatsächlich zu ihm drückt. Setzen Siecacheex = 2 auf Lesern, die Karten repräsentieren, die Sie besitzen und teilen möchten, undcacheex = 3 auf Lesern, die von upstream Peers stammen, von denen Sie konsumieren.

cacheex_maxhop und Vermeidung von Cache-Schleifen

Hier ist ein Fehlerzustand, der Leute erwischt, die drei oder mehr Peers betreiben: ohne ein sinnvollescacheex_maxhop kann ein CW zwischen Peer A, B und C wiederholt hin und her springen, wobei jede Box es erneut sendet, als wäre es neu. Das ist ein Duplikat-CW-Sturm, und es frisst Bandbreite und CPU ohne jeglichen Nutzen. Halten Siecacheex_maxhop = 2 als Ihre Standardeinstellung und setzen Sie es niemals über 3 in einem Multi-Peer-Mesh, es sei denn, Sie kontrollieren jede Box in diesem Mesh vollständig und haben verifiziert, dass es keine Schleife in der Topologie gibt.

csp (Cache-Server-Protokoll) und lb_mode Lastverteilung

[csp]

lb_mode = 1 aktiviert den integrierten Lastenausgleich von OSCam über Ihre Leser, die nach der historischen ECM-Antwortzeit eingestuft werden.lb_nbest_readers steuert, wie viele leistungsstarke Leser parallel für ein gegebenes ECM ausprobiert werden — 2 ist ein vernünftiger Standard für die meisten Setups mit mehr als einer brauchbaren Quelle pro CAID.lb_reopen_seconds gibt an, wie lange ein als schlecht markierter Leser sidelined bleibt, bevor OSCam ihm eine weitere Chance gibt; 900 Sekunden (15 Minuten) vermeiden es, einen Leser zu belasten, der gerade eine schlechte Minute hat, während er ihn letztendlich trotzdem wiederherstellt.

Reduzierung der ECM-Zeit- und Intervall-Einstellungen

Die Statistiken-Seite der Weboberfläche zeigt die durchschnittliche ECM-Zeit pro Leser — das ist Ihr echtes Diagnosewerkzeug, nicht Rätselraten. Wenn Sie Dekodierfehler (die Karte hat nichts Nützliches zurückgegeben) im Vergleich zu Zeitüberschreitungen (es kam überhaupt nichts zurück) in unterschiedlichen Proportionen über die Leser sehen, sagt Ihnen das unterschiedliche Dinge: Dekodierfehler deuten normalerweise auf CAID/Ident-Mismatches oder eine kämpfende Karte hin, Zeitüberschreitungen deuten normalerweise auf Netzwerkverzögerungen oder einen überlasteten upstream Peer hin. Beobachten Sie diese Seite einen Tag lang, bevor Sie blind Timeout-Werte ändern.

Fehlerbehebung bei häufigen OSCam-Konfigurationsproblemen

Karte wird nicht initialisiert (mhz / Gerätefehler)

Wenn Ihr Protokoll wiederholt ATR-Fehler zeigt oder die Karte in einer Schleife zurückgesetzt wird, überprüfen Sie zuerst denGerätepfad — ein USB-Leser kann sich nach einem Neustart von/dev/ttyUSB0 zu/dev/ttyUSB1 verschieben, wenn sich die Reihenfolge von etwas anderem am Bus geändert hat. Wenn der Gerätepfad korrekt ist, setzen Siemhz/cardmhz zurück auf 357/357 als Basistest.

Client verbindet sich, aber keine Kanäle dekodieren

Neun von zehn Mal ist dies die Gruppenschwankung, die ich zuvor erwähnt habe — überprüfen Sie dieGruppenzeile des Lesers mit derGruppenzeile des Benutzers. Wenn diese übereinstimmen und es immer noch nicht funktioniert, überprüfen Sie oscam.services — es ist einfach, die richtige CAID und Gruppe korrekt einzustellen, während ein Eintrag in der Dienstdatei stillschweigend den spezifischen Ident des Kanals ausschließt, was von der Client-Seite identisch aussieht wie ein Gruppenproblem, aber nichts mit Berechtigungen zu tun hat.

Eingefrorenes Bild und hohe ECM-Zeiten

Das ist fast immerfallbacktimeout zu aggressiv niedrig eingestellt, was dazu führt, dass die Leser-Kette zwischen primär und Fallback mitten im Stream wechselt, oder ein Leser, der tatsächlich überlastet ist von zu vielen gleichzeitigen Cache-ex-Peers, die von ihm abrufen. Überprüfen Sie die Leser-Statistikseite auf ECM-Zeitspitzen, die mit Ihren Spitzennutzungsstunden korreliert sind.

OSCam-Protokolle lesen, um die fehlerhafte Phase zu finden

Führen Sie OSCam im Vordergrund mit ausführlichem Leser-Debug aus:oscam -b -r 2. Durchsuchen Sie Ihr Protokoll nach zwei spezifischen Zeichenfolgen —"nicht gefunden (" sagt Ihnen, welche CAID/Ident der Client angefordert hat, die kein Leser bedienen konnte, und"abgelehnt" sagt Ihnen, dass eine Authentifizierung oder eine Gruppenblockade stattfand, bevor die Anfrage überhaupt zu einem Leser gelangte. Diese beiden Zeichenfolgen allein werden Sie schneller zur fehlerhaften Phase führen, als das gesamte Protokoll von oben nach unten zu lesen.

Nichts davon ist exotisch — es geht hauptsächlich darum, zu verstehen, was jeder Parameter tatsächlich tut, anstatt eine Konfiguration blind zu kopieren. Wenn Sie aus all dem eine Sache mitnehmen, dann ist es, dass die beste OSCam-Konfiguration für Ihre Box die ist, die zu Ihrer tatsächlichen Hardware und Anzahl der Leser passt, nicht das, was jemand anderes 2019 in einem Forum gepostet hat. Beginnen Sie mit den oben genannten Standardeinstellungen, beobachten Sie Ihre Leser-Statistikseite ein paar Tage lang und passen Sie von dort aus einen Wert nach dem anderen an.