Błąd NCam "Nie można dekodować": Przyczyny& Rozwiązania

Jeśli szukasz rozwiązania problemu "nie można dekodować" w ncam, pierwszą rzeczą, którą musisz zrozumieć, jest to, że ten błąd nie jest jednym problemem — to co najmniej cztery różne problemy, które generują ten sam komunikat w logach. Restartowanie NCam i ponowne wprowadzenie twojej linii to porada, którą znajdziesz na większości forów. To prawie nic nie naprawia. Ten przewodnik przechodzi przez rzeczywistą przyczynę, śledząc cykl życia ECM od analizy PMT do zastosowania słowa kontrolnego, abyś mógł dokładnie zidentyfikować, gdzie twoja konfiguracja się psuje.

Co "Nie można dekodować" naprawdę oznacza w NCam

NCam jest forkiem OSCam. Katalog konfiguracyjny zazwyczaj znajduje się w/etc/tuxbox/config/ a pliki mają nazwy w formacie oscam.* —ncam.conf,ncam.server,ncam.dvbapi,ncam.user. Jeśli jesteś przyzwyczajony do OSCam, struktura jest identyczna. Zachowanie również jest identyczne, w tym sposób rejestrowania błędów dekodowania.

Komunikat "nie można dekodować" oznacza, że NCam albo otrzymał słowo kontrolne (CW) od czytnika, ale dekoder je odrzucił, albo żadne CW nie dotarło na czas. Strumień pozostaje zaszyfrowany. Urządzenie pokazuje czarny ekran. To różni się od trzech innych stanów błędu, które zobaczysz w logach:

• brak dostępnego źródła — żaden czytnik nie pasował do CAID
• sid nie znaleziony — identyfikator usługi nie znajduje się na liście kanałów żadnego czytnika
• brak pasującego czytnika — CAID istnieje, ale filtr dostawcy/grupy zablokował czytnik

"Nie można dekodować" konkretnie oznacza, że pipeline ECM poszedł dalej — skontaktowano się z czytnikiem — ale ostatni krok dekodowania nie powiódł się. To jest istotna różnica.

Linia logu i miejsce, w którym się pojawia

Otwórz interfejs webowy NCam podhttp://your-box-ip:8888 (lub cokolwiekhttpport ustawiłeś w[webif]) i przejdź do Live Log. Szukasz linii oznaczonychdvbapi oraz wpisów pokazującychecm hash,brak cw, lub wyraźnienie można dekodować ciągu. Ścieżka do pliku dziennika jest ustawiona w[global] wncam.conf — zazwyczajlogfile = /var/log/ncam.log lub/tmp/ncam.log na systemach wbudowanych.

Niepowodzenie dekodowania vs. brak żądania ECM vs. ECM odrzucone

To tutaj większość rozwiązywania problemów idzie źle. "Brak żądania ECM" oznacza, że warstwa dvbapi nigdy nie poprosiła o CW — to jestproblem z pmt_mode lub gniazdem. "ECM odrzucone" oznacza, że serwer odpowiedział błędem. "Nie można dekodować" oznacza, że CW dotarło, ale nie działało. Te trzy wyniki wymagają zupełnie różnych poprawek, a w dzienniku wyglądają powierzchownie podobnie, jeśli nie czytasz uważnie.

Jak NCam różni się od nazewnictwa OSCam dvbapi

Prawie wcale, szczerze mówiąc. Plikncam.dvbapi używa tej samej składni P:/I:/D: cooscam.dvbapi. Niektóre wersje umieszczają konfiguracje w/usr/keys/ zamiast/etc/tuxbox/config/ — sprawdź swój konkretny obraz. Port webif domyślnie ustawiony jest na 8888 w większości wersji NCam w porównaniu do 8888 OSCam, więc tutaj nie ma zmiany.

Przeczytaj dzienniki przed wprowadzeniem jakichkolwiek zmian

Serio. Każda zmiana konfiguracji, którą wprowadzasz w ciemno, dodaje nową zmienną. Zanim cokolwiek dotkniesz, uzyskaj czysty ślad tego, co NCam faktycznie robi z jednym konkretnym kanałem.

Włącz pełne logowanie (debug 255) bezpiecznie

