Polsat Box Cardsharing Paket Einrichtung 2026 (CCcam/OScam)

Wenn Sie nach einem funktionierenden Polsat Box CCcam/OScam-Paket für Cardsharing 2026 suchen, haben Sie wahrscheinlich bereits das Problem bemerkt: die meisten Anleitungen online sind kopiert aus Forenthreads von 2019 und beziehen sich auf CAIDs, die seit Jahren keine ECMs mehr beantworten. Ich betreibe eine kleine OScam-Box zum Testen von Konfigurationen auf einer Handvoll DVB-S2-Setups, und das Erste, was ich jedem sage, der ein Polsat Box CCcam/OScam-Paket für Cardsharing 2026 sucht, ist dies — hören Sie auf, in Begriffen von "Paketen" zu denken, wie es ein Abonnent tun würde. Denken Sie in Begriffen von CAID und Anbieter-ID. Das ist das Einzige, was Ihren Leser tatsächlich interessiert.

Diese Anleitung erklärt, wie Sie identifizieren, womit Sie es auf der Karten-Seite tatsächlich zu tun haben, wie Sie oscam.server und oscam.dvbapi korrekt einrichten, wie das Äquivalent von CCcam.cfg aussieht, wenn Sie diese Binärdatei stattdessen verwenden, und — wahrscheinlich der Abschnitt, zu dem Sie am häufigsten zurückkehren werden — wie Sie die ECM-Zeitmessung lesen, damit Sie den Unterschied zwischen einem Konfigurationsfehler und einer Quelle erkennen können, die während der Hauptsendezeit einfach überlastet ist.

Wie die Polsat Box-Verschlüsselung zu einer Paketwahl passt

Hier ist das, was niemand klar erklärt: Es gibt kein "Paket"-Feld irgendwo in CCcam oder OScam. Es gibt eine CAID (Conditional Access ID) und eine Anbieter-ID (provid), und manchmal einen SID (Service ID)-Filter obendrauf. Wenn jemand sagt, dass er ein Polsat Box CCcam/OScam-Paket für Cardsharing 2026 benötigt, was er tatsächlich braucht, ist das spezifische CAID:provid-Paar, das derzeit auf der Karte aktiv ist, plus welche SID-Liste die HD- oder regionalen Varianten steuert.

Marketingstufen — die Dinge, die auf einer Abonnementrechnung gedruckt sind — existieren auf Protokollebene nicht. Ein "Premium"-Bouquet und ein "Standard"-Bouquet könnten die exakt gleiche CAID teilen und sich nur darin unterscheiden, welche SIDs die Karte Rechte hat. Wenn Sie also eine Konfiguration erstellen, vergessen Sie den Tiernamen vollständig und suchen Sie die Zahlen.

CAID- und Anbieter-ID-Identifikation

Zwei Stellen, die Sie überprüfen sollten. Zuerst, wenn Sie eine physische Karte in einem Leser haben, melden Sie sich bei der OScam-Weboberfläche an und gehen Sie zuStatus> Leser. Klicken Sie auf den Lesernamen und Sie sehen die ATR (Answer To Reset)-Zeichenfolge zusammen mit den CAIDs, die die Karte meldet. Zweitens — und das ist das, was tatsächlich für die Live-Fehlerbehebung wichtig ist — stimmen Sie auf einen Zielkanal ein und beobachten Sie das ECM-Protokoll. Sie werden Zeilen sehen wie:

reader (local) ECM 0100:000000 (crc=xxxxxx) gefunden von Leser in 210 ms

Das0100 ist Ihre CAID (Nagravision verwendet historisch den Bereich 0100-01FF), und die sechs hexadezimalen Ziffern danach zerfallen in die Anbieter-ID. Vertrauen Sie nicht auf eine Nummer, die Sie in einem Forum aus dem Jahr 2023 gefunden haben — Verschlüsselungssysteme rotieren, und die Polsat Box hat die Anbieter-IDs schon einmal ohne viel öffentliche Bekanntmachung geändert. Bestätigen Sie es live, jedes Mal, wenn Sie eine neue Quelle einrichten.

