NCam ECM Timeout: So beheben Sie es (Vollständiger Leitfaden)

Wenn Sie nach einer Lösung für den NCam ECM Timeout suchen, haben Sie wahrscheinlich bereits Protokolle mit Zeilen wieECM (0x0963) Timeout (3000 ms) betrachtet, während die Kanäle während des Streams einfrieren oder schwarz werden. Der frustrierende Teil? Die meisten Ratschläge online sagen einfach "erhöhen Sie den Timeout-Wert" — was nichts behebt und tatsächlich die Einfrierzeiten länger erscheinen lässt. Dieser Leitfaden behandelt die tatsächlichen Ursachen, von defekten upstream Lesegeräten bis hin zu einem blockierten CI-Slot direkt auf Ihrem eigenen Gerät.

Bevor Sie irgendwelche Konfigurationen ändern, verstehen Sie, was Sie tatsächlich betrachten. Ein Timeout ist nicht dasselbe wie ein fehlgeschlagener Dekodierungsvorgang, und sie gleich zu behandeln, kostet Stunden.

Was ein ECM Timeout in NCam tatsächlich bedeutet

Jeder verschlüsselte Kanal sendet etwa alle 10 Sekunden ECMs — Entitlement Control Messages. Ihr NCam-Client fängt einen ein, sendet ihn an ein Lesegerät (eine lokale Karte, einen Netzwerkpeer, einen Emulator) und wartet auf ein Kontrollwort. Dieses Kontrollwort entschlüsselt tatsächlich den Stream. Wenn innerhalb des konfigurierten Zeitfensters keine Antwort zurückkommt, protokolliert NCam ein Timeout und versucht entweder erneut oder wechselt zu einem anderen Lesegerät.

Der ECM Anfrage/Antwort Zyklus erklärt

Der Ablauf ist: dvbapi fängt ECM aus dem Stream ein → NCam leitet es an das beste verfügbare Lesegerät basierend auf dem Lastenausgleich weiter → Lesegerät/Server dekodiert es mit der Karte → Kontrollwort zurückgegeben → dvbapi übergibt es an den Decoder. Die gesamte Rundreise auf einem gesunden Setup mit einem lokalen Lesegerät dauert typischerweise unter 300 ms. Bei einem Netzwerkpeer mit einem Hop könnten Sie 400–800 ms sehen. Wenn Sie konstant 1500+ ms sehen, wird das Timeout zu einer Frage des Wann, nicht des Ob.

Dieser ecm-timeout Wert (Standard 3000 ms in den meisten Builds) ist die Zeit, die NCam wartet, bevor es aufgibt, ein Lesegerät für diese spezifische ECM-Anfrage zu finden. Drei Sekunden erscheinen viel. Aber wenn Ihre Krypto-Periode 10 Sekunden beträgt und Sie 3 Sekunden warten, dann ein anderes Lesegerät erneut versuchen und dann weitere 3 Sekunden warten — sind Sie bereits in der nächsten Krypto-Periode ohne Kontrollwort. Der Bildschirm wird schwarz.

Die Timeout-Zeile in Ihrem NCam-Protokoll lesen

Eine typische Timeout-Zeile sieht etwa so aus:

2026/03/15 21:04:33 c (ecm) r=MyReader CAID: 0963 PROVID: 000000 SID: 12AB PID: 0200 LEN: 183 READER: timeout (3000 ms)

Das aufgeschlüsselt:0963 ist die CAID (das Verschlüsselungssystem — Sky in diesem Fall),000000 ist die Anbieter-ID,12AB ist die Dienst-ID (der spezifische Kanal), und3000 ms ist das abgelaufene Timeout-Fenster. Der Name des Lesegeräts (MyReader) sagt Ihnen, welche upstream Quelle nicht geantwortet hat. Das ist Ihr erster Hinweis.

Timeout vs. 'Nicht gefunden' vs. 'Abgelehnt' — Verschiedene Probleme

Das ist das, was fast niemand richtig erklärt. Diese drei Ergebnisse haben völlig unterschiedliche Ursachen:

