CCcam Server Kanäle: Setup, Konfiguration & Troubleshooting

Wenn Sie nach der Einrichtung von CCcam auf einen schwarzen Bildschirm oder ein eingefrorenes Bild starren, sind Sie hier richtig. Das Verstehen, wie cccam server channels auf Protokollebene tatsächlich funktionieren — nicht nur "eine C-Line hinzufügen und hoffen, dass es funktioniert" — ist das, was ein zuverlässiges Setup von einem frustrierenden unterscheidet. Diese Anleitung setzt voraus, dass Sie CCcam installiert haben, mindestens eine C-Line oder lokale Karte konfiguriert haben, und dass bestimmte Kanäle entweder fehlen, einfrieren oder sich weigern zu dekodieren.

Wie CCcam Karten Kanälen zuordnet

Hier ist das, was die meisten Anleitungen völlig überspringen: CCcam hat kein Konzept von "Kanälen" in der Art, wie es Ihr EPG tut. Es speichert keine Liste von "Sky Sports HD, BBC One, Eurosport." Was es speichert, sind numerische Tupel — CAID, Provider-ID und SID — und es vergleicht ECM-Anfragen mit diesen Tupeln. Wenn das Tupel passt und die Karte dekodieren kann, erhalten Sie ein Kontrollwort. Wenn nicht, schwarzer Bildschirm.

Was ein 'Kanal' auf Protokollebene bedeutet

Auf der DVB-Ebene sendet jeder verschlüsselte Kanal ein ECM-Paket (Entitlement Control Message) neben dem Videostrom aus. Dieses ECM enthält die CAID, die das CA-System, das es verschlüsselt hat, identifiziert. Ihr Receiver sendet dieses ECM an CCcam, das es an eine Karte weitergeleitet, die die CAID erkennt. Die Karte dekodiert es und gibt ein Kontrollwort zurück. Dieses Kontrollwort entschlüsselt das Video.

Also "Kanal funktioniert nicht" bedeutet fast immer, dass das ECM-Routing irgendwo fehlgeschlagen ist — entweder die CAID wurde nicht verglichen, die Karte hatte nicht die richtige Berechtigung, oder die Antwort hat zu lange gedauert. Das ist das mentale Modell, das Sie brauchen.

CAID, Provider-ID und SID: Die drei Identifikatoren, die zählen

Diese drei Nummern definieren den Kanalzugriff in CCcam vollständig:

• CAID — Conditional Access ID. Identifiziert den CA-Anbieter. Zum Beispiel ist 0x0500 Viaccess, 0x0600 Irdeto, 0x1800 Nagravision. Dies ist das erste Filter in der Routing-Kette.
• Provider-ID — Ein Teil-Namespace innerhalb des CA-Systems. Eine einzelne Karte mit CAID 0x0500 könnte die Provider-IDs 032830, 042800 und 040810 tragen — jede stellt einen anderen Betreiber oder Paket dar.
• SID — Service-ID. Der tatsächliche Kanalidentifizierer innerhalb eines Transponders. Dies ist das, was "dieser spezifische Kanal" in der Kanalliste Ihres Receivers zuordnet.

CCcam leitet eine ECM-Anfrage weiter, indem zuerst die CAID verglichen wird, dann die Provider-ID, dann wird versucht zu dekodieren. Die SID wird nicht für das Routing verwendet — es ist die Abonnement-Stufe der Karte, die bestimmt, ob das Kontrollwort für eine bestimmte SID gültig zurückkommt.

Wie CCcam seine interne Kanalliste aus verbundenen Karten erstellt

Wenn CCcam startet und eine Karte eingeführt wird (oder eine C-Line verbunden ist), liest CCcam die ATR der Karte und führt eine erste Berechtigungsprüfung durch. Es erstellt eine interne Tabelle, auf welche CAIDs und Provider-IDs diese Karte antwortet. Diese Tabelle ist das, was Sie in t