Warum das 'Paket'-Konzept sich von einem Kanalbouquet unterscheidet

Ein Bouquet ist eine Liste von Kanälen, die für Marketingzwecke gruppiert sind. Ein Paket, im Sinne von CCcam/OScam, ist jede Gruppe von SIDs, für die Ihre Karte oder Ihr Share tatsächlich Berechtigungsbits auf der EMM-Seite gesetzt hat. Sie können die richtige CAID haben und trotzdem einen schwarzen Bildschirm auf drei Kanälen in einem Bouquet erhalten, weil die EMM niemals Rechte für diese spezifischen SIDs gewährt hat. Das bringt viele Leute durcheinander, die annehmen, "CAID stimmt überein, also sollte alles in dieser Stufe geöffnet werden."

Lesen der ECM/EMM-Pipeline, bevor Sie entscheiden

Bevor Sie eine einzige Zeile Konfiguration schreiben, verbringen Sie zwanzig Minuten damit, nur Protokolle zu beobachten. ECMs kommen ungefähr alle paar Sekunden pro Kanal und werden (oder nicht) von dem Leser in Ihrer Kette beantwortet, der tatsächlich Rechte hat. EMMs aktualisieren Berechtigungen periodisch im Hintergrund — wenn diese nicht korrekt verarbeitet werden, kann ein Kanal, der gestern geöffnet wurde, heute dunkel werden, selbst bei unveränderter CAID. Dies ist die Pipeline, um die Sie den Rest der Konfiguration aufbauen.

OScam Leser-Konfiguration für ein Nagravision-Stil-Paket

Vorausgesetzt, Sie haben Ihre CAID live bestätigt, anstatt zu raten, hier ist, wie die tatsächlichen Konfigurationsdateien zusammenkommen. Die Pfade variieren je nach Image — ich werde die gängigen kennzeichnen — aber die Logik ist überall identisch.

oscam.server Leserblock-Beispiel

Auf den meisten Linux-basierten Receivern befindet sich diese Datei unter/var/etc/oscam.server; auf einigen enigma2-Images befindet sie sich unter/etc/tuxbox/config/oscam.server. Ein sanierter Leserblock, der auf eine einzige Identität beschränkt ist, sieht so aus:

Beachten Sie die Platzhalter — 203.0.113.10 ist eine dokumentationsreservierte IP, kein echter Host. Jeder Wert hier muss von Ihrer eigenen Karte oder Ihren eigenen Share-Anmeldeinformationen stammen, niemals von einem Forenbeitrag übernommen werden.

oscam.dvbapi CAID/Anbieterfilterung

Diese Datei —/var/etc/oscam.dvbapi auf den meisten Images — ist das, was tatsächlich steuert, welche CAID/provid-Kombinationen an den Demuxer gesendet werden. Ohne einen Filter hier wird OScam versuchen, ECMs für jede CAID anzufordern, die es im Stream sieht, was Zyklen verschwendet und Verzögerungen beim Zappen verursachen kann.

Koppeln Sie das mit einer CAID/provid-Einschränkung direkt am Leser (dieident Zeile oben macht dies) anstatt zu versuchen, auf der dvbapi-Ebene mit Wildcards zu filtern — es ist vorhersehbarer und einfacher zu debuggen, wenn etwas nicht mehr funktioniert.

AU (Auto-Update) und EMM-Verarbeitung

Einstellungau = 1 sagt OScam, EMMs zu verarbeiten und die Berechtigungen automatisch aktuell zu halten. Schalte dies aus (au = 0) nur, wenn du ein reines CCcam-Share ohne lokale Karte verwendest — ein Remote-Share verarbeitet die EMMs auf der Serverseite, und das lokale Ausführen von AU gegen eine Share-Verbindung bringt nichts Nützliches und erzeugt nur Log-Geräusche.

