NCam ECM Timeout: Jak to naprawić (Pełny przewodnik)

Jeśli szukasz rozwiązania problemu z timeoutem ECM w NCam, prawdopodobnie już patrzyłeś na logi pełne linii takich jakECM (0x0963) timeout (3000 ms) podczas gdy kanały zamarzają lub stają się czarne w trakcie transmisji. Frustrująca część? Większość porad w internecie po prostu mówi "zwiększ wartość timeoutu" — co nic nie naprawia i w rzeczywistości sprawia, że zamarzania wydają się dłuższe. Ten przewodnik przechodzi przez rzeczywiste przyczyny, od martwych czytników upstream po zablokowany slot CI w twoim własnym urządzeniu.

Zanim dotkniesz jakiejkolwiek konfiguracji, zrozum, na co właściwie patrzysz. Timeout to nie to samo co nieudane dekodowanie, a traktowanie ich tak samo marnuje godziny.

Co właściwie oznacza timeout ECM w NCam

Każdy zaszyfrowany kanał wysyła ECM-y — wiadomości kontrolne uprawnień — mniej więcej co 10 sekund. Twój klient NCam łapie jeden, wysyła go do czytnika (lokalna karta, peer sieciowy, emulator) i czeka na odpowiedź kontrolną. Ta odpowiedź kontrolna to to, co faktycznie deszyfruje strumień. Jeśli nie przychodzi odpowiedź w skonfigurowanym oknie czasowym, NCam rejestruje timeout i albo próbuje ponownie, albo przełącza się na inny czytnik.

Cykl żądania/odpowiedzi ECM wyjaśniony

Przepływ wygląda tak: dvbapi przechwytuje ECM ze strumienia → NCam kieruje go do najlepszego dostępnego czytnika na podstawie balansu obciążenia → czytnik/serwer dekoduje go za pomocą karty → zwrócona odpowiedź kontrolna → dvbapi przekazuje ją do dekodera. Cała podróż w zdrowej konfiguracji z lokalnym czytnikiem zazwyczaj trwa poniżej 300 ms. W przypadku peera sieciowego z jednym skokiem, możesz zobaczyć 400–800 ms. Jeśli zaczynasz widzieć 1500+ ms konsekwentnie, to timeouty stają się kwestią "kiedy", a nie "czy".

Ta wartość ecm-timeout (domyślnie 3000 ms w większości wersji) to czas, jaki NCam czeka, zanim zrezygnuje z czytnika dla tego konkretnego żądania ECM. Trzy sekundy brzmią jak dużo. Ale jeśli twój okres kryptograficzny wynosi 10 sekund, a ty czekasz 3 sekundy, potem próbujesz innego czytnika, a następnie czekasz kolejne 3 — już jesteś w następnym okresie kryptograficznym bez odpowiedzi kontrolnej. Ekran staje się czarny.

Odczytywanie linii timeoutu w logu NCam

Typowa linia timeoutu wygląda mniej więcej tak:

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

Rozkładając to na czynniki:0963 to CAID (system szyfrowania — Sky w tym przypadku),000000 to identyfikator dostawcy,12AB to identyfikator usługi (konkretny kanał), a3000 ms to okno timeoutu, które wygasło. Nazwa czytnika (MyReader) informuje, który źródło upstream nie odpowiedziało. To twój pierwszy trop.

Timeout vs. 'Nie znaleziono' vs. 'Odrzucone' — Różne problemy

To jest rzecz, której prawie nikt nie wyjaśnia poprawnie. Te trzy wyniki mają zupełnie różne przyczyny:

• Timeout — Czytnik był osiągalny, żądanie zostało wysłane, ale nie przyszła odpowiedź na czas. Przyczyny: wysoka latencja, przeciążony serwer, martwe połączenie, lokalny problem z sygnałem.
• Nie znaleziono — Czytnik odpowiedział, ale nie ma karty/uprawnień dla tego CAID lub dostawcy. Zła karta, zły pakiet, lub karta po prostu nie jest subskrybowana.
• Odrzucone — Peer aktywnie odmówił żądania. Zwykle filtracja SID/CHID po stronie serwera, lub fałszywe/sfałszowane ECM jest blokowane.

Jeśli ścigasz timeout z poprawkami przeznaczonymi dla "nie znaleziono" — sprawdzając uprawnienia, zmieniając serwery — będziesz krążyć w kółko. Słowo kluczowe w logu to wszystko. Przeczytaj je najpierw.

Dostosowywanie timeoutu i parametrów czytnika

Lokalizacje plików konfiguracyjnych różnią się nieco w zależności od wersji, ale w większości wbudowanych konfiguracji Linux (np. Enigma2) szukasz/etc/tuxbox/config/ lub/var/keys/. Na serwerze samodzielnym zazwyczaj/etc/oscam/. Główne pliki, z którymi będziesz pracować tooscam.conf,oscam.server, ioscam.dvbapi.

