Zamrażanie kanałów GBox: Przyczyny& Rozwiązania dla CCcam/OScam

Jeśli szukasz niezawodnegorozwiązania problemu z zamrażaniem kanałów gbox, pierwszą rzeczą, którą musisz zaakceptować, jest to, że "kanały zamarzają" obejmuje co najmniej trzy całkowicie różne problemy — a odpowiednie rozwiązanie zależy całkowicie od tego, który z nich masz. Ten przewodnik przeprowadza przez odpowiednią sekwencję diagnostyczną, abyś przestał zgadywać i zaczął mierzyć.

Większość porad w Internecie mówi, aby zrestartować swój dekoder. To jest bezużyteczne, jeśli nie wiesz, dlaczego zamarzł w pierwszej kolejności. Prawdziwa odpowiedź prawie zawsze znajduje się w danych czasowych ECM, plikach dziennika lub teście ping na 100 pakietów — a nie w cyklu zasilania.

Co 'Zamrażanie' Naprawdę Oznacza w Udostępnianiu GBox

Zanim dotkniesz jakiejkolwiek konfiguracji, musisz wiedzieć, na co patrzysz. Zamrożenie w GBox/OScam ma bardzo specyficzny podpis i różni się od dwóch innych rzeczy, z którymi ludzie często to mylą.

Zamrożenie vs. Czarny Ekran vs. Pikselizacja

Zamrożenie to sytuacja, gdy obraz zatrzymuje się na 1–4 sekundy, a następnie wraca do normy. Dźwięk również może zniknąć. Potem wszystko wraca. To jest zatrzymanie dekodowania — odbiornik czekał na słowo kontrolne (DCW), które dotarło z opóźnieniem lub wcale, a następnie nadrobił zaległości.Twardy czarny ekran

jest inny. Brak obrazu, brak dźwięku, możliwe, że pojawia się komunikat "brak sygnału" lub "zablokowane". To zazwyczaj oznacza brak ważnego klucza — żądanie ECM całkowicie się nie powiodło, a nie tylko dotarło z opóźnieniem. Inny problem, inne rozwiązanie.Pikselizacja — blokowe makrobloki, artefakty rozrywania, losowy szum cyfrowy — to prawie zawsze problem z sygnałem. Niski SNR, uszkodzony LNB, wnikanie wody do kabla koncentrycznego lub słaby transponder. Dekoder ma właściwy klucz; strumień TS jest uszkodzony. Sprawdź poziomy sygnału, zanim obwinisz udostępnianie.

Cykl Żądania ECM/DCW i Gdzie Pojawia się OpóźnienieOdbiornik wysyła ECM (Wiadomość Kontroli Uprawnień) do OScam. OScam przesyła go do partnera GBox. Partner odszyfrowuje go za pomocą fizycznej karty inteligentnej i odsyła DCW (Słowo Kontroli Deszyfrowania). OScam dostarcza ten klucz do odbiornika, który używa go do dekodowania strumienia.

Każdy krok w tym łańcuchu dodaje czas. Opóźnienie w lokalnej sieci, opóźnienie WAN do partnera, czas przetwarzania samego partnera, podróż powrotna. Całkowity czas to czas odpowiedzi ECM, mierzony w milisekundach na stronie statusu OScam. Ta liczba jest najważniejszą rzeczą, na którą należy zwrócić uwagę podczas rozwiązywania problemów.

Zasada ogólna: konsekwentnie poniżej ~300ms jest komfortowe. 300–500ms to margines. Powyżej ~600ms prawdopodobnie zamarzniesz przy każdej zmianie klucza. Powyżej 1000ms na pewno zamarzniesz.

Dlaczego Zamrożenia Klasterują Co ~10 Sekund (Interwał Zmiany Klucza)

Dostawcy kart inteligentnych rotują słowa kontrolne według ustalonego harmonogramu — zazwyczaj co 10 sekund, chociaż niektórzy dostawcy używają krótszych interwałów. Odbiornik potrzebuje nowego klucza przed wygaśnięciem starego. Jeśli czas odpowiedzi ECM jest bliski lub przekracza ten czas, zamarznie dokładnie w momencie rotacji, a następnie normalny obraz aż do następnego.