• Timeout — Das Lesegerät war erreichbar, die Anfrage wurde gesendet, aber keine Antwort kam rechtzeitig zurück. Ursachen: hohe Latenz, überlasteter Server, tote Verbindung, lokales Signalproblem.
• Nicht gefunden — Das Lesegerät hat geantwortet, hat aber nicht die Karte/Entitlement für diese CAID oder diesen Anbieter. Falsche Karte, falsches Paket oder die Karte ist einfach nicht abonniert.
• Abgelehnt — Der Peer hat die Anfrage aktiv abgelehnt. Üblicherweise SID/CHID-Filterung auf der Serverseite oder ein gefälschtes ECM, das blockiert wird.

Wenn Sie ein Timeout mit Lösungen verfolgen, die für "nicht gefunden" gedacht sind — Überprüfen von Berechtigungen, Wechseln von Servern — werden Sie im Kreis laufen. Das Protokollschlüsselwort ist alles. Lesen Sie es zuerst.

Anpassen der Timeout- und Lesegeräteparameter

Die Speicherorte der Konfigurationsdateien variieren leicht je nach Build, aber auf den meisten Embedded-Linux-Setups (Enigma2-Boxen usw.) schauen Sie nach/etc/tuxbox/config/ oder/var/keys/. Auf einem Standalone-Server ist es typischerweise/etc/oscam/. Die Hauptdateien, mit denen Sie arbeiten werden, sindoscam.conf,oscam.server, undoscam.dvbapi.

ecm-timeout in [global] und Per-Reader

Die globale Einstellung befindet sich inoscam.conf unter dem[global] Block:

[global]

Sie können dies pro Reader inoscam.serverüberschreiben:

[reader]

Die Erhöhung des ecm-timeout von 3000 auf 5000 ms gibt langsamen Peers mehr Zeit zu antworten. Dies sorgt für stabiles Decodieren auf einem Grenzserver. Aber — und das ist wichtig — es bedeutet auch, dass jeder fehlgeschlagene ECM jetzt volle 5 Sekunden benötigt, bevor der Failover ausgelöst wird. Wenn Sie drei Reader haben und einer tot ist, wartet jeder Kanalwechsel potenziell 5 Sekunden pro totem Reader, bevor er auf den funktionierenden landet. Die Erhöhung des Timeouts, ohne das zugrunde liegende Problem zu beheben, verschlechtert die Benutzererfahrung, nicht verbessert sie.

lb_retrylimit und lb_reopen_seconds für Lastverteilung

Der Lastverteiler von NCam verfolgt, welche Reader gut funktionieren, und leitet neue ECMs entsprechend weiter. Zwei Einstellungen steuern, wie er mit schlechten Readers umgeht:

[global]

lb_retrylimit legt die ECM-Antwortzeit (in ms) fest, über der ein Reader herabgestuft wird. Bei 900 ms wird jeder Reader, der konstant länger braucht, von der Liste nach unten gedrängt.lb_reopen_seconds steuert, wie lange NCam wartet, bevor es einem schlechten Reader eine weitere Chance gibt — 900 Sekunden (15 Minuten) verhindert, dass er einen toten Peer bei jeder einzelnen ECM-Anfrage ständig anpingt und überall 3-Sekunden-Verzögerungen hinzufügt. Wenn dies zu niedrig eingestellt ist (wie 60 Sekunden) und Sie einen wirklich toten Upstream haben, versucht NCam ständig, ihn erneut zu erreichen, und jeder erneute Versuch ist ein weiterer Timeout, der Ihren Stream belastet.

cccmaxhops, cccwantemu und Reader-spezifische Limits

FürCCcam Protokoll-Reader,cccmaxhops begrenzt, wie viele Hops eine Karte durchlaufen kann, bevor NCam sie ignoriert. Halten Sie dies maximal bei 1 oder 2. Karten, die 3–5 Hops entfernt sind, sind für die ECM-Zeit wertlos — Sie fügen die Latenz mehrerer Zwischenserver hinzu.

[reader]

Setzen Siecccwantemu = 0 es sei denn, Sie möchten tatsächlich emulierte Karten von diesem Peer. Emulierte Einträge können im Lastverteiler erscheinen und bei echten verschlüsselten Kanälen fehlschlagen, was zu falschen Timeouts führt.

Wo die Konfigurationsdateien gespeichert sind und wie man sie neu lädt

