Rozwiązywanie problemów z CCcam& Najlepsze alternatywy (Przewodnik po OScam)

Jeśli właśnie szukasz alternatywy do rozwiązywania problemów z cccam, to prawdopodobnie Twój serwer zawiesił się w połowie meczu albo klient rzuca błędami ECM timeout i masz dość zgadywania. Uruchamiałem zarówno CCcam, jak i OScam na wszystkim, od starych jednordzeniowych boxów po nowoczesne odbiorniki Enigma2, i większość paniki typu „CCcam nie działa” okazuje się być martwym peerem, złą liczbą przeskoków (hop count) albo filtrem, o którym nikt nie pamięta, że go ustawił. Ten przewodnik przeprowadzi Cię przez rzeczywistą diagnozę problemu, naprawę tego, co da się naprawić, oraz — jeśli zdecydujesz, że CCcam osiągnął swój sufit możliwości — migrację do OScam bez niszczenia istniejącej konfiguracji.

Diagnozuj, zanim wymienisz: Czy CCcam naprawdę jest problemem?

Zanim zaczniesz szukać alternatywy do rozwiązywania problemów z cccam, spędź dziesięć minut z logami. Większość ludzi od razu przechodzi do „przejdźmy na OScam” w momencie, gdy kanał się zawiesi, a w połowie przypadków to przesada w stosunku do tego, co w rzeczywistości jest jednolinijkową poprawką konfiguracji.

Uruchom CCcam w trybie debugowania. Na większości buildów linuksowych toCCcam -d, a na obrazach Enigma2 zazwyczaj przekierujesz stdout do pliku, ponieważ softcam działa jako demon:CCcam -d > /var/log/cccam.log 2>&1. Obserwuj na żywo za pomocątail -f /var/log/cccam.log podczas gdy przełączasz się na kanał, który sprawia Ci problemy. Chcesz zobaczyć wychodzące żądania ECM i przychodzące CW (control words) — jeśli widzisz żądanie za żądaniem bez CW, to jest Twój dowód winy, a nie jakieś niejasne „CCcam jest zepsuty”.

Czytanie logów CCcam i flaga debugowania -d

Dane wyjściowe debugowania mówią dokładnie, która linia obsługuje żądanie — lokalny czytnik lub konkretna linia C: według nazwy hosta/etykiety. Jeśli masz box z ograniczoną pamięcią, nie zostawiaj -d włączonego na stałe; jest hałaśliwe i zapełni partycję logów na starym odbiorniku szybciej, niż myślisz. Zbierz 5-10 minut złej sesji, a następnie wyłącz je z powrotem.

Odróżnianie lokalnych usterek karty od usterek peera/sieci

To jest rozwidlenie na drodze. Jeśli Twój lokalny czytnik (powiedzmy interfejs typu SmartReader lub Phoenix na/dev/ttyUSB0) obsługuje kanał, który zawodzi, usterka jest lokalna — zła karta, złe parametry czytnika, brudne styki, zły protokół w konfiguracji czytnika. Jeśli odpowiada (lub nie odpowiada) zdalny peer przez linię C:, usterka jest po jego stronie lub na ścieżce sieciowej do niego. Nie przebudowuj całej swojej instalacji z powodu peera, który stracił swój udział.

Czas ECM (w ms) jako Twój podstawowy wskaźnik zdrowia

To liczba, której prawie nikt Cię nie uczy obserwować, a jest to najlepszy pojedynczy wskaźnik diagnostyczny, jaki masz. CCcam loguje czas odpowiedzi ECM dla każdego żądania. Wszystko konsekwentnie poniżej 200-300ms jest zdrowe. Gdy regularnie widzisz 600-800ms lub więcej, zobaczysz widoczne zawieszanie się i ponowne buforowanie na żywej telewizji, mimo że klient technicznie „dekoduje”. Powyżej mniej więcej 1000ms w zasadzie oglądasz pokaz slajdów. Loguj czas ECM dla kilku kanałów przez 20-30 minut, zanim wyciągniesz jakiekolwiek wnioski — pojedynczy skok niczego nie oznacza, utrzymujący się wzrost oznacza coś.

