GBox-Kanal-Frieren: Ursachen& Lösungen für CCcam/OScam

Wenn Sie nach einer zuverlässigenLösung für das Einfrieren von GBox-Kanälen suchen, ist das erste, was Sie akzeptieren müssen, dass "Kanäle einfrieren" mindestens drei völlig unterschiedliche Probleme umfasst — und die richtige Lösung hängt ganz davon ab, welches Sie tatsächlich haben. Dieser Leitfaden führt Sie durch eine ordnungsgemäße Diagnosesequenz, damit Sie aufhören zu raten und anfangen zu messen.

Die meisten Ratschläge online sagen Ihnen, dass Sie Ihre Box neu starten sollen. Das ist nutzlos, ohne zu wissen, warum sie überhaupt eingefroren ist. Die echte Antwort liegt fast immer in Ihren ECM-Zeitdaten, Ihren Protokolldateien oder einem 100-Paket-Ping-Test — nicht in einem Neustart.

Was 'Einfrieren' tatsächlich in einem GBox-Share bedeutet

Bevor Sie irgendwelche Konfigurationen ändern, müssen Sie wissen, was Sie sich ansehen. Ein Einfrieren in einem GBox/OScamSetup hat eine sehr spezifische Signatur, und sie unterscheidet sich von zwei anderen Dingen, die die Leute oft damit verwechseln.

Einfrieren vs. Schwarzer Bildschirm vs. Pixelation

EinEinfrieren ist, wenn das Bild für 1–4 Sekunden stockt und dann sauber fortgesetzt wird. Auch der Ton könnte ausfallen. Dann kommt alles zurück. Das ist ein Dekodierungsstopp — der Empfänger wartete auf ein Steuerwort (DCW), das zu spät oder gar nicht ankam, und holte dann auf.

Einharter schwarzer Bildschirm ist anders. Kein Bild, kein Ton, möglicherweise eine "kein Signal" oder "verschlüsselt" Nachricht. Das bedeutet normalerweise, dass kein gültiger Schlüssel vorhanden ist — die ECM-Anfrage ist vollständig fehlgeschlagen, nicht nur zu spät. Anderes Problem, andere Lösung.

Pixelation — blockartige Makroblöcke, Rissartefakte, zufälliges digitales Rauschen — ist fast immer ein Signalproblem. Niedriger SNR, ein defekter LNB, Wasser in der Koaxleitung oder ein schwacher Transponder. Der Decoder hat den richtigen Schlüssel; der TS-Stream selbst ist beschädigt. Überprüfen Sie Ihre Signalpegel, bevor Sie das Share beschuldigen.

Der ECM/DCW-Anforderungszyklus und wo Verzögerungen auftreten

Der Empfänger sendet eine ECM (Entitlement Control Message) an OScam. OScam leitet sie an den GBox-Peer weiter. Der Peer entschlüsselt sie mit der physischen Smartcard und sendet das DCW (Descrambling Control Word) zurück. OScam liefert diesen Schlüssel an den Empfänger, der ihn verwendet, um den Stream zu dekodieren.

Jeder Schritt in dieser Kette fügt Zeit hinzu. Lokale Netzwerkverzögerung, WAN-Verzögerung zum Peer, die eigene Verarbeitungszeit des Peers, die Rückreise. Die Gesamtheit ist Ihre ECM-Antwortzeit, gemessen in Millisekunden auf der OScam-Statusseite. Diese Zahl ist das nützlichste, was Sie beim Troubleshooting betrachten können.

Die Faustregel: konstant unter ~300ms ist angenehm. 300–500ms ist grenzwertig. Über ~600ms und Sie werden wahrscheinlich bei jedem Schlüsselwechsel einfrieren. Über 1000ms und Sie werden definitiv einfrieren.

Warum Einfrierungen alle ~10 Sekunden auftreten (Schlüsselwechselintervall)

Smartcard-Anbieter rotieren Steuerwörter nach einem festen Zeitplan — normalerweise alle 10 Sekunden, obwohl einige Anbieter kürzere Intervalle verwenden. Der Empfänger benötigt den neuen Schlüssel, bevor der alte abläuft. Wenn Ihre ECM-Antwortzeit nahe an oder über diesem Fenster liegt, frieren Sie genau im Moment der Rotation ein, dann normales Bild bis zum nächsten.