Wichtig ist: CCcam zählt nicht im Voraus alle SIDs auf, die eine Karte entschlüsseln kann. Es entdeckt dies nur dynamisch, wenn eine ECM-Anfrage eingeht. Die Web-Benutzeroberfläche zeigt Ihnen also CAIDs und Anbieter — keine vorgefertigte Kanalliste. Sie werden nicht wissen, dass eine bestimmte SID beschädigt ist, bis Sie versuchen, sie einzustellen.

Unterschied zwischen dem Tier/Paket einer Karte und dem Raw-CAID-Zugriff

Das überrascht viele Leute. Eine Karte kann CAID 0x0919 (Nagravision) präsentieren und Provider-ID 000000 sichtbar machen — aber nur ein grundlegendes Abonnementtier haben. Premium-Kanäle auf diesem CAID und Anbieter liefern ein ungültiges Kontrollwort oder gar keine Antwort, weil die Karte einfach nicht über die Berechtigung verfügt.

CCcam kann Ihnen nicht im Voraus mitteilen, welche SIDs innerhalb eines Kartenabonnements liegen. Es wird einen Entschlüsselungsversuch durchführen und einen Fehler protokollieren. Das ist die einzige Möglichkeit, um es herauszufinden — Entschlüsselung versuchen und die ECM-Antwort im Protokoll lesen.

CCcam so konfigurieren, dass bestimmte Kanäle freigegeben werden

Die Hauptkonfigurationsdatei befindet sich auf den meisten Linux-Boxen und Enigma2-Receivern unter /etc/CCcam.cfg. Alles, was kontrolliert, welche Kanäle freigegeben, gefiltert oder blockiert werden, befindet sich hier. Gehen wir die Direktiven durch, die wirklich wichtig sind.

CCcam.cfg-Syntax für Kanal- und CAID-Filterung

Die grundlegende Struktur verwendet Direktiven in Großbuchstaben gefolgt von einem Doppelpunkt und dem Wert. Leerzeichen sind flexibel. Kommentare verwenden #. Hier ist ein minimales funktionierendes Beispiel, das die Kontrolle auf CAID-Ebene handhabt:

# /etc/CCcam.cfg
PORT: 12000
NEWCAMD PORT: 15050 01020304050607080910111213141516
C: peer.example.com 12000 username password
IGNORE CAID: 0500
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0919 PROVID: 000001
SHARE LIMIT: 1
DEBUG: 1
HTTP PORT: 16001

Die Zeile IGNORE CAID: 0500 teilt CCcam mit, alle ECM-Anfragen oder Freigaben mit Viaccess (0500) zu verwerfen. Die PROVIDE CAID-Zeilen akzeptieren bestimmte CAID/Anbieter-Kombinationen. Wenn Sie beide verwenden, hat IGNORE Vorrang für die aufgelisteten CAIDs.

Verwendung von IGNORE- und PROVIDE-Direktiven zum Akzeptieren oder Blockieren von CAIDs

Wenn Sie alles außer einem CA-System zulassen möchten, verwenden Sie IGNORE. Wenn Sie eine strikte Whitelist-Kontrolle möchten, kombinieren Sie IGNORE CAID: ALL mit expliziten PROVIDE-Zeilen. Das ALL-Schlüsselwort ist eine echte Direktive — es weist CCcam an, alle nicht explizit bereitgestellten CAIDs abzulehnen.

IGNORE CAID: ALL
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0600 PROVID: 000000

Dies sperrt Ihren Server so, dass nur diese zwei CAID/Anbieter-Kombinationen zulässig sind. Alles andere — einschließlich eines Clients, der Viaccess-Kanäle anfordert — wird stillschweigend verworfen. Nützlich, wenn Sie eine bestimmte Karte freigeben und nicht verwandte CAIDs von Upstream-Peers nicht offenlegen möchten.

Einschränkung der Freigabe auf bestimmte Provider-IDs

Die Provider-ID-Filterung ist präziser als die CAID-Filterung. Sie könnten eine Karte mit CAID 0x0500 und drei Provider-IDs haben — eine für e