Ten rytmiczny wzór — zamrożenie, odzyskanie, 10 sekund dobrego obrazu, ponowne zamrożenie — jest diagnostyczny. To nie jest losowe. To nie jest twój tuner. To interwał zmiany klucza spotykający wolną ścieżkę ECM. Losowe zamrożenia w nieregularnych odstępach wskazują gdzie indziej (szczyty jitter, utrata pakietów, obciążenie CPU odbiornika).

Diagnostyka Krok po Kroku: Izoluj Prawdziwą Przyczynę

Nie zaczynaj od zmiany konfiguracji. Zacznij od pomiarów. Interfejs internetowy OScam daje ci wszystko, co potrzebujesz, aby zrozumieć, co się dzieje, zanim dotkniesz jednego pliku.

Odczytaj czas ECM w interfejsie internetowym OScam (Strona statusu Port 8888)

Wbudowany interfejs internetowy OScam znajduje się pod

http://your-server-ip:8888

domyślnie. Port jest ustawiony w/etc/oscam/oscam.conf w sekcji[webif] — szukajhttpport = 8888 section — look for httpport = 8888. Jeśli go tam nie ma, dodaj go i zrestartuj OScam.

Przejdź do strony Readers. Zobaczysz każdą czytnikę z aktualnym statusem, a — to jest ważna część — kolumną czasu ECM. Obserwuj to na żywo podczas oglądania kanału. Chcesz widzieć stabilne liczby poniżej 300ms. Jeśli zobaczysz, że skacze do 800ms, 1200ms lub całkowicie się zatrzymuje, znalazłeś swój problem.

Porównaj swojego czytnika GBox z dowolnym lokalnym czytnikiem, który masz. Lokalny softcam lub fizyczny czytnik powinien odpowiadać w czasie poniżej 50ms. Ta różnica dokładnie mówi, ile kosztuje cię ścieżka sieciowa i przetwarzanie peer.

Sprawdź najpierw jakość sygnału, aby wykluczyć talerz/LNB

Zanim spędzisz godzinę w logach OScam, poświęć dwie minuty na ekran sygnału swojego odbiornika. Uzyskaj SNR i siłę sygnału dla transpondera, który oglądasz. Na większości odbiorników to Info → Sygnał lub dedykowany przycisk.

SNR poniżej około 9–10 dB (w zależności od modulacji) spowoduje pikselizację niezależnie od twojej konfiguracji share. Jeśli sygnał jest marginalny, napraw to najpierw. Zły LNB lub luźny złącze F zmarnuje godziny debugowania oprogramowania.

Przetestuj jeden kanał na lokalnej karcie w porównaniu do zdalnego share

Jeśli masz dostęp do jakiejkolwiek lokalnej karty — nawet karty testowej lub slotu CI — zrób bezpośrednie porównanie. Ten sam kanał, ten sam transponder. Jeśli zamarza również na lokalnej karcie, share jest niewinny. Jeśli lokalna karta jest czysta, ale peer GBox zamarza, zlokalizowałeś problem w ścieżce share.

Ten test izolacji eliminuje ogromną liczbę zmiennych w jednym kroku. Nie pomijaj go.

Obserwuj liczbę hopów i łańcuch peer GBox

W statusie czytnika OScam, liczba hopów mówi ci, ile kroków reshare jest między tobą a fizyczną kartą. Hop 1 oznacza, że peer odczytuje swoją własną kartę bezpośrednio. Hop 2 oznacza, że otrzymuje ją od kogoś innego. Hop 3+ oznacza, że jesteś na końcu łańcucha reshare.

Każdy hop dodaje opóźnienie. Każdy hop dodaje punkt awarii. Karta na hopie 3, która wygląda dobrze podczas testu, może się pogorszyć w ciągu wieczoru, gdy obciążenie w górę rośnie. Jeśli widzisz hop 2 lub wyższy w statusie swojego czytnika, to czerwona flaga dla stabilności pod obciążeniem.