Dieses rhythmische Muster — einfrieren, erholen, 10 Sekunden gutes Bild, wieder einfrieren — ist diagnostisch. Es ist nicht zufällig. Es ist nicht Ihr Tuner. Es ist das Schlüsselwechselintervall, das auf einen langsamen ECM-Pfad trifft. Zufällige Einfrierungen in unregelmäßigen Abständen deuten auf etwas ganz anderes hin (Jitter-Spitzen, Paketverlust, CPU-Auslastung des Empfängers).

Schritt-für-Schritt-Diagnose: Isolieren Sie die echte Ursache

Beginnen Sie nicht mit dem Ändern von Konfigurationen. Beginnen Sie mit dem Messen. Die OScam-Weboberfläche gibt Ihnen alles, was Sie benötigen, um zu verstehen, was passiert, bevor Sie eine einzige Datei berühren.

ECM-Zeit in der OScam-Weboberfläche lesen (Port 8888 Statusseite)

Die integrierte Weboberfläche von OScam befindet sich unterhttp://your-server-ip:8888 standardmäßig. Der Port ist in/etc/oscam/oscam.conf unter dem[webif] Abschnitt festgelegt — suchen Sie nachhttpport = 8888. Wenn es nicht vorhanden ist, fügen Sie es hinzu und starten Sie OScam neu.

Navigieren Sie zur Seite der Leser. Sie sehen jeden Leser mit dem aktuellen Status aufgelistet, und — das ist der wichtige Teil — eine ECM-Zeitspalte. Beobachten Sie es live, während Sie einen Kanal abspielen. Sie möchten stabile Zahlen unter 300 ms sehen. Wenn Sie sehen, dass es auf 800 ms, 1200 ms oder ganz ausfällt, haben Sie Ihr Problem gefunden.

Vergleichen Sie Ihren GBox-Peer-Leser mit einem lokalen Leser, den Sie haben. Ein lokaler Softcam oder physischer Leser sollte in weniger als 50 ms reagieren. Dieser Unterschied sagt Ihnen genau, wie viel der Netzwerkpfad und die Peer-Verarbeitung kosten.

Überprüfen Sie zuerst die Signalqualität, um die Schüssel/LNB auszuschließen.

Bevor Sie eine Stunde in OScam-Protokollen verbringen, verbringen Sie zwei Minuten auf dem Signalbildschirm Ihres Receivers. Holen Sie sich das SNR und die Signalstärke für den Transponder, den Sie ansehen. Bei den meisten Receivern ist das Info → Signal oder eine spezielle Taste.

Ein SNR unter etwa 9–10 dB (je nach Modulation) führt unabhängig von Ihrer Share-Konfiguration zu Pixelbildung. Wenn das Signal grenzwertig ist, beheben Sie das zuerst. Ein schlechtes LNB oder ein loser F-Stecker verschwenden Stunden mit Software-Debugging.

Testen Sie einen Kanal auf einer lokalen Karte im Vergleich zu einem Remote-Share.

Wenn Sie Zugang zu einer lokalen Karte haben — sogar einer Testkarte oder einem CI-Slot — machen Sie einen direkten Vergleich. Gleicher Kanal, gleicher Transponder. Wenn es auch auf der lokalen Karte einfriert, ist der Share unschuldig. Wenn die lokale Karte sauber ist, aber der GBox-Peer einfriert, haben Sie das Problem auf den Share-Pfad isoliert.

Dieser Isolationstest eliminiert eine enorme Anzahl von Variablen in einem Schritt. Überspringen Sie ihn nicht.

Beobachten Sie die Hop-Anzahl und die GBox-Peer-Kette.

Im OScam-Leserstatus sagt die Hop-Anzahl, wie viele Reshare-Schritte zwischen Ihnen und der physischen Karte liegen. Hop 1 bedeutet, dass der Peer seine eigene Karte direkt liest. Hop 2 bedeutet, dass sie sie von jemand anderem erhalten. Hop 3+ bedeutet, dass Sie am Ende einer Reshare-Kette sind.

Jeder Hop fügt Latenz hinzu. Jeder Hop fügt einen Fehlerpunkt hinzu. Eine Karte bei Hop 3, die in Ordnung aussieht, wenn Sie sie testen, kann sich im Laufe eines Abends verschlechtern, während die Last im Upstream steigt. Wenn Sie Hop 2 oder höher in Ihrem Leserstatus sehen, ist das ein Warnsignal für die Stabilität unter Last.

Erfassen Sie die Zeit mit oscam.log auf Debug-Ebene.