ecmwhitelist und ident-Zeilen

Wenn du einen Reader hart auf ein bestimmtes Paket festlegen möchtest, anstatt ihn für alles antworten zu lassen, wofür er technisch könnte, verwende eine ecmwhitelist-Datei, die in oscam.server referenziert wird, oder halte einfach dieident = CAID:PROVID Zeile eng. Ein Reader mit einer breiten Ident-Liste wird gerne versuchen, ECMs zu beantworten, für die er keine echten Rechte hat, was genau die intermittierenden schwarzen Bildschirme verursacht, die im nächsten Abschnitt behandelt werden.

CCcam.cfg Entsprechende Einrichtung und F-Line/C-Line Hygiene

Wenn du die tatsächliche CCcam-Binärdatei anstelle der cccam-Client-Emulation von OScam verwendest, befindet sich die Datei unter/var/etc/CCcam.cfg auf den meisten Receiver-Images, obwohl ich Boxen gesehen habe — insbesondere ältere Dreambox-Images — die sie unter/usr/keys/CCcam.cfg speichern. Wenn du die Datei bearbeitest und sich beim Neustart nichts ändert, ist das fast immer der Grund: Du hast eine Kopie bearbeitet, die die Box tatsächlich nicht liest. Überprüfe beide Pfade, bevor du annimmst, dass der Daemon defekt ist.

C-Line-Client-Eintragsstruktur

Eine C-Line definiert eine ausgehende Verbindung zu einem Share, von dem du ziehst:

Einfach, aber der Port ist wichtig — 12000 ist der Standardport von CCcam, obwohl viele Betreiber auf benutzerdefinierten Ports für Lastverteilung oder zur Umgehung von zufälligem Scannen arbeiten. Bestätige den Port mit demjenigen, der die Verbindung bereitstellt, anstatt anzunehmen, dass 12000 immer gilt.

F-Line-Servereintrag und Hop-Limits

F-Lines definieren, was du nach außen bereitstellst, wenn du deine eigene Karte teilst. Für eine paketbezogene Einrichtung möchtest du dies im Allgemeinen eng halten, anstatt offen:

Das dritte Feld ist maxhop. Hop 1 bedeutet, dass der Client nur Karten sieht, die einen Schritt vom Ursprung entfernt sind — niedrigere Hop-Zahlen bedeuten geringere Latenz und weniger Ausfallpunkte. Hop 2 oder 3 führt mehr Knoten in die Kette ein, und jeder zusätzliche Hop erhöht sowohl die Latenz als auch das Risiko von Instabilität. Wenn die ECM-Zeiten inkonsistent sind, ist die Hop-Tiefe eines der ersten Dinge, die zu überprüfen sind.

SID-Zuweisung und CAID-Scoping

CCcam.cfg unterstützt das Scoping von Shares auf spezifische SIDs mithilfe einer Blocksyntax, die an eine Zeile angehängt wird:

Das{ caid:provid:sid,sid,sid } Block beschränkt die Verbindung darauf, nur ECMs für diese genauen Dienste anzufordern. Es ist das Nächste, was CCcam zu einem expliziten Paket-Scoping hat, und es ist wert, es absichtlich zu verwenden — eine ungescoppte C-Line wird alles ziehen, was sie kann, was das Debuggen viel schwieriger macht, wenn etwas nicht öffnet.

Sharelimit und Node-ID-Überlegungen

Wenn du Karten nach außen bereitstellst, setze ein Sharelimit, damit eine einzelne Quelle nicht unter zu vielen gleichzeitigen Client-Verbindungen überlastet wird — dies ist serverseitige Hygiene, nicht etwas, worum sich eine Client-only Einrichtung kümmern muss. Stelle auch sicher, dass deine Node-ID wirklich einzigartig pro Box ist; doppelte Node-IDs über mehrere Installationen im selben Share-Netzwerk verursachen Verbindungsrücksetzungen, die genau wie eine instabile Quelle aussehen, wenn sie tatsächlich eine Konfigurationskollision sind.