Zbieraj czasy z oscam.log na poziomie debugowania

Log OScam znajduje się w ścieżce ustawionej w/etc/oscam/oscam.conf pod[global] — szukajlogfile = /var/log/oscam/oscam.log. Aby uzyskać szczegóły czasowe, zwiększ poziom logowania albo w interfejsie internetowym (Konfiguracja → Ustawienia logów → tymczasowo ustaw LogLevel na debug), albo edytując konfigurację bezpośrednio.

Następnie obserwuj log na żywo:tail -f /var/log/oscam/oscam.log. Zobaczysz żądania ECM, odpowiedzi, wybór czytnika i dokładne znaczniki czasu w milisekundach. Wydarzenie zamrożenia pojawi się jako timeout lub niezwykle długi odstęp między żądaniem ECM a odpowiedzią DCW. Log nie kłamie.

Naprawy sieci i opóźnień

GBox używa UDP. To kluczowy fakt, który większość ogólnych przewodników rozwiązywania problemów całkowicie pomija. UDP nie retransmituje utraconych pakietów. Jeśli pakiet niosący DCW zostanie utracony w sieci, jest stracony. ECM wygasa, klucz nie dociera, zamarzasz.

To oznacza, że utrata pakietów i jitter mają znacznie większy wpływ niż surowe opóźnienie. Peer oddalony o 200ms z 0% utratą będzie lepszy od peera oddalonego o 30ms z 2% utratą pakietów za każdym razem.

Mierz jitter i utratę pakietów do peera (ping/mtr)

Zacznij od prostego rozszerzonego pingu:ping -c 100 adres-ip-peera. Sto pakietów daje ci znaczący procent utraty i pokazuje czasy min/avg/max. Rozpiętość między min a max to twój jitter. Jeśli max jest 3–4× twoim min, to jest wysoki jitter, nawet jeśli średnia wygląda dobrze.

Następnie uruchommtr adres-ip-peera (zainstaluj go za pomocąapt install mtr jeśli brakuje). MTR wykonuje ciągły traceroute i pokazuje utratę na każdym hopie. Możesz odkryć, że rdzeń twojego dostawcy internetowego ma 1,5% utraty po dwóch hopach — to samo wyjaśnia sporadyczne zamarzania. Jeśli jakikolwiek hop w łańcuchu pokazuje utratę powyżej 1–2%, rozważ ten hop jako podejrzany.

Utrata powyżej 2% lub jitter powyżej ~50ms spowoduje sporadyczne zamarzania, nawet gdy twoje średnie czasy ECM wyglądają całkowicie w porządku. Liczy się tutaj najgorszy przypadek opóźnienia, a nie średnia.

Przekierowanie portów UDP dla GBox i utrzymanie go w stabilności

Peering GBox używa jednego konfigurowalnego portu UDP na peer — ustawionego w twoimCCcam C-linie lub konfiguracji czytnika OScam GBox. Ten port musi być prawidłowo przekierowany w twoim routerze do maszyny uruchamiającej OScam/CCcam.

Typowy błąd: skonfigurowanie przekierowania portów raz i zapomnienie o tym. Jeśli Twój publiczny adres IP się zmienia (dynamiczny IP od Twojego dostawcy), konfiguracja Twojego partnera nadal wskazuje na Twój stary adres. Nagle pakiety UDP nie docierają nigdzie. Partner widzi martwe połączenie, Ty widzisz zamarznięty lub czarny ekran. Użyj usługi DDNS i upewnij się, że obie strony aktualizują swoje konfiguracje, gdy IP się zmienia.

Sprawdź również, czy reguła rzeczywiście przekierowuje UDP, a nie tylko TCP. Niektóre interfejsy routerów domyślnie ustawiają TCP lub TCP+UDP — upewnij się, że to UDP.

Pułapki MTU, Fragmentacja i CGNAT

W połączeniach PPPoE (większość linii DSL) efektywne MTU spada do 1492 bajtów zamiast standardowych 1500. Jeśli Twój router nie obsługuje tego poprawnie, duże pakiety UDP są fragmentowane — a fragmentacja w protokole UDP powoduje dokładnie takie przerywane zrywy, które wywołują zamarznięcia.