Das OScam-Protokoll befindet sich unter dem im/etc/oscam/oscam.conf festgelegten Pfad[global] — suchen Sie nachlogfile = /var/log/oscam/oscam.log. Um Timing-Details zu erhalten, erhöhen Sie die Protokollebene entweder in der Weboberfläche (Konfiguration → Protokolleinstellungen → setzen Sie die Protokollebene vorübergehend auf Debug) oder indem Sie die Konfiguration direkt bearbeiten.

Beobachten Sie dann das Protokoll live:tail -f /var/log/oscam/oscam.log. Sie sehen ECM-Anfragen, Antworten, Leserwahl und genaue Millisekunden-Zeitstempel. Ein Einfrierereignis wird entweder als Timeout oder als ungewöhnlich lange Lücke zwischen der ECM-Anfrage und der DCW-Antwort angezeigt. Das Protokoll lügt nicht.

Netzwerk- und Latenzkorrekturen.

GBox verwendet UDP. Das ist die entscheidende Tatsache, die die meisten allgemeinen Fehlersuche-Anleitungen völlig übersehen. UDP überträgt verlorene Pakete nicht erneut. Wenn ein Paket, das eine DCW enthält, im Kabel verloren geht, ist es weg. Die ECM läuft ab, der Schlüssel kommt nicht an, Sie frieren ein.

Das bedeutet, dass Paketverlust und Jitter viel mehr schmerzen als rohe Latenz. Ein Peer, der 200 ms entfernt ist und 0 % Verlust hat, wird einen Peer, der 30 ms entfernt ist und 2 % Paketverlust hat, jedes Mal übertreffen.

Messen Sie Jitter und Paketverlust zum Peer (ping/mtr).

Beginnen Sie mit einem einfachen erweiterten Ping:ping -c 100 peer-ip-address. Hundert Pakete geben Ihnen einen bedeutenden Verlustprozentsatz und zeigen min/avg/max Zeiten. Die Spreizung zwischen min und max ist Ihr Jitter. Wenn max 3–4× Ihr min ist, ist das hoher Jitter, auch wenn der Durchschnitt in Ordnung aussieht.

Führen Sie dannmtr peer-ip-address aus (installieren Sie es mitapt install mtr wenn es fehlt). MTR führt einen kontinuierlichen Traceroute durch und zeigt den Verlust an jedem Hop an. Sie könnten feststellen, dass das Backbone Ihres ISP zwei Hops entfernt 1,5 % Verlust hat — das allein erklärt intermittierende Einfrierungen. Wenn ein Hop in der Kette einen Verlust von über 1–2 % zeigt, betrachten Sie diesen Hop als verdächtig.

Ein Verlust von über 2 % oder Jitter von über ~50 ms führt selbst dann zu sporadischen Einfrierungen, wenn Ihre durchschnittliche ECM-Zeit perfekt aussieht. Hier zählt die schlimmste Latenz, nicht der Durchschnitt.

UDP-Portweiterleitung für GBox und Stabilität gewährleisten.

GBox-Peering verwendet einen einzelnen konfigurierbaren UDP-Port pro Peer — eingestellt in IhrerCCcam C-Line oder OScam GBox-Leser-Konfiguration. Dieser Port muss in Ihrem Router korrekt an die Maschine weitergeleitet werden, die OScam/CCcam ausführt.

Der häufige Fehler: Portweiterleitung einmal einrichten und dann vergessen. Wenn sich Ihre öffentliche IP ändert (dynamische IP von Ihrem ISP), zeigt die Konfiguration Ihres Peers weiterhin auf Ihre alte Adresse. Plötzlich gehen UDP-Pakete nirgendwohin. Der Peer sieht eine tote Verbindung, Sie sehen einen gefrorenen oder schwarzen Bildschirm. Verwenden Sie einen DDNS-Dienst und stellen Sie sicher, dass beide Seiten ihre Konfigurationen aktualisieren, wenn sich die IPs ändern.

Überprüfen Sie auch, ob die Regel tatsächlich UDP speziell weiterleitet, nicht nur TCP. Einige Routeroberflächen sind standardmäßig auf TCP oder TCP+UDP eingestellt – stellen Sie sicher, dass es UDP ist.

MTU, Fragmentierung und CGNAT-Fallen