Wncam.conf pod[global], ustawdebug = 255 tymczasowo. To loguje wszystko: analizę PMT, wybór PID ECM, dopasowanie czytnika, synchronizację CW i wywołania dekodera. Na Pi lub słabym STB, to zalać dziennik i może faktycznie spowolnić rzeczy na tyle, aby spowodować opóźnione CW — co tworzy objaw, który wygląda jak problem, który próbujesz zdiagnozować. Złap 60 sekund logu dla jednego kanału, a następnie ustawdebug = 0 ponownie. Nie zostawiaj tego włączonego.

Możesz również przełączać szczegółowość dla każdego czytnika w webif bez edytowania pliku, co jest czystsze podczas debugowania na żywo.

Śledzenie cyklu życia ECM: żądanie, znalezione, cw, dekodowanie

Udany ślad dekodowania wygląda tak w kolejności: dvbapi analizuje PMT i znajduje PID ECM, NCam wybiera PID i wysyła żądanie ECM do dopasowanego czytnika, czytnik zwraca CW, NCam przekazuje CW do dekodera, dekoder stosuje to, a strumień jest odszyfrowany. "Nie można dekodować" łamie się na tym ostatnim kroku — albo CW nigdy nie dotarło, dotarło za późno, albo dotarło błędnie.

Szukaj linii pokazującej czas ECM w milisekundach. Coś takiego jakczas ecm: 340ms jest w porządku. 1800ms na kanale z okresem kryptograficznym 1,8 sekundy oznacza, że CW przychodzi tuż na krawędzi i może być odrzucane.

Wykrywanie niezgodności CAID/dostawca/SID w śladzie

Z aktywnym debugiem 255 zobaczysz pełną parę CAID:provid, której NCam używa do dopasowania czytnika. Jeśli twój czytnik macaid = 0500 ale ECM kanału jest oznaczone dostawcą032830 a liniausługi lubident nie zawiera tego dostawcy, NCam dopasowuje na podstawie CAID, ale czytnik odrzuca konkretny ECM. Log pokaże, że czytnik próbował, ale nie zwrócił nic ważnego.

Napraw powiązanie dvbapi i mapowanie PID

To najczęstsza przyczyna potrzeby naprawy ncam cannot decode w konfiguracji, która wcześniej działała — coś w powiązaniu dvbapi jest nie tak, czy to z powodu aktualizacji obrazu, ponownego strojenia kanału, czy konfiguracji, która nigdy nie była poprawna.

składnia ncam.dvbapi: linie P/I/D, CAID, provid, SID, PID ECM

Plikncam.dvbapi kontroluje, jak NCam mapuje kanały na źródła ECM. Oto konkretny przykład:

# Preferuj dostawcę 032830 na CAID 0500

Forma czteropolowaP: CAID:provid:SID:ecmpid jest tym, co używasz, gdy automatyczne wykrywanie wybiera zły PID ECM. To ma większe znaczenie, niż przyznają to większość przewodników — kanał z wieloma PID ECM pod tym samym CAID będzie miał NCam zgadującego, a często zgaduje źle po ponownym przeskanowaniu kanału.

boxtype / tryb dvbapi (au, pmt_mode, listen_socket)

Wncam.conf blok[dvbapi] musi odpowiadać twojemu sprzętowi i obrazowi. Typowa konfiguracja enigma2 wygląda tak:

[dvbapi]

Złypmt_mode to cichy zabójca — NCam nigdy nie otrzymuje PMT, nigdy nie żąda ECM, a log po prostu pokazuje, że nic się nie dzieje dla tego kanału. Urządzenie wydaje się zawieszone bez żadnego błędu. Różne obrazy enigma2 (OpenATV, OpenPLi, OpenViX, E2iPlayer) zachowują się tutaj różnie.

Wymuszanie poprawnego PID ECM, gdy automatyczne wykrywanie wybiera zły

To najczęściej dotyka ludzi, gdy kanał ma zarówno główny, jak i zapasowy ECM, lub gdy FTA i zaszyfrowany dźwięk dzielą ten sam strumień transportowy. Warstwa dvbapi NCam analizuje PMT i widzi wiele PID ECM. Przy debugowaniu 255 zobaczysz wszystkie wymienione. Log pokazuje coś takiego:

dvbapi: znaleziono 2 ECMpids dla SID 0x1234: 0x0640 (CAID 0500) 0x0641 (CAID 0500)