ecm-timeout w [global] i Per-Reader

Globalne ustawienie znajduje się woscam.conf pod[global] blokiem:

[global]

Możesz to nadpisać dla każdego czytnika woscam.server:

[reader]

Zwiększenie ecm-timeout z 3000 do 5000 ms daje wolnym peerom więcej czasu na odpowiedź. To zapewnia stabilne dekodowanie na granicznym serwerze. Ale — i to jest ważne — oznacza to również, że każdy nieudany ECM teraz zajmuje 5 pełnych sekund, zanim uruchomi się failover. Jeśli masz trzy czytniki, a jeden jest martwy, każde przełączanie kanału potencjalnie czeka 5 sekund na martwego czytnika, zanim trafi na działający. Zwiększenie limitu czasu bez naprawienia podstawowego problemu pogarsza doświadczenie użytkownika, a nie poprawia.

lb_retrylimit i lb_reopen_seconds dla Load Balancing

Load balancer NCam śledzi, które czytniki działają dobrze i kieruje nowe ECM-y odpowiednio. Dwa ustawienia kontrolują, jak radzi sobie z złymi czytnikami:

[global]

lb_retrylimit ustawia czas odpowiedzi ECM (w ms), powyżej którego czytnik jest depriorytyzowany. Przy 900 ms każdy czytnik, który konsekwentnie zajmuje więcej czasu, jest przesuwany w dół listy.lb_reopen_seconds kontroluje, jak długo NCam czeka, zanim da złemu czytnikowi kolejną szansę — 900 sekund (15 minut) zapobiega ciągłemu atakowaniu martwego peera przy każdym żądaniu ECM i dodawaniu 3-sekundowych opóźnień w całym systemie. Jeśli to ustawienie jest zbyt niskie (jak 60 sekund) i masz rzeczywiście martwego upstreama, NCam ciągle próbuje go ponownie, a każda próba to kolejny timeout, który wpływa na twój strumień.

cccmaxhops, cccwantemu i Limity Specyficzne dla Czytnika

DlaCCcam czytników,cccmaxhops ogranicza, ile skoków karta może przejść, zanim NCam ją zignoruje. Trzymaj to na 1 lub maksymalnie 2. Karty oddalone o 3–5 skoków są bezużyteczne dla czasu ECM — dodajesz opóźnienie wielu pośrednich serwerów.

[reader]

Ustawcccwantemu = 0 chyba że naprawdę chcesz emulowane karty od tego peera. Emulowane wpisy mogą pojawić się w load balancerze i zawieść na rzeczywistych zaszyfrowanych kanałach, powodując fałszywe timeouty.

Gdzie znajdują się pliki konfiguracyjne i jak je przeładować

