CCcam DVBAPI Delayer: Naprawa Zawieszania& Przewodnik Konfiguracyjny

Jeśli trafiłeś tutaj, ponieważ Twoje kanały zawieszają się co 10 sekund, masz do czynienia z wyścigiem czasowym — nie z złym sygnałem.Konfiguracja CCcam dvbapi delayer jest pokrętłem, które to naprawia. Ten przewodnik dokładnie opisuje, jak to ustawić, jak czytać logi, aby odpowiednio to dostroić, i kiedy nie pomoże, abyś nie tracił trzech godzin na ściganie niewłaściwej rzeczy.

Co tak naprawdę robi DVBAPI Delayer

Interfejs DVBAPI to sposób, w jaki Twoja dekoder (lub odbiornik oparty na Linuksie działający na Enigma2, na przykład) udostępnia swoje CA descrambler dla oprogramowania użytkowego. Zamiast używać fizycznego CAM, klient DVBAPI, taki jak OScam lub wbudowany plugin DVBAPI CCcam, zapisuje słowa kontrolne (CW) bezpośrednio do demuxera przez/dev/dvb/adapterX/caY.

Delayer wstawia pauzę — mierzona w milisekundach — pomiędzy momentem, w którym oprogramowanie otrzymuje odszyfrowane CW, a momentem, w którym zapisuje to CW do sprzętu. Bez tej pauzy, CW może przyjść szybciej, niż demuxer jest gotowy do jego przetworzenia. Rezultat: czarny ekran, zawieszenie lub krótkie zacięcie przy każdej zmianie klucza.

Czasowanie ECM do słowa kontrolnego w CCcam DVBAPI

Szybkie definicje, abyśmy byli na tej samej stronie.ECM (Entitlement Control Message) to krótki zaszyfrowany pakiet nadawany w strumieniu DVB. Twój klient udostępniania wysyła go w górę, karta go odszyfrowuje i zwracasłowo kontrolne — rzeczywisty 8-bajtowy klucz, którego Twój descrambler potrzebuje do dekodowania wideo. Cała ta podróż trwa kilka milisekund, w zależności od Twojego sygnału.

Większość dostawców płatnej telewizji rotuje swoje klucze cookres kryptograficzny wynoszący około 10 sekund. Kiedy okres się zmienia, przychodzi nowe ECM, pobierane jest nowe CW, a klient DVBAPI musi zapisać je do demuxera w dokładnie odpowiednim momencie. Zbyt wcześnie i sprzęt je odrzuca. Zbyt późno i otrzymujesz lukę w zawieszeniu.

Dlaczego potrzebna jest opóźnienie przed zapisaniem CW do demuxera

Sprzęt demuxera w wielu odbiornikach — szczególnie starszych jednostkach Dreambox i budżetowych pudełkach Enigma2 — ma małe okno, w którym zaakceptuje nowe CW. Jeśli Twój klient udostępniania jest szybki (co zazwyczaj jest dobre), może wygrać wyścig z hardwarem i zapisać przed tym, jak demuxer zakończy przejście do nowego okresu kryptograficznego.

Delayer zmusza oprogramowanie do zatrzymania się na CW przez N milisekund przed zapisaniem. Ta przestrzeń do oddychania pozwala sprzętowi nadrobić zaległości. Brzmi to nieintuicyjnie — spowolnienie reakcji, aby naprawić problem — ale działa, i działa konsekwentnie, gdy jest odpowiednio dostrojone.

Jak CCcam różni się od obsługi dvbapi w OScam

Natywne wsparcie DVBAPI w CCcam jest dość podstawowe. Działa, ale możliwości konfiguracyjne są ograniczone — masz globalne opóźnienie i to wszystko. Implementacja dvbapi w OScam jest znacznie bardziej dojrzała: opóźnienia per-CAID, nadpisania per-SID, interfejs webowy pokazujący czasy ECM w czasie rzeczywistym i lepsze celowanie w adaptery.