NCam wybiera pierwszy. Jeśli tylko drugi jest ważny dla dostawcy twojego czytnika, otrzymasz CW, ale nie zostanie on odszyfrowany. Przypisz go wyraźnie za pomocą czteropolowej linii P: jak pokazano powyżej. Po zmianie parametrów nadawania kanału, stare linie pin w ncam.dvbapi mogą wskazywać na PID ECM, które już nie istnieją — kanał cicho nie otrzymuje ECM i wracasz do czarnego ekranu.

Uprawnienia i ścieżka urządzenia /tmp/camd.socket / dvbapi

Na STB opartych na Linuksie, NCam potrzebuje uprawnień do zapisu w/tmp/camd.socket i czytaj z/dev/dvb/adapter0/ca0 (i węzłów demux). Jeśli NCam działa jako użytkownik nie-root, sprawdź, czy użytkownik jest w grupievideo i czy ścieżka do gniazda jest zapisywalna. Błąd uprawnień tutaj powoduje, że NCam cicho nie wiąże — otrzymujesz ten sam objaw czarnego ekranu, co przy niezgodności pmt_mode, ale log pokaże błąd wiązania gniazda, jeśli oglądasz na debug 255.

Kiedy problemem jest karta/udział, a nie NCam

Gdy potwierdzisz, że dvbapi działa i ECM jest żądany i odpowiada, ale kanał nadal nie dekoduje, problem przesunął się w górę. To druga część każdej właściwej analizy problemu z dekodowaniem przez ncam.

ECM odpowiedział, ale CW nieprawidłowy: zły klucz, AES/CWPK lub tier

Niektóre systemy — warianty Nagra, niektóre implementacje Conax — nakładają dodatkowy klucz na CW. Czytnik zwraca to, co wygląda na ważne CW, NCam je stosuje, a dekoder produkuje śmieci. To jest niezgodność AES lub CWPK. Udział ma prawidłowy CAID i dostawcę, ale inny wariant klucza niż ten, którego wymaga Twoja treść. Zobaczysz, że ECM zakończył się pomyślnie w logu, ale strumień nie jest odszyfrowany. Napraw: zweryfikuj dokładny wariant CAID, którego używa Twój kanał (0500 i 0503 są różne) i potwierdź, że udział wyraźnie obejmuje ten wariant.

Brakujący tier to inny przypadek: karta lub konto ma CAID 0500, ale nie konkretny pakiet subskrypcyjny, który odblokowuje ten kanał. ECM jest odpowiedziane (karta je przetwarza), ale zwraca null lub nieprawidłowy CW. Niektórzy czytnicy logują to wyraźnie jakocw nie znaleziono .

BISS, tunelowanie (stałe CW) i specjalne przypadki Powervu

Kanały szyfrowane BISS i kanały z stałym CW (tunelowanie) w ogóle nie używają ECM. Jeśli próbujesz odszyfrować kanał BISS przez normalną ścieżkę ECM, otrzymasz wieczne "nie można dekodować", ponieważ nie ma ECM do odpowiedzi. Klucze BISS trafiają doncam.keys lubSoftCam.Key w zależności od Twojego obrazu, używając standardowego formatu dla SID. PowerVU jest podobny — wymaga specyficznego traktowania i odpowiedniego pliku klucza, a nie czytnika udostępniającego.

Jeśli Twój kanał jest BISS i debugujesz go jako błąd ECM, debugujesz całkowicie niewłaściwą rzecz.

Opóźnienie, timeout ecm i błędy dekodowania 'cw za późno'

W[global] plikuncam.conf,ctimeout = 1500 ustawia maksymalne milisekundy, które NCam czeka na CW. Jeśli udział zajmuje 1600 ms na odpowiedź, CW przychodzi po ctimeout i zostaje odrzucone. Log pokazujecw za późno lub podobnie. Kanał pozostaje czarny, mimo że klucz był technicznie poprawny.

Strojenie: możesz zwiększyćctimeout do 2500 ms jako test, ale prawdziwą naprawą jest szybszy udział lub mniej skoków. W czytnikach CCC,cccmaxhops kontroluje, ile węzłów ponownego udostępniania ECM przechodzi — każdy skok dodaje opóźnienie. Ustaw go na 1 lub 2, jeśli możesz.ccckeepalive = 1 zapobiega opóźnieniu renegocjacji połączenia na serwerach obsługujących keepalive.