Sprawdzanie niezgodności między CCcam.cfg a CCcam.channelinfo

Lokalizacja pliku konfiguracyjnego różni się w zależności od obrazu — znajdziesz go pod/etc/CCcam.cfg na niektórych buildach oraz/var/etc/CCcam.cfgna innych (OpenATV, OpenPLi i podobne forki Enigma2 zwykle używają /etc, niektóre starsze obrazy Dreambox używają /var/etc). Edytujesz niewłaściwą kopię i twoje zmiany po prostu nic nie robią przy następnym restarcie — sprawdź, którą ścieżkę faktycznie odczytuje twój softcam za pomocąps aux | grep -i cccamaby zobaczyć parametry uruchomieniowe, lub sprawdź skrypt init w/etc/init.d/. Sprawdź teżCCcam.channelinfojeśli istnieje na twoim obrazie — buforuje mapowania SID-na-CAID, a kanał, który zmienił SID po aktualizacji dostawcy, będzie pokazywał "brak karty" dopóki ten cache się nie odświeży lub nie zostanie wyczyszczony.

Najczęstsze awarie CCcam i ich rzeczywiste rozwiązania

Oto zestawienie tego, co naprawdę psuje się w praktyce, uszeregowane w przybliżeniu według częstotliwości występowania.

Częste zawieszanie się i timeouty ECM

Przyczyna: czas ECM powyżej 600-800ms, zwykle wynikający z przeciążonej karty (zbyt wielu klientów obciążających jedną fizyczną kartę lub udział peera) lub zbyt wielu przeskoków między tobą a rzeczywistą lokalną kartą. Rozwiązanie: sprawdź liczbę przeskoków w podglądzie statusu CCcam — cokolwiek na poziomie hop 3+ dla kanału oglądanego codziennie z natury będzie niestabilne, ponieważ każdy przeskok dodaje opóźnienie i kolejny potencjalny punkt awarii. Zapytaj źródło swojego udziału, czy może zaoferować ten CAID/provid bliżej źródła, albo znajdź alternatywę hop 1-2 specjalnie dla tego pakietu.

Klient pokazuje połączenie, ale brak dekodowania (0 kart)

To ciągle wprowadza ludzi w błąd. "Połączony" w CCcam oznacza jedynie, że powiodło się uzgadnianie TCP i logowanie — nie mówi nic o tym, czy peer faktycznie udostępnia karty dla potrzebnego ci CAID. Jeśli liczba kart pokazuje 0, peer prawdopodobnie usunął ten udział, zmienił filtry swojej linii F:, albo jesteś filtrowany po CAID/provid po jego stronie. Sprawdź swoją linię C: względem jego dokumentacji i potwierdź, że kombinacja nazwy użytkownika/hasła jest aktualna — wygasłe lub zmienione dane uwierzytelniające często nadal będą się "łączyć" przed niepowodzeniem autoryzacji jakichkolwiek kart.

Zablokowane porty: 12000/16000 oraz problemy z zaporą sieciową/NAT

Domyślny port serwera CCcam to12000(TCP). Jeśli prowadzisz serwer CCcam, do którego łączą się inni ludzie, ten port musi być przekierowany do wewnątrz przez twój router/NAT do urządzenia, na którym działa CCcam. Jeśli jesteś wyłącznie klientem łączącym się z serwerem kogoś innego, potrzebujesz tylko dostępu wychodzącego — przekierowanie portów po twojej stronie nie jest potrzebne, dlatego wiele zgłoszeń "dlaczego nie mogę się połączyć" okazuje się być zaporą sieciową peera, a nie twoją. Port 16000 pojawia się w niektórych starszych poradnikach jako alternatywny port/port webif w zależności od buildu; sprawdź w swoim konkretnym CCcam.cfg faktyczny powiązany port, zamiast zakładać.

zbyt wysoka liczba przeskoków i martwe linie C:

Każda linia C: w twojej konfiguracji jest potencjalnym martwym balastem, jeśli peer przejdzie offline, a ty nigdy jej nie usuniesz. Martwa linia C: nie zawodzi po prostu bezgłośnie — w zależności od twojej wersji CCcam może dodawać opóźnienie połączenia, próbując uzgadniania aż do przekroczenia limitu czasu, zanim przejdzie do następnej linii. Regularnie usuwaj linie, które nie wykazywały aktywności w monitorze statusu od tygodni.

Niepowodzenia uzgadniania i niezgodności wersji/kluczy DES

Klasyczny błąd "niezgodna wersja protokołu" pojawia się, gdy miesza się klientów CCcam 2.1.4 z serwerem 2.3.x (lub odwrotnie) — wymiana kluczy DES i format uzgadniania zmieniły się między głównymi wersjami, a starsze klienty po prostu nie uwierzytelnią się wobec nowszych serwerów, czasem bez żadnego użytecznego błędu poza zerwanym połączeniem. Jeśli konkretny peer działa u wszystkich innych, ale nie u ciebie, zapytaj, jakiego builda CCcam używa i porównaj ze swoim, zanim założysz, że to wina twojej sieci.

Format linii C: to:C: hostname port username password. Jeśli oferujesz udział na zewnątrz, format linii F: jest używany do zdefiniowania tego, co przekazujesz dalej — linie F: kontrolują, które kombinacje CAID/provid są oferowane którym połączeniom podrzędnym, a błędnie skonfigurowana linia F: jest dokładnie powodem, dla którego peer może połączyć się bez problemu, ale widzieć zero kart dla oczekiwanego pakietu.

Kiedy naprawianie się nie opłaca: oznaki, że powinieneś zmienić rozwiązanie

Słuchaj, CCcam działa i jeśli twoja konfiguracja jest stabilna, nie ma powodu, żeby jej dotykać. Ale ma realne ograniczenia i udawanie inaczej marnuje twój czas na pogoń za naprawami, które nie istnieją.

CCcam jest zamkniętoźródłowy i nie widział znaczącego aktywnego rozwoju od lat, jak na ten moment. To nie jest zarzut wobec nikogo — to po prostu rzeczywistość tego, co uruchamiasz. Brak kodu źródłowego oznacza brak łatek społeczności, brak rozszerzeń protokołu, a ty utknąłeś z tym, co obsługuje ostatni skompilowany plik binarny dla twojej architektury. Na nowoczesnych obrazach Enigma2 czasami znajdziesz utrzymywany plik binarny CCcam pozostający w tyle za aktualizacjami jądra lub bibliotek na samym odbiorniku, powodując dziwne awarie, które nie mają nic wspólnego z twoją konfiguracją card sharingu.

Obciążenie CPU przez emulację na starszych odbiornikach

Jeśli uruchamiasz emulację programową na wierzchu card sharingu na starszym jednordzeniowym urządzeniu, rywalizacja o CPU może wyglądać dokładnie jak problem z card sharingiem — zacinanie się, zawieszanie, gubione EMM — podczas gdy w rzeczywistości twój CPU jest maksymalnie obciążony. Sprawdźtoppodczas zawieszenia (freeze), zanim obwinisz protokół.

Brak źródła dla protokołów w stylu OScam (cccam vs newcamd vs cs378x)

CCcam mówi swoim własnym protokołem, kropka. OScam obsługuje między innymi cccam, newcamd, cs378x i radegast, wszystko z jednego pliku binarnego, co oznacza, że gdy jeden protokół ma zły dzień z powodu trasowania u twojego ISP, masz inne, na które możesz się przełączyć. Taka elastyczność po prostu nie istnieje w CCcam.

Nieutrzymywany plik binarny CCcam w nowoczesnych obrazach Enigma2

Nowsze wersje obrazów czasami dołączają plik binarny CCcam jako opcję kompatybilności wstecznej, a nie jako element pierwszej kategorii, co oznacza mniej testów pod kątem aktualnych jąder i wersji bibliotek. Jeśli w dzienniku zmian twojego obrazu CCcam nie był wspominany od roku wydań, to o czymś świadczy.

Górna granica niezawodności protokołu cccam przy utracie pakietów