Bei PPPoE-Verbindungen (den meisten DSL-Leitungen) sinkt die effektive MTU auf 1492 Bytes anstelle der Standard-1500. Wenn Ihr Router dies nicht korrekt verarbeitet, werden große UDP-Pakete fragmentiert – und Fragmentierung im UDP-Protokoll verursacht genau die Art von intermittierenden Ausfällen, die zu Freezes führen.

Versuchen Sie, die WAN-MTU Ihres Routers explizit auf 1492 einzustellen. Unter Linux können Sie testen mit:ping -M do -s 1464 peer-ip-address — wenn das fehlschlägt, aber kleinere Größen funktionieren, haben Sie ein MTU-Problem.

CGNAT ist schlimmer. Wenn Ihr ISP Sie hinter Carrier-Grade NAT (häufig bei mobilem Breitband und einigen Budget-ISPs) platziert, kann Ihr GBox-Peer Sie überhaupt nicht über eine eingehende UDP-Portweiterleitung erreichen. Ihre ausgehende Verbindung könnte sporadisch funktionieren, aber stabiles Peering ist ohne ein VPN-Tunnel oder einen VPS in der Mitte im Wesentlichen unmöglich. Überprüfen Sie, ob Ihre externe IP (whatismyip.com) von der WAN-IP Ihres Routers abweicht – wenn ja, sind Sie wahrscheinlich hinter CGNAT.

Wi-Fi vs. Kabel beim Empfänger

Das klingt langweilig, ist aber die kostengünstigste Lösung. Wi-Fi-Wiederholungen fügen Jitter hinzu. Nicht viel pro Paket, aber konstant – und dieser Jitter landet unvorhersehbar in Bezug auf wichtige Änderungsmomente. Ich habe Setups gesehen, bei denen das Verschieben des Empfängers von 5GHz-Wi-Fi zu einem 5 € Powerline-Adapter Freezes vollständig beseitigt hat, wobei die ECM-Zeiten um 30–50 ms gesenkt wurden und die Varianz verloren ging.

Ethernet vom Empfänger zum Router ist ideal. Powerline-Adapter (MoCA oder die Standard-AV2-Variante) sind die zweitbeste Wahl. Wi-Fi, insbesondere 2.4GHz, sollte die letzte Option sein, wenn Sie Freezes beheben.

Konfigurationskorrekturen in CCcam/OScam

Sobald Sie Signalprobleme ausgeschlossen und bestätigt haben, dass Ihr Netzwerkpfad sauber ist, ist die Konfiguration der Bereich, in dem die meisten verbleibenden Probleme liegen. Die Standardeinstellungen in OScam sind nicht für Live-TV optimiert – sie sind konservativ, und konservativ bedeutet langsame Rückfalle, wenn ein Peer ausfällt.

Cache-Timeout und ECM-Timeout-Tuning (oscam.conf Global Section)

Öffnen Sie/etc/oscam/oscam.conf und schauen Sie sich den[global] Abschnitt an. Zwei Einstellungen sind hier am wichtigsten:

[global]

Derclienttimeout Wert ist in Millisekunden – dies ist die Zeit, die OScam wartet, bevor es dem Client mitteilt, dass es fehlgeschlagen ist. Wenn auf 3000 ms (ein gängiger Standard) eingestellt, wartet OScam 3 volle Sekunden, bevor es auf einen anderen Leser zurückfällt. Das sind drei Sekunden eines gefrorenen Bildes. Senken Sie ihn auf 1500 ms für Live-TV. Wenn Ihr bester Peer konstant unter 500 ms antwortet, können Sie ihn noch weiter senken.

fallbacktimeout steuert, wie lange OScam wartet, bevor es den nächsten Leser in einer Gruppe ausprobiert. Stellen Sie dies etwas über Ihrer typischen ECM-Zeit für den primären Leser ein, damit der Rückfall schnell erfolgt, wenn der primäre langsam ist, aber nicht unnötig ausgelöst wird.

Lesergruppe, Rückfall und CAID/Provider-Zuordnung