Nach der Bearbeitung ist kein vollständiger Neustart erforderlich. Im NCam-Webinterface (normalerweise unterhttp://your-box:8888) gehen Sie zuKonfiguration → Neustart oder verwenden Sie die Schaltfläche Leser neu laden. Alternativ können Sie dem Prozess ein SIGHUP senden:killall -HUP oscam. Änderungen anoscam.server treten sofort nach dem Neuladen in Kraft. Änderungen anoscam.conf [global] erfordern normalerweise einen vollständigen Neustart desoscam Prozesses, nicht nur ein Neuladen des Lesers.

Netzwerklatenz und serverseitige Ursachen

Bevor Sie einen einzigen Konfigurationswert ändern, finden Sie heraus, wo die Verzögerung tatsächlich auftritt. Das Ändern des ecm-timeout, wenn das Problem ein defekter upstream-Leser ist, bringt nichts. Verbringen Sie zuerst 10 Minuten mit Messen.

Messung der Round-Trip-Zeit zum Upstream-Peer

Beginnen Sie mit einem einfachen Ping zur IP oder zum Hostnamen des Servers. Wenn Sie Ping-Zeiten von über 200 ms auf einem Server erhalten, der sich in Europa befinden sollte, ist das Ihr Problem. Gehen Sie dann tiefer mitmtr (Matt's Traceroute):

mtr --report --report-cycles 100 yourpeer.example.com

Dies zeigt Ihnen den Paketverlust und die Latenz pro Hop. Ein einzelner Hop mit 40% Paketverlust in der Mitte der Route verursacht intermittierende ECM-Timeouts, selbst wenn am anderen Ende ein gesunder Server vorhanden ist. Die Lösung liegt im Netzwerkpfad, nicht in der NCam-Konfiguration.

Jetzt vergleichen Sie mit dem NCam-Webinterface. UnterStatus zeigt die Spalte ECM-Zeit die tatsächlichen Antwortzeiten pro Leser an. Wenn Sie dort konstant 1200–1800 ms mit einem Timeout von 3000 ms sehen, leben Sie am Limit. Ein schlechter Moment und Sie haben einen Timeout.

MTU, Fragmentierung und Portprobleme (Standard 12000 Bereich)

Das CCcam-Protokoll läuft normalerweise auf Port 12000 (konfigurierbar in der Gerätezeile Ihres Lesers). Camd35 verwendet normalerweise 15000 oder 15001. Dies sind TCP-Verbindungen, daher sollte die MTU-Fragmentierung kein Problem darstellen — aber Firewall-Zustandstabellen können inaktive Verbindungen stillschweigend abbrechen.

Dies ist die Ursache für das Problem "Timeouts nach Inaktivität", das viele Menschen überrascht. Sie schauen 20 Minuten lang einen Kanal, stoppen, kommen eine Stunde später zurück, und er dekodiert nicht. Die Verbindung ist aus der Sicht von NCam technisch immer noch "aktiv", aber das NAT/die Firewall hat den Zustandseintrag gelöscht. Die Lösung: Aktivieren Sie TCP-Keepalives auf Betriebssystemebene oder konfigurieren Sie Ihren Router so, dass er einen längeren Timeout für die Verbindungsverfolgung für diese Ports verwendet. Bei OpenWrt-basierten Routern erhöhen Sienf_conntrack_tcp_timeout_established auf über 7200 Sekunden.

Überlasteter Server: ECM-Zeitspitzen unter gleichzeitiger Last

Eine einzelne physische Smartcard kann nur einen ECM gleichzeitig beantworten. Wenn ein Server 50 Clients hat, die eine Karte teilen, und alle 50 gleichzeitig einen Krypto-Zeitraum-Refresh anfordern, hat diese Karte eine Warteschlange. Die ECM-Zeit steigt auf 2000–3000 ms. Zu Stoßzeiten (Abende, Sportereignisse am Wochenende) wird es dramatisch schlimmer. Die Karte ist nicht defekt, der Server ist nicht falsch konfiguriert — es ist einfach Mathematik. Zu viele Clients pro Karte.

Sie werden dieses Muster deutlich sehen: ECM-Zeiten im Webinterface sind den ganzen Morgen über stabil bei 400 ms, steigen dann ab 19:00 Uhr auf 1800 ms. Das ist eine Überbuchung des Servers, Punkt. Kein Maß an lokaler NCam-Optimierung behebt das. Die einzige echte Lösung für ECM-Timeouts in NCam besteht darin, einen Server mit weniger Clients pro Karte zu finden oder einen zweiten Upstream-Peer mit derselben CAID als Failover hinzuzufügen.

Lokale Tuner/CI-Probleme, die wie Timeouts aussehen

Hier ist das, was die meiste Diagnoszeit verschwendet: Das Problem hat überhaupt nichts mit dem Netzwerk zu tun. Ein festsitzender CI (Common Interface)-Slot, ein verschlechterter interner Kartenleser oder ein schwaches Satellitensignal können alle ECM-Timeout-Einträge in den NCam-Protokollen erzeugen — weil das ECM von einem schlechten Stream erfasst wurde oder der CI kein Steuerwort zurückgab, und NCam es als Timeout protokollierte.

Überprüfen Sie die Signalpegel im Menü Ihres Receivers. Ein SNR unter etwa 12 dB bei den meisten Setups oder eine Signalqualität unter 80% beginnt, beschädigte Pakete zu erzeugen. Dazu gehören beschädigte ECMs. NCam kann ein verzerrtes ECM nicht dekodieren; es hat einen Timeout, während es auf eine Antwort wartet, die nicht kommen kann, weil der Eingang von Anfang an Müll war. Probieren Sie denselben Kanal auf einem Transponder mit bekannt guter Signalstärke aus und sehen Sie, ob die Timeouts verschwinden. Wenn ja, liegt das Problem bei Ihrer Schüssel, LNB oder Kabelverlegung — nicht bei NCam.

Schritt-für-Schritt-Diagnoseworkflow

Der größte Fehler, den die Leute machen, besteht darin, zwei oder drei Dinge gleichzeitig zu ändern und dann nicht zu wissen, welches funktioniert hat. Hier ist das Handbuch, das ich verwende. Ändern Sie eine Variable. Beobachten Sie mindestens 15 Minuten. Gehen Sie dann zum nächsten Schritt.

Aktivieren Sie detaillierte Protokollierung (Debug-Level) sicher

Inoscam.conf [global], Protokollierung vorübergehend erhöhen:

[global]

Debug-Level 64 gibt Ihnen ECM-Routing-Details ohne die extreme Ausführlichkeit des vollständigen Debugs (255). Lassen Sie das vollständige Debug nicht dauerhaft aktiviert — auf eingebetteter Hardware mit langsamen Speichern verkürzt das Schreiben von Megabytes an Protokollen pro Stunde in den Flash-Speicher die Lebensdauer des Geräts und kann I/O-Verzögerungen verursachen, die sich auf die Dekodierung selbst auswirken. Aktivieren Sie es, reproduzieren Sie das Problem, und schalten Sie es dann wieder aus.

Protokoll-Zeitstempel mit dem Einfrieren korrelieren

Wenn ein Kanal einfriert, notieren Sie die genaue Uhrzeit. Ziehen Sie das Protokoll und schauen Sie 5–15 Sekunden vor diesem Zeitstempel — ECM-Timeouts treten vor dem sichtbaren Einfrieren auf, da das Steuerwort kurz nach dem Fehlschlagen der Anfrage abläuft. Wenn Sie eine Ansammlung von Timeout-Zeilen um 21:04:25 sehen und der Bildschirm um 21:04:33 schwarz wurde, ist das Ihr Ereignis. Notieren Sie die CAID, PROVID und SID aus diesen Zeilen.

Testen Sie einen Leser nach dem anderen

Inoscam.serverdeaktivieren Sie alle Leser außer einem, indem Sieenable = 0zu jedem Block hinzufügen, den Sie überspringen möchten, und laden Sie dann neu. Zwingen Sie eine Abstimmung auf den problematischen Kanal. Beobachten Sie die Status-Registerkarte im Webinterface — insbesondere die ECM-Zeit-Spalte und die ecmok/ecmnok-Zähler für Ihren aktiven Leser. Wenn dieser Leser mit null Last (nur Ihre einzelne Sitzung) ein Timeout hat, liegt das Problem an der Latenz dieses Lesers oder Ihrer Verbindung zu ihm. Wenn er gut reagiert, aktivieren Sie den nächsten Leser wieder und testen Sie mit beiden.

Dieser Ansatz mit einem einzelnen Leser ist das schnellste Diagnosemittel zur Behebung von NCam-ECM-Timeouts, das ich kenne. Er beseitigt sofort Probleme mit Lastenausgleich und Wechselwirkungen zwischen Lesern.

Bestätigen Sie die Behebung ohne falsche Positivmeldungen

Ein erfolgreicher Kanalwechsel bestätigt keine Behebung. NCam speichert das letzte gültige Steuerwort kurzzeitig, sodass Sie umschalten, ein Bild erhalten, denken, es sei behoben — und dann friert es 10 Sekunden später ein, wenn der nächste Kryptoperiodenwechsel eintritt und dasselbe Timeout erneut auftritt. Beobachten Sie den ecmok-Zähler im Webinterface mindestens 15 Minuten lang, auf dem spezifischen Kanal, der zuvor ausgefallen ist. Sie möchten sehen, dass ecmok alle 10 Sekunden zunimmt, mit ECM-Zeiten, die weit unter Ihrer Timeout-Einstellung liegen, und null ecmnok-Ereignissen während dieses Zeitraums. Das ist eine bestätigte Behebung.

Wie man eine zuverlässige Upstream-Quelle auswählt

Einen soliden Upstream-Peer zu bekommen, ist die langfristige Behebung von NCam-ECM-Timeouts, die durch keine Menge an lokalen Konfigurationseinstellungen ersetzt werden kann. Hier ist, was tatsächlich wichtig ist, wenn man eine Quelle bewertet.

Kriterien, die mit niedriger ECM-Zeit korrelieren

Die ECM-Antwortzeit ist der beste Prädiktor für Zuverlässigkeit. Jeder anständige Peer sollte während der Hauptverkehrszeiten Antwortzeiten von unter 700 ms für die benötigte CAID liefern — nicht nur um 2 Uhr morgens, wenn der Server inaktiv ist. Geografische Nähe spielt hier eine Rolle: Ein Server, der physisch nahe bei Ihnen auf einem Netzwerkpfad mit niedriger Latenz ist, wird immer besser abschneiden als ein "Premium"-Server auf einer überlasteten transatlantischen Route.

Die Hop-Anzahl ist der andere große Faktor. Eine Karte, die 1 Hop vom Ursprung geteilt wird (der Peer betreibt die tatsächliche Karte), wird immer eine Karte übertreffen, die 3 Hops tief durch eine Wiederverteilungskette geht. Jeder Hop fügt Latenz und einen potenziellen Fehlerpunkt hinzu. Fragen Sie konkret, wie viele Hops von der physischen Karte Ihre ECM-Anfrage zurücklegt. Alles über 2 ist ein Warnsignal.

Warnsignale, die häufige Timeouts vorhersagen

ECM-Zeiten über 1200 ms während eines Testzeitraums sollten eine Quelle sofort disqualifizieren. Das sind bereits 40% Ihres Standard-Timeout-Budgets, ohne Spielraum für Abweichungen. Server ohne Client-Limit neigen dazu, im Laufe der Zeit immer schlechter zu werden, wenn sie mehr Benutzer aufnehmen — beobachten Sie, ob die ECM-Zeiten über ein 30-minütiges Beobachtungsfenster stabil sind oder langsam ansteigen.

Ein nicht angebotener Testzeitraum ist selbst ein Warnsignal. Jeder Betreiber, der von der Leistung seines Servers überzeugt ist, wird Ihnen erlauben, ihn zu testen. Wenn Sie die ECM-Zeit nicht vor einer Verpflichtung überprüfen können, fliegen Sie blind.

Testen vor der Verpflichtung

Konfigurieren Sie den neuen Peer als einzelnen Leser inoscam.servermit allen anderen Lesern deaktiviert. Lassen Sie ihn durch einen Abend-Hauptverkehrszeitraum laufen — das ist, wenn Überbuchungen sichtbar werden. Beobachten Sie die ECM-Zeit-Spalte im Webinterface. Ein Server, der um 12 Uhr 350 ms und um 20:00 Uhr 2400 ms anzeigt, ist überbucht und wird regelmäßig Timeouts verursachen. Ein Server, der während der Hauptverkehrszeiten 400–600 ms hält, ist es wert, behalten zu werden. Das Verhältnis von ecmnok/ecmok sollte bei einer zuverlässigen Quelle gut unter 5% bleiben — wenn Sie 15% ECM-Fehler sehen, selbst wenn die Antwortzeiten in Ordnung aussehen, gibt es ein Filter- oder Berechtigungsproblem, das separat untersucht werden muss.