IGNORE CAID: 0500
PROVIDE CAID: 0500 PROVID: 032830

Dies macht nur das Paket des Anbieters 032830 unter Viaccess verfügbar und blockiert die anderen Provider-IDs von dieser Karte. Sauber und effektiv für die Freigabe von Teilabos.

Festlegung von SHARE LIMIT und Hop Count zur Steuerung der Kanalausbreitung

Die Direktive SHARE LIMIT steuert, wie viele Hops stromabwärts eine Freigabe reisen kann. Das Setzen auf 0 bedeutet, dass nur Ihre lokale Karte geteilt wird — keine Weitergabe von Karten, die Sie von vorgelagerten Peers erhalten haben. Das Setzen auf 1 bedeutet, dass Sie Ihre lokale Karte einen Hop stromabwärts teilen. Höhere Werte ermöglichen mehr Hops.

SHARE LIMIT: 1

Die RESHARE-Direktive auf Benutzerebene funktioniert anders — sie steuert, ob ein bestimmter verbundener Client das, was er von Ihnen erhält, weiter teilen kann. Ein Wert von 0 bedeutet kein Reshare; 1 bedeutet, dass er einen Hop weitergeben kann. Dies ist wichtig, wenn Sie sehen, dass Ihre CCcam-Server-Kanäle auf Servern erscheinen, die Sie nicht autorisiert haben.

Die Dateien CCcam.providers und CCcam.channelinfo erklärt

Diese beiden Dateien verwirren die Leute, weil sie funktional aussehen, aber nicht sind. Beide sind nur kosmetisch.

/usr/share/CCcam/CCcam.providers ordnet Provider-IDs menschenlesbaren Betreibernamen zu. Es macht Ihre Logs „Viasat" statt „042800" anzeigen. Es hat absolut keine Auswirkung auf die Kanäle, die entschlüsselt werden. Dasselbe gilt für /usr/share/CCcam/CCcam.channelinfo — es ordnet SIDs Kanalnamen für die Protokolllesbarkeit zu. Nützlich zum Debuggen, irrelevant für die Entschlüsselung.

Das Channelinfo-Format ist ein Eintrag pro Zeile: SID in Hexadezimal, dann der Kanalname. Zum Beispiel:

1234 BBC One HD
5678 Sky Sports 1

Platzieren Sie die Datei dort, wo Ihre CCcam.cfg darauf verweist. Falls sie fehlt, greift CCcam einfach auf die Protokollierung von rohen Hexadezimalwerten zurück.

Überprüfung der Kanäle, die Ihr Server entschlüsseln kann

Sie sollten nicht raten, ob Ihr Server einen Kanal entschlüsseln kann. CCcam bietet Ihnen eine integrierte HTTP-Schnittstelle und Protokollausgabe, die Ihnen genau zeigen, was vor sich geht — wenn Sie wissen, wie man sie liest.

Lesen der CCcam-Webschnittstelle (Port 16001) zur Überprüfung aktiver CAIDs

Standardmäßig macht CCcam eine Web-UI auf Port 16001 verfügbar. Stellen Sie sicher, dass Ihre CCcam.cfg folgendes hat:

HTTP PORT: 16001

Dann rufen Sie http://<your-receiver-ip>:16001 in einem Browser auf. Sie sehen Abschnitte für verbundene Karten, aktive Clients, Freigaben und ECM-Verlauf. Der Bereich Karten ist Ihr Ausgangspunkt — er listet die CAID, Provider-ID, Hop-Anzahl und das Reshare-Level jeder Karte auf.

Ein wichtiger Fallstrick: Wenn Sie CCcam hinter NAT ausführen und Port 12000 für Clientverbindungen weitergeleitet haben, ist Port 16001 separiert und benötigt eine eigene Weiterleitungsregel. Viele leiten den CCcam-Clientport weiter, vergessen aber ``````html der HTTP-Port, dann fragen sie sich, warum sie die Web-UI von außerhalb des LAN nicht sehen können.