Spróbuj ustawić MTU WAN swojego routera na 1492 wyraźnie. Na Linuksie możesz przetestować za pomocą:ping -M do -s 1464 adres-ip-partnera — jeśli to nie działa, ale mniejsze rozmiary działają, masz problem z MTU.

CGNAT jest gorszy. Jeśli Twój dostawca internetu umieszcza Cię za Carrier-Grade NAT (częste w mobilnym internecie i niektórych budżetowych dostawcach), Twój partner GBox nie może w ogóle dotrzeć do Ciebie przez przekierowanie portu UDP. Twoje połączenie wychodzące może działać sporadycznie, ale stabilne połączenie jest zasadniczo niemożliwe bez tunelu VPN lub VPS pośredniczącego. Sprawdź, czy Twój zewnętrzny adres IP (whatismyip.com) różni się od adresu IP WAN Twojego routera — jeśli tak, prawdopodobnie jesteś za CGNAT.

Wi-Fi vs. Połączenie przewodowe na odbiorniku

To brzmi nudno, ale to najtańsza dostępna naprawa. Retransmisje Wi-Fi dodają jitter. Niewiele na pakiet, ale konsekwentnie — a ten jitter ląduje nieprzewidywalnie w stosunku do kluczowych momentów zmiany. Widziałem konfiguracje, w których przeniesienie odbiornika z Wi-Fi 5GHz na adapter Powerline za 5 € całkowicie wyeliminowało zamarznięcia, a czasy ECM spadły o 30–50 ms, eliminując zmienność.

Ethernet od odbiornika do routera jest idealny. Adaptery Powerline (MoCA lub standardowy typ AV2) są drugie w kolejności. Wi-Fi, zwłaszcza 2.4GHz, powinno być ostatecznością, jeśli rozwiązujesz problemy z zamarznięciami.

Naprawy konfiguracji w CCcam/OScam

Gdy wykluczysz problemy z sygnałem i potwierdzisz, że Twoja ścieżka sieciowa jest czysta, konfiguracja jest miejscem, w którym żyje większość pozostałych problemów. Domyślne ustawienia w OScam nie są dostosowane do telewizji na żywo — są konserwatywne, a konserwatywne oznacza wolny powrót, gdy partner ma timeout.

Czas oczekiwania na pamięć podręczną i dostosowanie czasu oczekiwania ECM (sekcja globalna oscam.conf)

Otwórz/etc/oscam/oscam.conf i spójrz na[global] sekcję. Dwa ustawienia mają tutaj największe znaczenie:

[global]

Wartośćclienttimeout jest w milisekundach — to czas, przez jaki OScam czeka na DCW, zanim powie klientowi, że się nie powiodło. Jeśli ustawisz na 3000 ms (częsty domyślny), OScam będzie czekać 3 pełne sekundy, zanim przejdzie do innego czytnika. To trzy sekundy zamrożonego obrazu. Zmniejsz do 1500 ms dla telewizji na żywo. Jeśli Twój najlepszy partner konsekwentnie odpowiada poniżej 500 ms, możesz ustawić jeszcze niżej.

fallbacktimeout kontroluje, jak długo OScam czeka, zanim spróbuje następnego czytnika w grupie. Dostosuj to, aby było nieco powyżej typowego czasu ECM dla głównego czytnika, aby powrót następował szybko, gdy główny jest wolny, ale nie wywoływał niepotrzebnie.

Grupa czytników, powrót i mapowanie CAID/Dostawcy

W/etc/oscam/oscam.server każdy czytnik ma przypisaniegrupy. Klient (w/etc/oscam/oscam.user) mapuje do jednej lub więcej grup. Kluczem jest posiadanie czytnika zapasowego w osobnej grupie lub ustawionego zfallback = 1 w definicji czytnika:

[reader]