Przy naprawdę niestabilnym połączeniu — mobilny hotspot, przeciążone DSL, cokolwiek — protokół cccam nie radzi sobie z retransmisją i odzyskiwaniem tak sprawnie, jak z mojego doświadczenia zwykle radzą sobie newcamd czy cs378x. Jeśli twoje łącze jest niestabilne i potwierdziłeś, że nie da się tego naprawić po twojej stronie, to uzasadniony powód, by rozważyć alternatywę do rozwiązywania problemów z cccam, zamiast wciąż dostrajać protokół, który walczy z twoją siecią.

Nic z tego nie oznacza, że należy całkowicie porzucić CCcam. Możesz uruchomić go równolegle z OScam podczas przejścia, a dokładnie to omawia następna sekcja.

Migracja z CCcam do OScam bez psucia konfiguracji

To część, którą większość poradników pomija lub traktuje zdawkowo. Jeśli przechodzisz na OScam, ponieważ osiągnąłeś granice CCcam, oto rzeczywista konwersja plik po pliku.

Mapowanie linii CCcam.cfg na wpisy oscam.server

OScam dzieli konfigurację na trzy pliki zamiast jednego pliku .cfg jak w CCcam. W zależności od obrazu, znajdziesz je w/etc/tuxbox/config/oscam/lub/var/etc/oscam/— sprawdź oba, a jeśli nie jesteś pewien, która ścieżka jest faktycznie wczytywana podczas rozruchu, sprawdź swój skrypt init.

Role plików oscam.conf, oscam.server, oscam.user

• oscam.conf— ustawienia globalne, w tym interfejs webowy: ustawhttpport=8888w sekcji [webif], aby go włączyć.
• oscam.server— tutaj znajdują się wszystkie połączenia typu reader i peer, jeden blok [reader] na linię/kartę/peera.
• oscam.user— twoi lokalni klienci (dekodery/aplikacje, które łączą się z tą instancją OScam), każdy z wartością group=.

Konwersja linii CCcam C: na [reader] w OScam z protocol=cccam

Weź linię CCcam taką jak ta:

C: share.example-host.net 12000 myusername mypassword

Odpowiednik w OScam w pliku oscam.server wygląda tak:

[reader]








To cała konwersja — nazwa hosta i port stają się polem device=, oddzielonym przecinkiem, a nazwa użytkownika i hasło są mapowane bezpośrednio. Elementem, który sprawia ludziom najwięcej kłopotów, jestgroup=. Ta wartość musi pokrywać się z grupą, do której przypisany jest twój lokalny klient w oscam.user, w przeciwnym razie czytnik połączy się poprawnie, ale nie odkoduje ani jednego kanału — to dokładnie ten sam objaw „połączono, ale brak kart" znany z CCcam, tylko w innej konfiguracji. Z mojego doświadczenia niezgodność grup jest najczęstszym powodem, dla którego świeża instalacja OScam „nie działa", mimo że wszystkie pozostałe ustawienia są poprawne.

W oscam.user pasujący wpis konta wygląda tak:

[account]





Uruchamianie OScam i CCcam równolegle podczas przejścia

Nie musisz przełączać się od razu. Przypisz port serwera cccam w OScam (ustawiany w bloku [cccam] w oscam.server za pomocą własnej linii port=) do wartości innej niż 12000, jeśli CCcam nadal zajmuje ten port na tym samym urządzeniu, albo uruchom je na całkowicie oddzielnych portach i skieruj klienta testowego do OScam, podczas gdy twój główny odbiornik pozostaje na CCcam. Upewnij się tylko, że oba nie próbują jednocześnie przejąć tego samego urządzenia czytnika kart — dwa softcamy walczące o/dev/ttyUSB0 lub/dev/sci0 spowodują błędy odczytu w obu, i to klasyczna pułapka, gdy ktoś instaluje OScam „tylko żeby przetestować", nie zatrzymując wcześniej wątku czytnika CCcam.

Korzystanie z interfejsu webowego OScam (domyślny port 8888) w celu weryfikacji