Interpretieren der Abschnitte "Cards" und "Shares" in der Web-UI

Der Abschnitt "Cards" zeigt hop=0 für lokal eingefügte physische Karten. Hop=1 bedeutet, dass sich die Karte einen C-line Weg entfernt befindet, hop=2 bedeutet zwei Sprünge, und so weiter. Mit zunehmender Hop-Anzahl nimmt die Latenz zu und die Zuverlässigkeit nimmt tendenziell ab.

Der Abschnitt "Shares" zeigt, welche nachgelagerten Clients verbunden sind und worauf sie zugegriffen haben. Wenn ein Client verbunden ist, aber die Share-Tabelle keine Aktivität für eine bestimmte CAID anzeigt, fordern sie diese entweder nicht an, oder deine Filter blockieren sie, bevor sie sie erreichen.

Verwendung der CCcam-Protokollausgabe zur Verfolgung einer fehlgeschlagenen ECM-Anfrage

Stellen Sie DEBUG: 1 in CCcam.cfg für grundlegende ECM-Verfolgung ein. Für ausführlichere Ausgaben verwenden Sie DEBUG: 3, aber rechnen Sie mit großen Protokolldateien. Eine erfolgreiche ECM-Antwort sieht wie folgt aus:

ECM 0919/000000/1234 answered in 320ms by card 1

Ein Fehler sieht wie einer dieser aus:

ECM 0919/000000/1234 - no card found
ECM 0919/000000/1234 - timeout after 3000ms
ECM 0919/000000/1234 - card returned error

"No card found" bedeutet, dass keine Karte in Ihrem Pool dieser CAID/Provider-Kombination entspricht — überprüfen Sie Ihre IGNORE/PROVIDE-Filter. "Timeout" bedeutet, dass eine Karte gefunden wurde, aber nicht rechtzeitig antwortete — ein Latenzzeitproblem. "Card returned error" bedeutet normalerweise, dass die Abonnementzugriffswahrung für diese SID fehlt.

Kreuzreferenzierung von SID gegen eine DVB-Kanaldatenbank

Wenn Sie nicht sicher sind, welche CAID und SID ein bestimmter Kanal verwendet, müssen Sie die roh PMT ansehen. Die Tools dvbsnoop und tzap (Teil des dvb-apps-Pakets unter Linux) ermöglichen es Ihnen, einen Transponder zu wählen und die Dienstinformationen auszugeben.

tzap -c /etc/channels.conf "BBC One HD"
dvbsnoop -s pmt 1234

Die PMT-Ausgabe zeigt die CA-Deskriptor-Einträge einschließlich der CAID und der ECM-PID. Vergleichen Sie diese Werte mit dem, was CCcam in der Web-UI anzeigt. Wenn die CAID in der PMT nicht in Ihrer Kartentabelle vorhanden ist, ist das dein Problem.

Testen der Entschlüsselung mit einem einzelnen bekannten Kanal vor der Skalierung

Bevor Sie mehrere C-Lines oder komplexe Filterregeln hinzufügen, testen Sie mit einem Kanal, der funktionieren sollte. Wählen Sie einen Kanal, dessen CAID Sie aus der PMT überprüfen können, bestätigen Sie, dass diese CAID in der Web-UI-Kartentabelle angezeigt wird, und versuchen Sie, sie zu wählen. Lassen Sie einen Kanal sauberes Entschlüsseln, dann erweitern Sie. Dies isoliert Konfigurationsprobleme von Abonnementproblemen.

Häufige Gründe, warum Kanäle fehlen oder nicht entschlüsselt werden

Dies sind die Fehler, die ich am häufigsten sehe, in grober Reihenfolge ihrer tatsächlichen Häufigkeit. Jeder hat einen bestimmten Diagnosepfad.

Karte hat nicht das Abonnementpaket für diesen Kanal