Fehlerbehebung bei Freezes, ECM-Timeouts und Zapping-Verzögerungen

Hier leben oder sterben die meisten Setups tatsächlich. Alles oben bringt dich online — dieser Abschnitt handelt davon, es anschaubar zu halten.

DVBAPI-Protokolle lesen und ECM-Zeit (ms)

Aktiviere das Protokollieren in eine Datei (setzelogfile in oscam.conf, normalerweise auf etwas wie/tmp/.oscam/oscam.log) und beobachte die ECM-Antwortzeiten, die auf jeder Zeile gemeldet werden. Diese Zahl ist alles:

• Unter ~400ms — flüssig, keine sichtbare Auswirkung auf das Bild
• 400–700ms — marginal, Sie könnten ein kurzes Stottern bei Szenenwechseln bemerken
• Über 1000ms — hier beginnt das tatsächliche Einfrieren, da der Decoder keine gepufferten Frames mehr hat, die auf den Schlüssel warten

Ich hatte Quellen, die um 2 Uhr morgens konstant 180ms liefen und bis 20 Uhr über 900ms stiegen — dieselbe Konfiguration, dieselbe CAID, nichts hat sich auf meiner Seite geändert. Das ist ein Lastproblem auf der Quelle, nichts, was Sie lokal beheben können.

Einfrieren alle paar Sekunden vs. schwarzer Bildschirm

Das sind zwei verschiedene Fehlermodi und die Leute verwechseln sie ständig. Periodisches Einfrieren (Bild stottert alle paar Sekunden, erholt sich aber) bedeutet fast immer hohe ECM-Zeit oder einen instabilen Hop irgendwo in der Kette — der Decoder hat intermittierend Hunger. Ein harter schwarzer Bildschirm von Anfang an, ohne jemals ein Bild zu sehen, bedeutet normalerweise falsche CAID/provid ganz oder eine CAID, die korrekt ist, aber keine tatsächlichen Berechtigungen für diese SID hat. Überprüfen Sie das Protokoll: Wenn Sie sehen, dass ECMs angefordert und beantwortet werden, ist es ein Timing-Problem. Wenn Sie "nicht gefunden" oder überhaupt keinen ECM-Verkehr für diese CAID sehen, ist es ein Rechte- oder Konfigurationsproblem.

Interpretation der OScam-Statusfarben (grün/gelb/rot)

Auf der Webif-Statusseite werden Leser als grün (Karte oder Share online und antwortet korrekt), gelb (verbunden, aber mit aktuellen Fehlern oder verzögerten Antworten) oder rot (nicht antwortend / Verbindung down) angezeigt. Ein Leser, der während der Spitzenzeiten zwischen grün und gelb flackert, erzählt Ihnen dieselbe Geschichte wie ein ansteigendes ECM-Zeitdiagramm — es ist ein Last- oder Stabilitätsproblem bei dieser speziellen Quelle, nicht unbedingt bei Ihrem Gerät.

Netzwerk-Jitter, Port- und Firewall-Überprüfungen

Bevor Sie die Quelle beschuldigen, schließen Sie Ihr eigenes Netzwerk aus. Testen Sie die grundlegende Erreichbarkeit mit:

telnet 203.0.113.10 12000

oder, wenn telnet nicht installiert ist:

nc -vz 203.0.113.10 12000