Gdy w oscam.conf ustawisz httpport=8888, wejdź nahttp://your-receiver-ip:8888 w przeglądarce. To tutaj OScam wyprzedza CCcam pod względem diagnostyki — otrzymujesz status czytnika na żywo (OK/CONNECTED kontra CONNECTING kontra stany błędu), liczniki ECM/EMM dla poszczególnych klientów oraz wykresy czasu odpowiedzi, bez konieczności śledzenia surowego pliku logu. Jeśli czytnik utknie w stanie „connecting" i nigdy nie przełączy się na CONNECTED, oznacza to, że nawiązywanie połączenia zawodzi — najpierw sprawdź dane logowania i wersję protokołu.

Krótka uwaga dotycząca cofnięcia zmian: zachowaj kopię zapasową oryginalnego CCcam.cfg, zanim czegokolwiek dotkniesz. Jeśli OScam zachowuje się nieprawidłowo na twoim sprzęcie — niektóre starsze jednordzeniowe urządzenia mają wyższe obciążenie CPU z powodu przetwarzania EMM przez OScam, które można ograniczyć za pomocądisablecrccws_only_for= lub wyłączając przetwarzanie EMM dla poszczególnych czytników, jeśli nie potrzebujesz aktualizacji przesyłanych w ten sposób — możesz zatrzymać OScam i uruchomić ponownie CCcam z nietkniętej konfiguracji w mniej niż minutę.

Wybór niezawodnego źródła card-sharing (kryteria ogólne)

Niezależnie od tego, czy zostajesz przy CCcam, czy przechodzisz na OScam, oprogramowanie nie jest jedyną zmienną — jakość udziału (share) lub karty, z którą się łączysz, ma równie duże znaczenie, a może nawet większe. Nie będę tu wymieniać nazw, ale oto na co naprawdę warto zwrócić uwagę.

Jak w praktyce wygląda dobry uptime i niski czas ECM

Wiarygodne źródło utrzymuje czasy ECM na poziomie poniżej mniej więcej 400ms w sposób ciągły, nie tylko o 3 nad ranem, gdy nikt inny nie jest podłączony. Poproś o wgląd (lub sam zmierz) czasy odpowiedzi w godzinach szczytu — wieczorami, w weekendy, podczas dużych wydarzeń sportowych — bo właśnie wtedy przeciążone karty zaczynają zawodzić.

Karta lokalna a share z peeringu: wiedz, z czym się łączysz

Źródło działające na hop 1 (prawdziwa lokalna karta) jest zasadniczo bardziej niezawodne niż takie na hop 4 lub 5, które samo korzysta z peeringu u kogoś innego, trzy razy dalej w łańcuchu. Zapytaj wprost, na jakim hop count będziesz dla pakietów, które faktycznie cię interesują. Źródło, które nie chce jasno odpowiedzieć na to pytanie, już samo w sobie o czymś świadczy.

Sygnały ostrzegawcze: absurdalne liczby hopów, niestabilne IP, uzależnienie od jednego protokołu

Zwracaj uwagę na: hosty/IP, które zmieniają się ciągle bez żadnego wyjaśnienia, obietnice „tysięcy kart” bez żadnych szczegółów co do liczby hopów czy pokrycia CAID, oraz odmowę umożliwienia testów przed zobowiązaniem się. Uważaj też na każdego, kto upiera się przy jednym konkretnym protokole bez żadnej elastyczności — źródło, które obsługuje tylko jeden protokół i nie potrafi wyjaśnić dlaczego, niekoniecznie jest złe, ale to sygnał, który warto odnotować.

Testowanie połączenia, zanim zaczniesz na nim polegać

Podłącz jedną linię, a potem faktycznie ją obserwuj — nie poprzestawaj na jednorazowym potwierdzeniu dekodowania i uznaniu sprawy za zamkniętą. Śledź czas ECM i stabilność dekodowania na konkretnych kanałach, które cię interesują, przez 24-48 godzin, najlepiej obejmując co najmniej jeden wieczorny szczyt. Źródło, które utrzymuje stabilność pod realnym obciążeniem w tym okresie, warto zatrzymać; takie, które traci wydajność po pierwszych kilku godzinach — nie, bez względu na to, jak dobrze wyglądało początkowe połączenie.