Z tą konfiguracją OScam używa głównego czytnika i tylko sięga po zapasowy, jeśli główny przekroczyfallbacktimeout. Brak czytnika zapasowego oznacza, że jeden wolny partner zatrzymuje wszystko, ażclienttimeout wygasa. To stąd pochodzą długie zamrożenia.

Thecaid iident linie również wykonują prawdziwą pracę — ograniczają, które ECM-y ten czytnik w ogóle próbuje odpowiedzieć. Jeśli czytnik nie ma ich ustawionych poprawnie dla pakietu, który oglądasz, OScam w ogóle nie skieruje tych ECM-ów do niego, nawet jeśli peer technicznie mógłby na nie odpowiedzieć.

Ograniczanie skoków i wyłączanie martwych peerów

W/etc/oscam/oscam.conf pod[global], ustawieniecccmaxhops ogranicza, ile skoków reshare OScam zaakceptuje od peerów CCcam:

[global]

Ustawienie tego na 2 oznacza, że OScam nie zaakceptuje kart, które są już 2 lub więcej skoków od fizycznego czytnika. To filtr jakości, a nie tylko preferencja polityki — karty o wysokim skoku są z natury wolniejsze i mniej niezawodne.

Dla martwych peerów, nie zostawiaj ich w konfiguracji. Czytnik, który jest offline, nie tylko nic nie robi — OScam nadal go próbuje, czeka na czas oczekiwania, a następnie przechodzi dalej. Każdy martwy czytnik w twojej konfiguracji dodaje opóźnienie do każdej próby ECM. Usuń peerów, których już nie używasz, lub przynajmniej ustaw ich czas oczekiwania na niski i umieść ich na końcu łańcucha zapasowego.

AU i EMM Hałas, który spowalnia czytnik

Automatyczne aktualizacje (AU) i EMM (Wiadomości o zarządzaniu uprawnieniami) to mechanizm, który karty inteligentne używają do otrzymywania aktualizacji oprogramowania i odnawiania uprawnień. Na udostępnionym peerze przetwarzanie EMM może być intensywne — szczególnie jeśli peer obsługuje dziesiątki klientów, jednocześnie przetwarzając EMM dla swojej karty.

W/etc/oscam/oscam.server dla twoich czytników GBox, rozważ:

saveemm = 0

To zatrzymuje OScam przed zapisywaniem/przetwarzaniem EMM z tego czytnika. Na karcie udostępnionej nie potrzebujesz AU — nie jesteś właścicielem karty. Wyłączenie tego zmniejsza obciążenie przetwarzania na peerze i zwalnia pasmo, które było używane do ruchu EMM. Jeśli widzisz, że strona statusu OScam pokazuje wysokie wskaźniki EMM na peerze, który powinien tylko odpowiadać na ECM-y, to prawdopodobnie przyczynia się do wolnych odpowiedzi ECM.

Odpowiedniki CCcam.cfg (Opcje C-line, Sen, Skok)

Jeśli nadal używasz CCcam zamiast OScam, konfiguracja znajduje się w/etc/CCcam.cfg. Odpowiedni limit skoków znajduje się na linii F (twoje własne ustawienia reshare) oraz poprzez opcję globalną:

CCCAM HOP: 2

CCCAM HOP ogranicza głębokość skoków karty przychodzącej, tak samo jakcccmaxhops w OScam.CCCAM RESHARE: 0 oznacza, że nie udostępniasz przychodzących kart innym — dobra praktyka, jeśli jesteś tylko klientem.SLEEP ustawione na 0 wyłącza tryb uśpienia, który rozłącza nieaktywnych klientów, co może powodować opóźnienia w ponownym połączeniu po zmianach kluczy po cichych okresach.

Dla linii C (twoje połączenia z peerami GBox), CCcam nie udostępnia tak wielu opcji dostrajania na połączenie, jak OScam. Jeśli napotykasz ograniczenia w konfigurowalności CCcam dla naprawy zamrożenia kanału gbox, warto rozważyć migrację do OScam — daje ci znacznie większą kontrolę nad czasami oczekiwania, kolejnością zapasową i trasowaniem ECM.

Jak ocenić, czy problem leży po stronie twojego peera