Dlatego większość produkcyjnych konfiguracji łączy CCcam z OScam: CCcam obsługuje protokół i sieć udostępniania kart, ale OScam zajmuje się rzeczywistym odszyfrowywaniem. Jeśli nadal używasz CCcam DVBAPI natywnie i walczysz z zawieszeniami, warto rozważyć migrację do OScam — więcej na ten temat w ostatniej sekcji.

Konfiguracja Delayera Krok po Kroku

Uzyskaniekonfiguracji CCcam dvbapi delayer w porządku zaczyna się od wiedzy, który plik edytować. Ścieżka różni się w zależności od Twojego obrazu i tego, czy używasz wbudowanego DVBAPI CCcam, czy łączysz przez OScam.

Lokalizacja konfiguracji: CCcam.cfg vs oscam.dvbapi

Dla czystego CCcam DVBAPI, główny plik konfiguracyjny znajduje się w/var/etc/CCcam.cfg w większości obrazów Enigma2 (OpenATV, OpenPLi, OpenViX). W starszych konfiguracjach lub obrazach opartych na Gemini możesz go znaleźć w/etc/CCcam.cfg. Sprawdź oba, jeśli nie jesteś pewien.

Jeśli używasz OScam z czytnikiem CCcam (bardziej powszechna konfiguracja), opóźnienie znajduje się w/etc/tuxbox/config/oscam/oscam.dvbapi lub/var/etc/oscam.dvbapi, w zależności od twojego obrazu. OpenATV zwykle używa/var/etc/. Obrazy OE-Alliance czasami umieszczają to pod/etc/oscam/. Uruchomfind / -name oscam.dvbapi 2>/dev/null jeśli nie możesz go znaleźć.

Ustawienie wartości opóźnienia (parametr DELAY: i zakresy ms)

WCCcam.cfg, linia wygląda tak:

DELAY : 150

To są milisekundy. Zacznij od100–300 ms i dostosuj od tego. Jeśli kanały nadal zamarzają przy zmianie klucza, zwiększ je o 50 ms. Jeśli zmiana kanałów wydaje się opóźniona — naciskasz przycisk i czekasz zbyt długo — poszedłeś za wysoko, zmniejsz to w krokach po 25 ms.

Woscam.dvbapi, format jest inny. Globalna linia opóźnienia wygląda tak:

DELAY : 150

Ale możesz także celować w konkretne wpisy. Pełny format dla wpisu to:

P: CAID:ProvID:SID:PMT_PID:ECM_PID : DELAY

Na przykład, aby ustawić opóźnienie 200 ms dla konkretnej kombinacji CAID/dostawcy, pozostawiając wszystko inne na 100 ms:

DELAY : 100

Gdzie niektóre odbiorniki udostępniają interfejs webowy dla CCcam (wbudowany serwer HTTP działa na porcie 16001 domyślnie), możesz tam również znaleźć pole "DVB API DELAY". Nie polegaj tylko na tym — zmiany przez interfejs webowy nie zawsze przetrwają ponowne uruchomienie demona, chyba że plik konfiguracyjny również zostanie zaktualizowany.

Nadpisania opóźnienia na kanałach i per-CAID

To jest to, co większość przewodników pomija. Globalne opóźnienie jest tępe — spowalnia każdą zmianę kanału w każdym CAID. Ale w praktyce problem z czasowaniem jest prawie zawsze specyficzny dla CAID lub nawet transpondera. Okres kryptograficzny jednego dostawcy synchronizuje się dobrze przy 100 ms; inny potrzebuje 250 ms, ponieważ ich ECM-y przychodzą nieco późno w stosunku do zmiany klucza.

OScamoscam.dvbapi pozwala na dokładne ustawienie opóźnień. Jeśli znasz CAID (np. 0963 lub 1810) problematycznego pakietu, ustaw wyższe opóźnienie tylko dla tego wpisu i pozostaw globalne niższe. Twój pakiet sportowy zmienia się szybko; twój pakiet filmowy pozostaje stabilny. Oba działają.