In/etc/oscam/oscam.server hat jeder Leser eineGruppenzuordnung. Ein Client (in assignment. A client (in /etc/oscam/oscam.user) wird einer oder mehreren Gruppen zugeordnet. Der Schlüssel ist, einen Rückfallleser in einer separaten Gruppe zu haben oder mitfallback = 1 in der Leserdefinition festzulegen:

[reader]

Mit diesem Setup verwendet OScam den primären Leser und greift nur auf den Rückfall zu, wenn der primärefallbacktimeout überschreitet. Kein Rückfallleser bedeutet, dass ein langsamer Peer alles zum Stillstand bringt, bisclienttimeout läuft ab. Daher kommen lange Ausfälle.

Diecaid undident Zeilen leisten ebenfalls echte Arbeit — sie beschränken, welche ECMs dieser Leser überhaupt zu beantworten versucht. Wenn ein Leser diese nicht korrekt für das Paket eingestellt hat, das Sie beobachten, wird OScam diese ECMs überhaupt nicht an ihn weiterleiten, selbst wenn der Peer sie technisch beantworten könnte.

Hops begrenzen und tote Peers deaktivieren

In/etc/oscam/oscam.conf unter[global] begrenzt diecccmaxhops Einstellung, wie viele Reshare-Hops OScam von CCcam-Peers akzeptiert:

[global]

Wenn Sie dies auf 2 setzen, bedeutet das, dass OScam keine Karten akzeptiert, die bereits 2 oder mehr Hops von einem physischen Leser entfernt sind. Dies ist ein Qualitätsfilter, nicht nur eine politische Präferenz — Karten mit vielen Hops sind von Natur aus langsamer und weniger zuverlässig.

Für tote Peers sollten Sie sie nicht in der Konfiguration belassen. Ein Leser, der offline ist, tut nicht einfach nichts — OScam versucht es weiterhin, wartet auf das Timeout und macht dann weiter. Jeder tote Leser in Ihrer Konfiguration erhöht die Latenz bei jedem ECM-Versuch. Entfernen Sie Peers, die Sie nicht mehr verwenden, oder setzen Sie mindestens ihr Timeout niedrig und stellen Sie sie zuletzt in die Fallback-Kette.

AU und EMM-Geräusche, die den Leser verlangsamen

Automatische Updates (AU) und EMM (Entitlement Management Messages) sind der Mechanismus, den Smartcards verwenden, um Software-Updates und Berechtigungsverlängerungen zu erhalten. Bei einem Share-Peer kann die EMM-Verarbeitung schwer sein — insbesondere wenn der Peer Dutzende von Clients bedient und gleichzeitig EMMs für seine Karte verarbeitet.

In/etc/oscam/oscam.server für Ihre GBox-Leser sollten Sie in Betracht ziehen:

saveemm = 0

Dies stoppt OScam daran, EMMs von diesem Leser zu speichern/verarbeiten. Bei einer reshared Karte benötigen Sie ohnehin kein AU — Sie besitzen die Karte nicht. Das Deaktivieren reduziert die Verarbeitungsbelastung auf dem Peer und räumt Bandbreite frei, die für EMM-Verkehr verwendet wurde. Wenn Sie auf der OScam-Statusseite hohe EMM-Raten bei einem Peer sehen, der nur ECMs beantworten sollte, trägt dies wahrscheinlich zu langsamen ECM-Antworten bei.

CCcam.cfg-Äquivalente (C-Line-Optionen, Sleep, Hop)

Wenn Sie weiterhin CCcam anstelle von OScam verwenden, befindet sich die Konfiguration unter/etc/CCcam.cfg. Das äquivalente Hop-Limit befindet sich auf der F-Line (Ihre eigenen Reshare-Einstellungen) und über eine globale Option:

CCCAM HOP: 2

CCCAM HOP begrenzt die eingehende Kartentiefe, genau wiecccmaxhops in OScam.CCCAM RESHARE: 0 bedeutet, dass Sie eingehende Karten nicht an andere weitergeben — gute Praxis, wenn Sie nur ein Client sind.SLEEP auf 0 gesetzt deaktiviert den Schlafmodus, der inaktive Clients trennt, was bei Schlüsseländerungen nach ruhigen Phasen zu Verzögerungen bei der Wiederverbindung führen kann.

Für C-Lines (Ihre Verbindungen zu GBox-Peers) bietet CCcam nicht so viele pro-Verbindung-Tuning-Optionen wie OScam. Wenn Sie mit der Konfigurierbarkeit von CCcam für eine GBox-Kanal-Fixierung an Grenzen stoßen, ist eine Migration zu OScam in Betracht zu ziehen — es gibt Ihnen viel mehr Kontrolle über Timeouts, Fallback-Reihenfolge und ECM-Routing.

Wie man beurteilt, ob das Problem bei Ihrem Peer liegt

Manchmal machen Sie alles richtig — sauberes Netzwerk, gute Konfiguration, ordnungsgemäße Portweiterleitung — und Sie frieren trotzdem ein. An diesem Punkt wird die Frage, ob der Peer selbst das Problem ist.

Hier ist der Punkt, an dem viele Leute entweder den Peer zu früh beschuldigen oder zu lange bei einem schlechten Peer bleiben. Die Antwort besteht darin, messbares Verhalten über einen Zeitraum zu bewerten, nicht Schnappschüsse.

Stabile Share-Kriterien, auf die man achten sollte (allgemein)

Ein guter Peer zeigt ECM-Zeiten, die über Stunden hinweg konsistent sind. Überprüfen Sie die OScam-Statusseite während der Nebenzeiten und dann wieder während der Hauptzeiten (Abendstunden in welcher Zeitzone der Server auch immer ist). Ein Peer mit 150 ms ECM-Zeit um 15 Uhr und 800 ms ECM-Zeit um 20 Uhr ist zu Spitzenzeiten überlastet – es ist kein Netzwerkproblem auf Ihrer Seite.

Hop 1 ist der Goldstandard. Der Peer liest die physische Karte direkt, ohne eine Reshare-Kette darüber. Hop 2 kann akzeptabel sein, wenn der Upstream schnell und zuverlässig ist. Hop 3 oder höher bedeutet, dass Sie von einer Kette von Peers abhängig sind, die Sie nicht einsehen können, und jeder von ihnen kann ohne Vorwarnung ausfallen.

CAID und Anbieterabdeckung müssen mit dem übereinstimmen, was Sie tatsächlich ansehen. Ein Peer, der eine Karte für einen Anbieter hält, der Ihr Paket nicht anbietet, wird bei jedem ECM für dieses Paket zeitlich ablaufen – und das sieht wie ein Netzwerkproblem aus, bis Sie die CAID-Zuordnung überprüfen.

Uptime, lokale Karte vs. Reshare und Hop-Transparenz

Uptime über Tage und Wochen ist wichtiger als eine perfekte Testsitzung. Ein Peer, der während der Hauptzeiten verschwindet, während Sportereignissen abbricht oder sich alle paar Stunden neu verbindet, verwendet eine dynamische IP ohne DDNS oder läuft auf Hardware, die neu startet. In den OScam-Protokollen sehen Sie wiederholte Einträge für das Verbinden/Trennen des Lesers – mehr als ein paar pro Tag ist ein Warnsignal.

Hop-Transparenz bedeutet, dass der Peer die Hop-Anzahl ehrlich meldet, anstatt sie künstlich auf 1 zu setzen. Sie können ein grobes Gefühl dafür bekommen, indem Sie die ECM-Zeiten beobachten – eine Karte, die Hop 1 beansprucht und in 400–600 ms antwortet, ist wahrscheinlich tatsächlich weiter entfernt, als sie angibt, da eine echte lokale Ablesung in weniger als 100 ms plus Ihrer Netzwerk-RTT antworten sollte.

Warnsignale, die chronisches Einfrieren vorhersagen

ECM-Zeiten, die stark variieren – sagen wir 80 ms bis 1200 ms bei aufeinanderfolgenden Anfragen für denselben Kanal – deuten auf eine upstream Reshare-Kette mit inkonsistenter Last hin. Kein Netzwerk-Jitter-Problem (das würde sich in Ihrem mtr-Test zeigen); dieses Muster deutet darauf hin, dass die Karte an der Spitze der Kette überlastet ist.

Häufige CAID-Mismatches im Protokoll, bei denen OScam den Leser versucht und "nicht gefunden" für Pakete zurückgibt, die abgedeckt sein sollten, bedeutet entweder, dass die Karte nicht die richtigen Berechtigungen hat oder der Peer Ihnen falsche Fähigkeitsinformationen sendet.

Peers, die perfekt für 30–60 Sekunden funktionieren und dann allmählich abnehmen – steigende ECM-Zeiten, dann Zeitüberschreitungen – sind fast immer eine reshared Karte (Hop 2+), bei der der unmittelbare Peer, mit dem Sie verbunden sind, in Ordnung ist, aber die Karte darüber in der Kette Schwierigkeiten hat. Eine Gbox-Kanal-Einfrierbehebung, die einen Wechsel der Peers erfordert, ist manchmal die einzige echte Lösung hier, sobald Sie bestätigt haben, dass das Problem upstream und nicht lokal ist.

Häufig gestellte Fragen