Po edytowaniu nie potrzebujesz pełnego restartu. W interfejsie webowym NCam (zwykle podhttp://your-box:8888), przejdź doKonfiguracja → Restart lub użyj przycisku Przeładuj czytniki. Alternatywnie, wyślij SIGHUP do procesu:killall -HUP oscam. Zmiany woscam.server wchodzą w życie natychmiast po przeładowaniu. Zmiany woscam.conf [global] zazwyczaj wymagają pełnego restartuprocesu oscam, a nie tylko przeładowania czytnika.

Opóźnienie sieciowe i przyczyny po stronie serwera

Zanim zmienisz jakąkolwiek wartość konfiguracyjną, ustal, gdzie faktycznie występuje opóźnienie. Zmiana ecm-timeout, gdy problemem jest martwy czytnik upstream, nic nie osiągnie. Spędź najpierw 10 minut na pomiarach.

Mierzenie czasu przejazdu do upstream peer

Zacznij od podstawowego pingu do adresu IP serwera lub nazwy hosta. Jeśli otrzymujesz czasy pingu powyżej 200 ms na serwerze, który powinien być w Europie, to jest twój problem. Następnie przejdź głębiej zmtr (Traceroute Matta):

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

To pokazuje utratę pakietów i opóźnienia na każdym hopie. Pojedynczy hop z 40% utratą pakietów w środku trasy spowoduje sporadyczne timeouty ECM, nawet przy zdrowym serwerze po drugiej stronie. Rozwiązaniem jest ścieżka sieciowa, a nie konfiguracja NCam.

Teraz porównaj z interfejsem webowym NCam. W sekcjiStatuskolumna czasu ECM pokazuje rzeczywiste czasy odpowiedzi dla każdego czytnika. Jeśli konsekwentnie widzisz tam 1200–1800 ms przy timeoutcie 3000 ms, żyjesz na krawędzi. Jeden zły moment i masz timeout.

MTU, fragmentacja i problemy z portami (domyślny zakres 12000)

Protokół CCcam zazwyczaj działa na porcie 12000 (konfigurowalnym w linii urządzenia twojego czytnika). Camd35 zazwyczaj używa 15000 lub 15001. To są połączenia TCP, więc fragmentacja MTU nie powinna być problemem — ale tabele stanu zapory mogą cicho zrywać nieaktywne połączenia.

To jest przyczyna problemu "timeoutów po bezczynności", który zaskakuje ludzi. Oglądasz kanał przez 20 minut, przestajesz, wracasz godzinę później, a on nie dekoduje. Połączenie technicznie nadal jest "aktywne" z perspektywy NCam, ale NAT/zapora zrzuciła wpis stanu. Rozwiązanie: włącz TCP keepalives na poziomie systemu operacyjnego lub skonfiguruj swój router, aby używał dłuższego timeoutu śledzenia połączeń dla tych portów. Na routerach opartych na OpenWrt, zwiększnf_conntrack_tcp_timeout_established powyżej 7200 sekund.

Przeciążony serwer: szczyty czasu ECM pod obciążeniem równoległym

Pojedyncza fizyczna karta smart może odpowiedzieć tylko na jeden ECM w danym czasie. Jeśli serwer ma 50 klientów dzielących jedną kartę i wszyscy 50 jednocześnie uderzają w odświeżenie okresu kryptograficznego, ta karta ma kolejkę. Czas ECM wzrasta do 2000–3000 ms. W godzinach szczytu (wieczory, weekendowe wydarzenia sportowe) sytuacja staje się dramatycznie gorsza. Karta nie jest uszkodzona, serwer nie jest źle skonfigurowany — to po prostu matematyka. Zbyt wielu klientów na kartę.

Zobaczysz ten wzór wyraźnie: czasy ECM w interfejsie webowym są stabilne na poziomie 400 ms przez całe przedpołudnie, a następnie wzrastają do 1800 ms od 19:00. To jest nadmierna subskrypcja serwera, kropka. Żadne lokalne dostosowanie NCam tego nie naprawi. Jedynym prawdziwym rozwiązaniem timeoutu ECM w NCam w tej sytuacji jest znalezienie serwera z mniejszą liczbą klientów na kartę lub dodanie drugiego upstream peera z tym samym CAID jako zapasowego.

Lokalne problemy z tunerem/CI, które wyglądają jak timeouty

Oto ten, który marnuje najwięcej czasu diagnostycznego: problem nie ma nic wspólnego z siecią. Zablokowany slot CI (Common Interface), uszkodzony wewnętrzny czytnik kart lub słaby sygnał satelitarny mogą generować wpisy timeoutów ECM w logach NCam — ponieważ ECM został przechwycony z złego strumienia lub CI nie zwrócił żadnego słowa kontrolnego, a NCam zarejestrował to jako timeout.

Sprawdź poziomy sygnału w menu swojego odbiornika. SNR poniżej około 12 dB w większości konfiguracji lub jakość sygnału poniżej 80% zaczyna generować uszkodzone pakiety. To obejmuje uszkodzone ECM. NCam nie może dekodować zniekształconego ECM; ma timeout czekając na odpowiedź, która nie może nadejść, ponieważ wejście było śmieciem od samego początku. Spróbuj tego samego kanału na transponderze z dobrze znaną siłą sygnału i zobacz, czy timeouty znikają. Jeśli tak, problem leży w twojej antenie, LNB lub kablu — nie w NCam.

Krok po kroku: proces diagnostyczny

Największym błędem, jaki popełniają ludzie, jest zmiana dwóch lub trzech rzeczy jednocześnie, a potem nie wiedzą, która zadziałała. Oto podręcznik, którego używam. Zmień jedną zmienną. Obserwuj przez minimum 15 minut. Następnie przejdź do następnego kroku.

Włącz szczegółowe logowanie (poziom debugowania) bezpiecznie

Woscam.conf [global], tymczasowo zwiększ logging:

[global]

Poziom debugowania 64 daje szczegóły routingu ECM bez ekstremalnej werbalności pełnego debugowania (255). Nie zostawiaj pełnego debugowania na stałe — na sprzęcie wbudowanym z wolnym magazynem, zapisywanie megabajtów logów na godzinę do pamięci flash skróci żywotność urządzenia i może powodować opóźnienia I/O, które wpływają na samo dekodowanie. Włącz to, odtwórz problem, a następnie wyłącz.

Skoreluj znaczniki czasowe logów z zamarznięciem

Kiedy kanał zamarza, zanotuj dokładny czas. Wyciągnij log i sprawdź 5–15 sekund przed tym znacznikiem czasowym — czas oczekiwania ECM pojawia się przed widocznym zamarznięciem, ponieważ słowo kontrolne kończy się nieco po tym, jak żądanie się nie powiedzie. Jeśli widzisz skupisko linii timeout o 21:04:25, a ekran zgasł o 21:04:33, to jest twoje zdarzenie. Zanotuj CAID, PROVID i SID z tych linii.

Testuj jednego czytnika na raz

Woscam.serverwyłącz wszystkich czytników oprócz jednego, dodającenable = 0 do każdego bloku, który chcesz pominąć, a następnie przeładuj. Wymuś tuning do problematycznego kanału. Obserwuj zakładkę Status w webif — szczególnie kolumnę czasu ECM oraz liczniki ecmok/ecmnok dla twojego aktywnego czytnika. Jeśli ten czytnik ma timeout przy zerowym obciążeniu (tylko twoja pojedyncza sesja), problemem jest opóźnienie tego czytnika lub twoje połączenie z nim. Jeśli odpowiada poprawnie, włącz następnego czytnika i przetestuj z oboma.

To podejście z jednym czytnikiem jest najszybszą diagnostyką naprawy timeoutów ECM w NCam, jaką znam. Natychmiast eliminuje problemy z równoważeniem obciążenia i efekty interakcji czytników.

Potwierdź naprawę bez fałszywych pozytywów

Jedno udane przełączenie kanału nie potwierdza naprawy. NCam krótko buforuje ostatnie ważne słowo kontrolne, więc możesz przełączyć, uzyskać obraz, myśleć, że to naprawione — a potem zamarza 10 sekund później, gdy rozpoczyna się następny okres kryptograficzny i ten sam timeout występuje ponownie. Obserwuj licznik ecmok w webif przez co najmniej 15 minut, na konkretnym kanale, który zawodził. Chcesz widzieć, jak ecmok zwiększa się co 10 sekund z czasami ECM znacznie poniżej ustawienia timeoutu, z zerowymi zdarzeniami ecmnok w tym oknie. To potwierdzona naprawa.

Jak wybrać niezawodne źródło upstream

Uzyskanie solidnego peer'a upstream to długoterminowa naprawa timeoutów ECM w NCam, której nie zastąpi żadne dostosowanie lokalnej konfiguracji. Oto, co naprawdę ma znaczenie przy ocenie źródła.

Kryteria, które korelują z niskim czasem ECM

Czas odpowiedzi ECM jest najlepszym predyktorem niezawodności. Każdy przyzwoity peer powinien dostarczać czasy odpowiedzi poniżej 700 ms dla potrzebnego CAID, mierzonych w godzinach szczytu — nie tylko o 2 w nocy, gdy serwer jest bezczynny. Bliskość geograficzna ma tutaj znaczenie: serwer fizycznie blisko ciebie na niskolatencyjnej trasie sieciowej zawsze przewyższy "premium" serwer na zatłoczonej trasie transatlantyckiej.

Liczba hopów to kolejny ważny czynnik. Karta dzielona 1 hop od źródła (peer obsługuje rzeczywistą kartę) zawsze przewyższy kartę 3 hopów głęboko przez łańcuch ponownego udostępniania. Każdy hop dodaje opóźnienie i potencjalny punkt awarii. Zapytaj konkretnie, ile hopów od fizycznej karty przemieszcza się twoje żądanie ECM. Cokolwiek powyżej 2 to czerwona flaga.

Czerwone flagi, które przewidują częste timeouty

Czasy ECM powyżej 1200 ms w okresie testowym powinny natychmiast zdyskwalifikować źródło. To już 40% twojego domyślnego budżetu timeoutowego wydane, bez marginesu na zmienność. Serwery bez limitu klientów mają tendencję do stopniowego pogarszania się w miarę przyjmowania większej liczby użytkowników — obserwuj, czy czasy ECM są stabilne w 30-minutowym oknie obserwacyjnym, czy powoli rosną.

Brak oferowanego okresu testowego to sama w sobie czerwona flaga. Każdy operator pewny wydajności swojego serwera pozwoli ci go przetestować. Jeśli nie możesz zweryfikować czasu ECM przed zobowiązaniem, działasz w ciemno.

Testowanie przed zobowiązaniem

Skonfiguruj nowego peera jako jednego czytnika woscam.server z wyłączonymi wszystkimi innymi czytnikami. Przeprowadź go przez szczytowy okres wieczorny — wtedy pojawiają się problemy z nadsubskrypcją. Obserwuj kolumnę czasu ECM w webif. Serwer pokazujący 350 ms w południe i 2400 ms o 20:00 jest nadsubskrybowany i regularnie spowoduje timeouty. Serwer utrzymujący 400–600 ms w godzinach szczytu jest wart zachowania. Stosunek ecmnok/ecmok powinien pozostawać znacznie poniżej 5% na niezawodnym źródle — jeśli widzisz 15% awarii ECM, nawet gdy czasy odpowiedzi wyglądają w porządku, należy oddzielnie zbadać problem z filtrowaniem lub uprawnieniami.