Na transponderze z mieszanymi CAID — powiedzmy, pakietem FTA multiplexowanym z zaszyfrowanym — upewnij się, że celowanie w CAID jest precyzyjne, inaczej spowolnisz zmianę kanałów, które tego nie potrzebują.

Ponowne uruchomienie demona i potwierdzenie załadunku zmiany

CCcam nie ładuje konfiguracji na gorąco. Po edytowaniuCCcam.cfg, uruchom go ponownie:

killall -9 CCcam&& sleep 2&& CCcam

Lub przez skrypt init, jeśli masz go skonfigurowanego (/etc/init.d/CCcam restart). Sprawdź/tmp/CCcam.log lub jakąkolwiek ścieżkę logu, którą skonfigurowałeś, i poszukaj linii DELAY analizowanej przy uruchamianiu.

Dla OScam wystarczy miękkie ponowne uruchomienie:

killall -HUP oscam

Lub użyj interfejsu webowego OScam na porcie 8888 → Restart. Sprawdź, czy strona informacyjna potwierdza, że wartość opóźnienia dvbapi jest zgodna z oczekiwaną.

Czytanie logów, aby znaleźć odpowiednie opóźnienie

Zgadywanie wartości opóźnienia to strata czasu. Logi dokładnie mówią, co się dzieje, a pięć minut ich czytania przewyższa godzinę prób i błędów.

Włączanie logowania debugowania (loghistorysize, poziomy logów)

W pliku OScamoscam.conf, w sekcji[global]:

[global]

Poziom 64 daje szczegóły na poziomie ECM bez zalewania logu szumem. Jeśli potrzebujesz więcej, połącz to:loglevel = 64+32 dodaje informacje debugowania czytnika. Cokolwiek wyższego i będziesz potrzebować większegologhistorysize lub historia zapełni się, zanim będziesz mógł ją przeczytać.

Dla CCcam, szczegółowość logów ustawia się wCCcam.cfg:

POZIOM DEBUG : 1

Poziom 1 zazwyczaj wystarcza, aby zobaczyć zdarzenia dostarczania CW. Poziom 3 daje pełny ruch ECM, ale generuje dużo wyjścia.

Interpretacja czasu dekodowania/zawieszenia w logu

To, czego szukasz, to czas między przybyciem ECM a dostarczeniem CW oraz jak to się ma do twoich zdarzeń zawieszenia. W logach OScam każda linia dekodowania wygląda mniej więcej tak:

[reader] (czas ecm: 87 ms) CW znaleziono [0963/000000/1234]

Ta wartość 87 ms to twój czas ECM w obie strony. Jeśli twój okres kryptograficzny wynosi 10 sekund, a twoje ECM-y przybywają z czasem dekodowania 87 ms konsekwentnie, opóźnienie 100–150 ms pokrywa lukę z marginesem. Jeśli ta liczba sporadycznie wzrasta do 400 ms (przerwa w sieci, zajęty serwer), potrzebujesz albo wyższego opóźnienia, albo lepszej linii.

Porównaj znaczniki czasowe zawieszeń w logu odbiornika z interwałem zmiany klucza. Jeśli zawieszenia występują konsekwentnie w interwałach 9.8–10.2 sekundy, to jest problem z czasowaniem, a opóźniacz to naprawi. Jeśli zawieszenia są losowe — co kilka minut, bez wzoru — to nie jest problem z czasowaniem.

Narzędzia: tail -f, strona statusu oscam, kolumna czasu ECM

Interfejs webowy OScam nahttp://[receiver-ip]:8888 ma zakładkę ECM/EMM, która pokazuje czasy dekodowania na żywo dla każdego CAID. Ta kolumna "msec" to na podstawie której dostosowujesz swoje opóźnienie. Aktualizuje się w czasie rzeczywistym.

Dla oglądania surowych logów:

tail -f /tmp/oscam.log | grep "ecm time"