Eine Verbindung abgelehnt oder Timeout bedeutet, dass entweder der Port falsch ist, eine Firewall im Weg ist oder — zunehmend häufig im Jahr 2026 — Sie hinter CGNAT oder auf einer IPv6-only-Verbindung sind, die versucht, eine Quelle zu erreichen, die nur auf einem direkten IPv4-Port lauscht. Wenn das Ihre Situation ist, benötigen Sie entweder ein IPv4-Tunnel, ein VPN mit einem statischen Endpunkt oder eine Quelle, die IPv6 direkt unterstützt. Überprüfen Sie auch MTU, wenn Sie sporadische Ausfälle sehen, anstatt eines harten Fehlers — fragmentierte Pakete bei einigen ISP-Setups verursachen genau die Art von intermittierendem Einfrieren, die schwer zu diagnostizieren ist, da sie identisch mit einer Quelle-seitigen ECM-Verzögerung aussieht.

Auswahl einer Paketquelle: Allgemeine Auswahlkriterien

Ich werde Sie nicht auf einen bestimmten Anbieter hinweisen — teilweise, weil sich die Zuverlässigkeit von Monat zu Monat ändert, und teilweise, weil die einzigen Messungen, die zählen, die sind, die Sie selbst durchführen. Hier ist, was Sie tatsächlich testen sollten, bevor Sie sich langfristig für ein Polsat Box CCcam/OScam-Paket für die Cardsharing 2026-Setup entscheiden.

Stabilitäts- und Uptime-Signale, die Sie selbst testen sollten

Führen Sie jede Kandidatenquelle mindestens 3-4 Tage lang aus, bevor Sie ihr vertrauen. Protokollieren Sie die ECM-Zeiten zu verschiedenen Tageszeiten — morgens, nachmittags und insbesondere zur Hauptsendezeit (ungefähr 19-23 Uhr lokal), da dies die Zeit ist, in der geteilte Quellen am stärksten belastet werden. Eine Quelle, die es wert ist, behalten zu werden, zeigt konsistente Zahlen über dieses gesamte Zeitfenster, nicht nur um 3 Uhr morgens, wenn sonst niemand verbunden ist.

Lokale Karte vs. Remote-Share-Abwägungen

Eine lokale physische Smartcard in Ihrem eigenen Leser gibt Ihnen Hop 0 oder Hop 1 und entfernt die Netzwerkabhängigkeit vollständig aus dem ECM-Pfad — die einzige Latenz ist die Reaktionszeit Ihres eigenen Kartenlesers, typischerweise unter 100ms. Ein Remote-Share fügt mindestens einen Netzwerk-Hop hinzu plus die Last, die die Quelle trägt. Lokal ist von Natur aus stabiler, erfordert jedoch, dass Sie tatsächlich eine gültige Karte und einen Leser besitzen. Remote ist bequemer, bindet jedoch Ihre Bildqualität an die Uptime eines anderen und die Last in den Spitzenzeiten eines anderen.

Latenz, Hop-Anzahl und Share-Tiefe

Bei der Bewertung eines Shares fragen Sie, bei welcher Hop-Anzahl Sie sich befinden. Hop 1 von der ursprünglichen Karte ist bedeutend stabiler als Hop 3 durch eine Kette von Wiederverkäufern, da jeder zusätzliche Hop einen weiteren Punkt darstellt, an dem eine unterbrochene Verbindung oder eine überlastete Zwischenbox Ihre ECM-Zeit beeinträchtigt. Wenn Sie keine klare Antwort zur Hop-Tiefe erhalten können, betrachten Sie das als einen eigenen Datenpunkt.

Warnsignale in einer unzuverlässigen Quelle

Achten Sie auf ECM-Zeiten, die wild schwanken, anstatt in einem stabilen Bereich zu bleiben, häufige Trennungen, die Neustarts des Lesers erzwingen, und — die häufigste Beschwerde, die ich sehe — Shares, die in der ersten Woche gut funktionieren und dann still verschwinden, sobald die Zahlung erfolgt ist. Nichts davon ist etwas, das eine Konfigurationsänderung behebt. Es ist ein Signal, weiterzuziehen und anderswo mit derselben Methodik erneut zu testen: Ihre eigenen Protokolle, über mehrere Tage, zu Spitzen- und Nebenzeiten.