Dopasowanie czytnika: lokalne karty, czytnik ccc/cccam, grupa/usługi

Usługi NCam i and grupa filtry wncam.server incam.user mogą cicho zablokować SID z czytnika. Jeśli skonfigurujesz białą listę usług lub tabelę SID wncam.services (sidtab) i bieżący kanał nie jest w niej, NCam nie przekaże ECM do tego czytnika. Czytnik pokazuje, że jest online. CAID się zgadza. Ale SID jest filtrowany przed wysłaniem ECM. Sprawdźusługi = igrupa = w konfiguracji czytnika i upewnij się, że SID kanału jest dozwolony.

Krok po kroku Lista kontrolna diagnostyczna

Wykonaj te kroki w kolejności. Każdy krok dokładnie wskazuje, która warstwa jest uszkodzona. To jest systematyczny proces naprawy ncam, który nie może dekodować — nie pomijaj kroków, nawet jeśli myślisz, że znasz odpowiedź.

Potwierdź, że czytnik jest online i ma odpowiedni CAID

1. Otwórz webif → Czytniki. Potwierdź, że status jest zielony/połączony, a nie czerwony.
2. Sprawdź, czy lista CAID czytnika zawiera dokładny CAID twojego kanału. 0500 ≠ 0503 ≠ 0504.
3. Jeśli używasz czytnika CCC/CCcam wncam.server, zweryfikujprotokół = cccam, poprawny host/port oraz żeużytkownik/hasło zgadzają się dokładnie z serwerem — w tym wielkość liter.
4. Sprawdźgrupa = w czytniku igrupa = w koncie użytkownika. Muszą dzielić przynajmniej jeden numer grupy.

Potwierdź, że dvbapi żąda ECM (nie cicho)

1. Ustawdebug = 255, dostrój się do nieudającego kanału, sprawdź log na żywo w ciągu 10 sekund.
2. Szukajdvbapi: otrzymano PMT lub równoważne. Jeśli brak, NCam nie odbiera PMT — błędnypmt_mode lub ścieżka gniazda.
3. Szukaj linii PID ECM pokazującej CAID i wybrany PID NCam. Jeśli brak po zobaczeniu PMT, sprawdź linie I: wncam.dvbapi blokujących ten CAID.
4. Potwierdź, że gniazdo/tmp/camd.socket istnieje i jest zapisywalne przez proces NCam.

Potwierdź, że CW wraca i jego czas

1. W logu znajdź linię żądania ECM, a następnie poszukaj linii odpowiedzi CW pokazującej czas (np.czas ecm: 342ms).
2. Jeśli brak odpowiedzi CW: czytnik otrzymał ECM, ale nie mógł na nie odpowiedzieć. Sprawdź poziom/subskrypcję na karcie lub niezgodność CAID:provid na udostępnieniu.
3. Jeśli odpowiedź CW istnieje, ale czas >1500ms: napotykaszctimeout. Przetestuj zctimeout = 3000 w[global] tymczasowo.
4. Jeśli odpowiedź CW jest szybka i czysta, ale kanał nadal się nie dekoduje: niezgodność AES/CWPK, zły PID ECM lub kanał BISS/stała CW jest źle obsługiwany.

Izoluj jeden kanał/CAID na raz

1. Przetestuj z znanym kanałem na tym samym CAID, który powinien działać. Jeśli to również zawiedzie, problem leży w czytniku/udostępnieniu, a nie w konkretnym kanale.
2. Jeśli tylko jeden kanał zawodzi: sprawdź unikalną sytuację PID ECM lub SID, który jest w innym poziomie subskrypcyjnym.
3. Jeśli wszystkie kanały na jednym CAID zawodzą: czytnik jest podłączony, ale nieautoryzowany dla tego CAID.
4. Jeśli wszystkie kanały na wszystkich CAID zawodzą: powiązanie dvbapi jest uszkodzone na poziomie gniazda/pmt_mode.

Jeśli każdy krok powyżej się zgadza — czytnik online, poprawny CAID, żądany ECM, szybki CW zwrócony — ale dekodowanie nadal zawodzi, masz do czynienia z problemem klucza/poziomu/strumienia, a nie problemem konfiguracji NCam. Naprawa leży po stronie źródła, a nie w plikach konfiguracyjnych.