Uruchom to podczas zmiany kanałów i obserwowania zawieszeń. Praktyczna metoda dostrajania: zacznij wysoko (powiedzmy, 300 ms), obserwuj opóźnienia przy zmianie kanałów, zmniejszaj o 50 ms co kilka minut, monitorując zdarzenia zawieszenia. Gdy zawieszenia się pojawią, dodaj 75 ms z powrotem jako margines bezpieczeństwa i uznaj to za zakończone.

Typowe błędne konfiguracje i jak je naprawić

Większość problemów z zawieszeniami, które ludzie przypisują opóźniaczowi, to tak naprawdę coś innego. Oto, co widzę konsekwentnie.

Opóźnienie ustawione globalnie, gdy tylko jeden CAID tego potrzebuje

UstawienieOPÓŹNIENIE : 300 globalnie, aby naprawić jeden uparty pakiet kanałowy, oznacza, że każda zmiana kanału trwa o 300 ms dłużej. Jeśli przeskakujesz przez wydarzenie sportowe i trafiasz na 15 kanałów w ciągu 30 sekund, to sumuje się do zauważalnego opóźnienia.

Rozwiązanie: zidentyfikuj CAID powodujący problemy (sprawdź dziennik ECM), ustaw wysokie opóźnienie tylko dla tego CAID woscam.dvbapi i przywróć globalne do 100 ms lub mniej.

Błędny indeks adaptera/demuxa dla boxów z wieloma tunerami

Na odbiorniku z podwójnym tunerem — powszechnym w Vu+ Duo2, Dreambox DM920 lub podobnych — masz/dev/dvb/adapter0 i/dev/dvb/adapter1, każdy z własnymca0 urządzeniem. Jeśli twój klient DVBAPI zapisuje doadapter0/ca0, ale aktywny tuner toadapter1, otrzymasz całkowite niepowodzenie dekodowania niezależnie od wartości opóźnienia.

W pliku OScamoscam.dvbapi ustawiasz adapter za pomocą:

BOXTYPE : dreambox

I zweryfikuj enumerację adaptera w/proc/bus/pci/ lub za pomocąls /dev/dvb/. Niektóre obrazy numerują tunery inaczej po aktualizacji jądra. Jeśli twoja konfiguracja się nie zmieniła, ale dekodowanie nagle przestało działać, sprawdź, czy indeksy adapterów się przesunęły.

Konflikty między CCcam DVBAPI a równoległą instancją OScam

To jest zaskakująco powszechne. Ktoś instaluje OScam obok działającej konfiguracji CCcam, nie wyłączając wbudowanego DVBAPI CCcam. Oba próbują otworzyć/dev/dvb/adapter0/ca0 jednocześnie. Wynik jest nieprzewidywalny — czasami jeden wygrywa, czasami walczą, zawsze powodując niestabilność.

Potrzebujesz dokładnie jednego aktywnego klienta DVBAPI. Jeśli używasz OScam, wyłącz DVBAPI w CCcam, usuwając lub komentującDVBAPI : 1 linię (lub równoważną) wCCcam.cfg. Jeśli używasz natywnego DVBAPI CCcam, upewnij się, że OScam nie jest skonfigurowany jako klient dvbapi.

Buforowanie po stronie odbiornika maskujące prawdziwy problem

Niektóre obrazy Enigma2 — szczególnie starsze wersje OpenPLi — krótko buforują ostatnio używane CW. Może to sprawić, że dekodowanie wydaje się działać, gdy w rzeczywistości serwuje przestarzałe klucze przez sekundę lub dwie przed niepowodzeniem. Objaw: brak zawieszenia podczas pierwszego oglądania, ale szybkie przeskakiwanie powoduje krótkie czarne ekrany, które same się rozwiązują.

Wyłącz buforowanie CW, jeśli twój obraz udostępnia tę opcję, lub zaktualizuj do aktualnej wersji obrazu, w której jest to lepiej obsługiwane. OpenATV 7.x i OpenPLi 9.x są tutaj znacznie bardziej niezawodne niż cokolwiek z 2022 roku lub wcześniejszego.