Die CAID stimmt überein, die Provider-ID stimmt überein, aber der Kanal ist schwarz. Das Protokoll sagt "card returned error." Dies ist ein Problem mit der Abonnementtierenstufe — die Karte hat einfach keine Berechtigung für diese SID. Th ```Hier ist keine Konfigurationsanpassung möglich. Entweder enthält das Abonnement diesen Kanal nicht oder die EMM-Aktualisierungen sind abgelaufen (siehe unten).

CAID-Nichtübereinstimmung zwischen Client-Anfrage und Server-Karte

Einige Kanäle werden gleichzeitig auf mehreren CAIDs ausgestrahlt (sogenannte Überkapselung). Ihr Receiver könnte den Kanal mit CAID 0x0606 anfordern, während Ihre Karte nur CAID 0x0600 verarbeitet. Das Protokoll zeigt „keine Karte gefunden", obwohl Sie konzeptionell eine Karte für diesen Kanal haben. Die Lösung besteht darin, die tatsächliche PMT auf alle CA-Deskriptoren zu überprüfen und zu überprüfen, welche CAID Ihre Karte verarbeitet. In OScam-Bridged-Setups können Sie die CAID-Priorität konfigurieren. In reinem CCcam müssen Sie möglicherweise den Client zwingen, eine bestimmte CAID anzufordern.

Provider-ID in CCcam.cfg herausgefiltert

Überprüfen Sie Ihre IGNORE/PROVIDE-Regeln. Falls Sie IGNORE CAID: ALL verwendet haben und vergessen haben, eine PROVIDE-Zeile für eine Provider-ID hinzuzufügen, wird dieses gesamte Paket stillschweigend gelöscht. Das Protokoll zeigt keinen ECM-Versuch, der diesen Anbieter erreicht. Gleichen Sie die Provider-ID aus der Web-Benutzeroberfläche mit Ihren PROVIDE-Zeilen in der Konfiguration ab.

Hop-Anzahl oder Weitergabe-Level zu niedrig eingestellt

Falls Sie eine C-Line zu einem Peer hinzugefügt haben und die Karten des Peers in Ihrer Web-Benutzeroberfläche mit hop=1 angezeigt werden, aber Ihre Downstream-Clients können nicht darauf zugreifen. Überprüfen Sie Ihr SHARE LIMIT. Ein SHARE LIMIT von 0 bedeutet, dass Sie nur hop=0 (lokale) Karten freigeben – die Karten des Peers werden nie mit Ihren Clients weitergegeben. Setzen Sie es auf 1, um eine Ebene der Weitergabe zu ermöglichen:

SHARE LIMIT: 1

Überprüfen Sie auch den RESHARE-Wert, der dem Peer in Ihrer C-Line-Konfiguration zugewiesen ist. Einige Builds unterstützen die Weitergabe-Ebene pro Peer in der C-Line-Syntax.

EMM-Aktualisierungen blockiert – Kartenberechtigung nicht aktualisiert

Dieses Problem zerstört Setups langsam. Falls RECEIVE EMM: no in Ihrer Konfiguration vorhanden ist (oder bei einigen Builds, die standardmäßig deaktiviert sind, fehlt), empfängt die Karte keine Berechtigungsaktualisierungsmeldungen aus der Ausstrahlung mehr. Mit der Zeit verfallen die Abonnementberechtigungen und Kanäle können nicht mehr entschlüsselt werden – oft zunächst mit Premium-Paketen.

RECEIVE EMM: yes

Stellen Sie dies ein und starten Sie CCcam neu. Je nachdem, wie lange EMM deaktiviert war, kann es mehrere Minuten bis zu einer Stunde dauern, bis die Karte alle ihre Berechtigungsaktualisierungen empfängt und verarbeitet. Zeitlich begrenzte Berechtigungen sind besonders anfällig – eine Karte, die einwandfrei funktionierte, kann mitten in einer Sitzung stille Kanäle nicht mehr entschlüsseln, da ihre gespeicherten Berechtigungen ohne Erneuerung ablaufen.

Netzwerklatenzen verursachen ECM-Timeouts bei schnell umschaltenden Kanälen

Das Standard-ECM-Timeout von CCcam beträgt 3000ms. Auf einem schnell umschaltenden Receiver oder beim schnellen Wechsel zwischen Kanälen müssen ECM-Anfragen vor dem Timeout abgeschlossen sein, sonst erhalten Sie einen „Timeout"-Fehler. Wenn Ihre Peer-Verbindung eine Roundtrip-Latenz von 150–200ms aufweist und die Kartenverarbeitung weitere 200–300ms hinzufügt, wird es eng.

Sie können das Timeout in CCcam.cfg anpassen:

ECM TIMEOUT: 5000

Die Erhöhung gibt langsamen Peers mehr Zeit

Newcamd oder CS378X-Protokollunterschiede beim Bridging zu OScam

Wenn Sie CCcam über das Newcamd-Protokoll zu OScam bridgen (konfiguriert mit NEWCAMD PORT: 15050 <DES-Schlüssel> in CCcam.cfg), führen Versionskonflikte oder DES-Schlüssel-Nichtübereinstimmungen zu stillen Fehlern bei bestimmten CAIDs. Der OScam-Eintrag /etc/oscam/oscam.server für die CCcam-Verbindung muss genau der Protokollversion entsprechen:

[reader]
label = cccam_bridge
protocol = cccam
device = 127.0.0.1,12000
user = username
password = password
caid = 0919,0500

Wenn einige CAIDs über die Brücke funktionieren und andere nicht, überprüfen Sie die CAID-Filterung auf beiden Seiten. OScam verfügt über einen eigenen CAID-Filter pro Reader, der CAIDs unabhängig von CCcams eigenen Filtern blockieren kann. Achten Sie auch auf CCcam-Versionskonflikte zwischen Server und Client — ältere CCcam-Versionen schlagen manchmal bei der Freigabeverhandlung für bestimmte CA-Systeme fehl, wenn sich die Protokollbehandlung unterscheidet.

Bewertung einer Remote-CCcam-Peer-Verbindung für die Kanalabdeckung

Eine C-Line von einem Peer zu erhalten ist erst der Anfang. Die C-Line selbst sagt Ihnen fast nichts darüber, welche cccam-Server-Kanäle tatsächlich über sie zugänglich sind.

Was eine C-Line Ihnen mitteilt — und was nicht

Eine C-Line sieht so aus:

C: hostname.example.com 12000 myuser mypassword

Das ist alles. Vier Felder: Host, Port, Benutzername, Passwort. Die C-Line enthält keine Informationen darüber, welche CAIDs, Provider-IDs oder SIDs der Peer teilt. Das erfahren Sie erst nach dem Verbinden und Überprüfen der Web-UI-Freigabentabelle. Jeder, der behauptet, „X Kanäle" in einer C-Line-Beschreibung anzubieten, erzählt Ihnen von der nominalen Abonnementabdeckung seiner Karte, nicht von dem, was Sie tatsächlich erhalten — diese Zahlen verschlechtern sich mit Hop-Anzahl, Serverlast und Filterkonfiguration.

So testen Sie eine C-Line, bevor Sie sich dafür entscheiden

Fügen Sie die C-Line zu Ihrer CCcam.cfg hinzu, starten Sie CCcam neu und überprüfen Sie sofort Port 16001. Innerhalb von 30-60 Sekunden sollten die Karten des Peers in der Karten-/Freigabentabelle angezeigt werden. Beachten Sie:

• Welche CAIDs werden angezeigt — entsprechen sie Ihren Anforderungen?
• Mit welcher Hop-Anzahl kommen sie herein? Hop=1 ist gut; hop=3 oder höher ist ein rotes Zeichen.
• Überprüfen Sie ECM-Antwortzeiten im Protokoll für einen bekannten Kanal. Konsistent unter 800ms ist solide; über 1500ms verursacht Probleme.
• Beobachten Sie die Verbindungsstabilität über 10-15 Minuten. Wenn der Peer wiederholt abbricht und sich erneut verbindet, ist das ein Zuverlässigkeitsproblem.

Allgemeine Kriterien zur Bewertung der Peer-/Server-Kanalqualität

Vertrauen Sie nicht einfach darauf, dass ein Peer gut ist, weil er verbunden ist. Bewerten Sie ihn ordnungsgemäß:

• Ping unter 200ms zum Server-Host aus Ihrem Netzwerk
• ECM-Antwortzeiten konsistent unter 1500ms im CCcam-Protokoll
• Karten erschei```html ring at hop=1 (direkt verbundene Karten, keine weitergeleitet Ketten)
• Keine übermäßigen Verbindungszyklen im CCcam-Protokoll über eine Stunde sichtbar
• Wenn der Peer behauptet, viele gleichzeitige Clients zu bedienen, prüfen Sie, ob sich die ECM-Antwortzeiten während der Spitzenlastzeiten verschlechtern — überlastete Server zeigen dies deutlich