Czasami robisz wszystko dobrze po swojej stronie — czysta sieć, dobra konfiguracja, prawidłowe przekierowanie portów — a mimo to zamraża. W tym momencie pytanie brzmi, czy sam peer jest problemem.

To tutaj wiele osób albo przedwcześnie obwinia peer'a, albo zbyt długo zostaje z złym peer'em. Odpowiedzią jest ocena mierzalnego zachowania w czasie, a nie migawki.

Kryteria stabilnego udostępniania do poszukiwania (ogólne)

Dobry peer pokazuje czasy ECM, które są spójne przez kilka godzin. Sprawdź stronę statusu OScam w godzinach poza szczytem, a następnie ponownie w godzinach szczytu (wieczornych w strefie czasowej, w której znajduje się serwer). Peer z czasem ECM 150ms o 15:00 i 800ms o 20:00 jest przeciążony w godzinach szczytu — to nie jest problem z siecią po twojej stronie.

Hop 1 to złoty standard. Peer odczytuje fizyczną kartę bezpośrednio, bez łańcucha reshare powyżej. Hop 2 może być akceptowalny, jeśli upstream jest szybki i niezawodny. Hop 3 lub wyżej oznacza, że jesteś zależny od łańcucha peerów, których nie widzisz, a każdy z nich może się pogorszyć bez ostrzeżenia.

Pokrycie CAID i dostawcy musi odpowiadać temu, co faktycznie oglądasz. Peer trzymający kartę dla jednego dostawcy, który nie ma twojego pakietu, będzie czasowo wygasał na każdym ECM dla tego pakietu — a to wygląda jak problem z siecią, dopóki nie sprawdzisz mapowania CAID.

Czas pracy, lokalna karta vs. reshare i przejrzystość hopów

Czas pracy przez dni i tygodnie ma większe znaczenie niż idealna sesja testowa. Peer, który znika w godzinach szczytu, przerywa podczas wydarzeń sportowych lub łączy się ponownie co kilka godzin, używa dynamicznego IP bez DDNS lub działa na sprzęcie, który się restartuje. W logach OScam zobaczysz powtarzające się wpisy o połączeniu/rozłączeniu czytnika — więcej niż kilka dziennie to czerwona flaga.

Przejrzystość hopów oznacza, że peer uczciwie raportuje liczbę hopów, zamiast sztucznie ustawiać ją na 1. Możesz uzyskać ogólne pojęcie o tym, obserwując czasy ECM — karta twierdząca, że jest na hopie 1, która odpowiada w 400–600ms, prawdopodobnie jest w rzeczywistości dalej, niż twierdzi, ponieważ prawdziwe lokalne odczyty powinny odpowiadać w czasie poniżej 100ms plus twój RTT sieciowy.

Czerwone flagi, które przewidują przewlekłe zamarzanie

Czasy ECM, które znacznie się różnią — powiedzmy 80ms do 1200ms w kolejnych żądaniach dla tego samego kanału — wskazują na łańcuch reshare upstream z niespójnym obciążeniem. To nie jest problem z jitterem sieciowym (to pokazałoby się w teście mtr); ten wzór sugeruje, że karta na szczycie łańcucha jest przeciążona.

Częste niezgodności CAID w logu, gdzie OScam próbuje czytnika i zwraca "nie znaleziono" dla pakietów, które powinny być objęte, oznacza, że albo karta nie ma odpowiednich uprawnień, albo peer wysyła ci złe informacje o możliwościach.

Peery, które działają idealnie przez 30–60 sekund, a następnie stopniowo się pogarszają — zwiększające się czasy ECM, a potem time-outy — prawie zawsze są kartą reshare (hop 2+), gdzie bezpośredni peer, z którym się łączysz, jest w porządku, ale karta powyżej nich w łańcuchu ma problemy. Naprawa zamarzania kanału gbox, która wymaga zmiany peerów, jest czasami jedyną realną odpowiedzią w tej sytuacji, gdy potwierdzisz, że problem jest upstream, a nie lokalny.

Najczęściej zadawane pytania