Kiedy opóźniacz nie pomoże (i co pomoże)

To jest sekcja, którą większość przewodników pomija, a ma znaczenie.Konfiguracja opóźniacza CCcam dvbapinaprawia dokładnie jedną rzecz: wyścig czasowy między dostarczeniem CW a gotowością demuxera. Nie naprawia problemów z siecią, złych linii ani ograniczeń sprzętowych.

Zawieszanie spowodowane opóźnieniem sieciowym, a nie czasem

Jeśli czasy okrążenia ECM w logu OScam skaczą losowo między 80 ms a 1200 ms, to oznacza niestabilność sieci. Może peer udostępniający jest przeciążony. Może twoje połączenie internetowe ma utratę pakietów. Opóźniacz nie ma tu nic do zaoferowania — nie możesz ustawić go wystarczająco wysoko, aby pokryć 1,2-sekundowy skok, nie sprawiając, że zapping wydaje się zepsuty.

Diagnozuj problemy z siecią za pomocąping -i 0.2 [server-ip]uruchomionego podczas oglądania telewizji. Jeśli widzisz nietypowe pingi zbieżne z wydarzeniami zawieszenia, ustawienie opóźnienia jest nieistotne. Napraw sieć lub znajdź bardziej stabilne źródło udostępniania.

Problemy z okresem kryptograficznym / zmianą klucza vs problemy z opóźnieniem

Zawieszenia związane z czasem mają określony wzór: występują w przewidywalnych odstępach odpowiadających okresowi kryptograficznemu. Jeśli zauważysz zawieszenie o 10:01:10, a następnie o 10:01:20 i kolejne o 10:01:30, to oznacza 10-sekundowy okres kryptograficzny i problem z opóźnieniem. Napraw to za pomocą opóźniacza.

Jeśli zawieszenia występują o 10:01:12, 10:04:47, 10:09:03 — brak wzoru — to nie jest problem z czasem zmiany klucza. Nie dostosowuj opóźniacza, zbadaj coś innego.

Ograniczenia demuxera sprzętowego w starszych odbiornikach

Niektóre starsze odbiorniki — Dreambox 500s, jednostki AZBox pierwszej generacji, niektóre chińskie pudełka bez nazwy — mają sprzętowe demuxery, które po prostu nie mogą akceptować CW dostarczanych przez oprogramowanie wystarczająco szybko, niezależnie od tego, jak ustawione jest opóźnienie. Okno jest zbyt wąskie lub sprzęt ma cechy, których żadne opóźnienie programowe nie może skompensować.

Na tych pudełkach, zawieszenie często trwa kilka klatek, a nie twardy czarny ekran, i występuje przy każdej zmianie klucza, niezależnie od tego, co ustawisz. Jeśli to twoja sytuacja, sprzęt jest wąskim gardłem. Nowoczesny odbiornik Vu+, Gigablue lub AX poradzi sobie z tym samym ustawieniem bez problemów.

Migracja z CCcam DVBAPI do OScam dla stabilności

Jeśli używasz natywnego DVBAPI CCcam i napotykasz ograniczenia w opcjach konfiguracji, migracja do OScam jako obsługi DVBAPI, zachowując CCcam jako protokół udostępniania, to właściwy krok. Mostek jest prosty na wysokim poziomie: OScam łączy się z CCcam jako czytnik za pośrednictwem protokołu newcamd lub CCcam na porcie 10000 (lub jakimkolwiek porcie, którego używa twój serwer CCcam), a następnie samodzielnie obsługuje wszystkie lokalne dekodowanie DVBAPI.

Woscam.servertwój czytnik CCcam wygląda tak:

[reader]

OScam następnie obsługuje stronę DVBAPI z pełną kontrolą opóźnienia, celowaniem per-CAID i interfejsem webowym do monitorowania wszystkiego. Problemy z zawieszaniem, które wynikają z podstawowej implementacji DVBAPI CCcam, zazwyczaj znikają natychmiast po dokonaniu tej zmiany.