Ein Peer, der Tausende von Kanälen über viele Hops bewirbt, ist fast immer eine Weiterleitungskette mit hoher Latenz und fragwürdiger Zuverlässigkeit. Lokale Karten bei hop=0 oder direkte Peers bei hop=1 sind das, was Sie für zuverlässige CCcam-Server-Kanäle möchten.

Überprüfung der Peer-Verfügbarkeit und der ECM-Antwortzeit über die CCcam-Web-Benutzeroberfläche

Die CCcam-Web-Benutzeroberfläche zeigt pro Verbindung ECM-Statistiken an, wenn Sie Debug-Protokollierung aktiviert haben. Schauen Sie sich den Abschnitt „Clients" an, um die Verbindungszeit und die ECM-Anzahl/Erfolgsquote zu sehen. Ein Peer, der 20 Stunden verbunden war mit 5.000 ECMs und nur 3 Ausfällen, ist solide. Ein Peer mit 40% Zeitüberschreitungsquoten in der ECM-Verlaufstabelle ist unbrauchbar — weiterziehen.

Verständnis des gemeinsamen Zugriffs im Vergleich zum dedizierten Kartenzugriff und dessen Auswirkung auf Kanäle

Gemeinsamer Zugriff bedeutet, dass eine physische Karte ECM-Anfragen für viele gleichzeitige Clients bedient. Jede ECM-Anfrage wird nacheinander auf der Karte verarbeitet — die Karte verarbeitet eine nach der anderen. Unter hoher Last steigen die Antwortzeiten an und Zeitüberschreitungen nehmen zu. Deshalb frieren CCcam-Server-Kanäle auf einem stark belasteten gemeinsam genutzten Server während der Spitzenlastzeiten ein, obwohl die CAID vorhanden und das Abonnement gültig ist.

Dedizierter Zugriff — bei dem eine Karte nur Ihre Verbindung bedient — beseitigt Warteschlangen-Konflikte. ECM-Antworten bleiben schnell, unabhängig davon, was sonst noch passiert. Der Kompromiss besteht in Kosten und Verfügbarkeit. Bei der Bewertung eines Peers fragen Sie, ob die Karte unter vielen Benutzern geteilt oder Ihnen speziell zugewiesen ist. Die Antwort erklärt viel über das, was Sie erleben werden.

Noch eine Sache, die Sie beachten sollten: DVB-S2-Kanäle mit ACM- oder VCM-Modulation erfordern Hardware, die variable Kodierung unterstützt. Wenn die Server-Tunerkarte ACM nicht unterstützt, kann sie diese Transponder nicht einmal empfangen — was bedeutet, dass die Karte für diese Kanäle unerreichbar ist, selbst wenn die CAID und das Abonnement perfekt gültig sind. Dies ist eine Hardware-Einschränkung auf der Serverseite, kein Softwarekonfigurationsproblem.