Alternatywy dla CCcam: OScam, mgcamdi inne porównane

Jeśli to czytasz, twój serwer CCcam prawdopodobnie zawiesza się podczas zmiany kanałów, ma opóźnienia w ECM podczas godzin szczytu, lub po prostu masz dość opiekowania się zamkniętym źródłem, które nie miało prawdziwej aktualizacji od lat. Nie mylisz się, szukając gdzie indziej. Ten artykuł przechodzi przez rzeczywiste alternatywy dla konfiguracji cccam, które istnieją w tej chwili — OScam, mgcamd, NCam — co każda z nich robi inaczej w tle i jak przenieść swoją istniejącą konfigurację bez łamania wszystkiego w pierwszym dniu.

Przez lata uruchamiałem wszystkie trzy na boxach Enigma2 i kilku bezgłowych serwerach Linux. Żaden z nich nie jest doskonały, ale różnice mają duże znaczenie w zależności od tego, czy uruchamiasz czytnik, klienta, czy oba. Przejdźmy do rzeczy.

Dlaczego warto spojrzeć poza CCcam w pierwszej kolejności

CCcam 2.3.0 — ostatnia wersja, którą większość ludzi faktycznie używa — jest zamkniętym źródłem. Nie ma publicznego repozytorium, nie ma historii commitów do przeglądania, ani społeczności, która naprawia błędy, gdy się pojawiają. Rozwój w zasadzie zatrzymał się lata temu. Jeśli nowa aktualizacja CAS zepsuje coś w obsłudze twojego dostawcy, czekasz. Nie ma innej opcji, ponieważ nikt poza oryginalnym autorem nie ma źródła.

Ta zamknięta natura najbardziej doskwiera przy obsłudze ECM. CCcam przetwarza żądania kart w sposób, który nie skalują się dobrze, gdy peer lub czytnik jest zajęty — zobaczysz zamrożenia zmiany kanałów trwające kilka sekund, czasami dłużej, na serwerach z dużą liczbą równoczesnych klientów. Nie jest wielowątkowy w sposób, w jaki są nowoczesne alternatywy, więc jeden wolny czytnik może zablokować wszystko, co jest poniżej niego.

Nie daje również precyzyjnej kontroli nad lokalnym sprzętem. Jeśli masz czytnik Smargo lub Phoenix podłączony do portu USB i chcesz, aby CCcam rozmawiał z nim bezpośrednio z odpowiednią obsługą protokołu, jesteś w martwym punkcie. CCcam został zbudowany głównie jako klient/server do udostępniania w sieci, a nie jako platforma do zarządzania czytnikami.

Problem zamkniętego źródła i zatrzymanego rozwoju CCcam

Brak publicznego źródła oznacza brak możliwości audytowania tego, co tak naprawdę dzieje się wewnątrz binariów, oraz brak drogi dla społeczności do naprawy rzeczy, gdy operator satelitarny zmienia swoją obsługę CAS. Jesteś całkowicie zależny od binariów, które zostały skompilowane lata temu i nadal działają poprawnie z aktualnymi formatami ECM. Jak dotąd w większości działają — ale "w większości" nie jest świetnym zakładem na dłuższą metę.

Gdzie CCcam wciąż się sprawdza (i dlaczego ludzie go trzymają)

Będę szczery — jeśli wszystko, czego potrzebujesz, to głupi klient, który łączy się z jedną lub dwiema liniami protokołu CCcam i wyprowadza odszyfrowane kanały, CCcam wciąż dobrze wykonuje tę pracę. Konfiguracja to jeden płaski plik, jest lekka pod względem RAM, i nie ma nic do dostrojenia. Dla boxa, który po prostu siedzi tam, odbierając jedną linię i nie dotykając lokalnych czytników, wyrwanie go nie zawsze jest warte zachodu.

Sygnalizuje, że czas na migrację: zawieszenia, czas oczekiwania ECM, brak elastyczności lokalnego czytnika

Zwróć uwagę na te trzy rzeczy szczególnie. Po pierwsze, powtarzające się zawieszenia trwające 3-5 sekund lub dłużej podczas zmiany kanałów w godzinach szczytu wieczornego — to kolejka ECM się zatyka. Po drugie, czasy oczekiwania w twoim dzienniku, które ciągle trafiają do tego samego peera, mimo że twoje połączenie jest stabilne. Po trzecie, jeśli kupiłeś lokalny czytnik, a CCcam po prostu nie może go obsłużyć tak, jak potrzebujesz — to twój znak, aby spojrzeć na alternatywę dla konfiguracji cccam, zamiast walczyć z oprogramowaniem, które już masz.

Główne alternatywy dla CCcam porównane

Są naprawdę trzy softcamy, które warto rozważyć jako alternatywę dla konfiguracji cccam w 2026 roku: OScam, mgcamd i NCam. Każdy zajmuje inną niszę, a wybór niewłaściwego dla twojego przypadku użycia tylko tworzy nowe bóle głowy.

OScam — otwartoźródłowy koń roboczy (czytniki, protokoły, webif)

OScam to ten, na którym kończy większość ludzi. Jest otwartoźródłowy, aktywnie utrzymywany i wielowątkowy — co oznacza, że wolny czytnik lub peer nie zatrzymuje wszystkiego innego. Obsługuje newcamd (zwykle przypisany do każdego czytnika zaczynając od portu 15000, chociaż ustawiasz to sam), natywny protokół klienta/servera cccam, camd35, protokoły radegast i gbox, wszystko z tego samego binarium. Może obsługiwać lokalne czytniki Smargo i Phoenix przez port szeregowy/USB (zwykle enumerowane jako /dev/ttyUSB0), a także dostarczane jest z odpowiednim interfejsem webowym do monitorowania na żywo. Jeśli chcesz jednego softcama, który robi wszystko, co robi CCcam, plus zarządzanie lokalnymi czytnikami i wsparcie dla wielu protokołów, to jest to.

OScam-Emu / fork NCam — gdy potrzebujesz emulacji lub dodatkowego CAS

NCam to fork OScam, który wprowadza dodatkowe wsparcie CAS i funkcje emulacji (stałe CW / obsługa SoftCam.Key) szybciej niż główny OScam czasami to robi. Istnieją gałęzie OScam-Emu z podobnych powodów. Jeśli twój dostawca lub konfiguracja potrzebuje wsparcia emulacji, którego standardowy OScam jeszcze nie zintegrował, jeden z tych forków warto wypróbować — format konfiguracji jest niemal identyczny z OScam, więc migracja między nimi jest trywialna.

mgcamd — lekki klient newcamd

mgcamd jest mały, szybki w konfiguracji i jest czysto klientem — nie ma roli serwera i nie może obsługiwać lokalnych czytników kart. Konfiguracja znajduje się w dwóch plikach: newcamd.list dla twoich wpisów linii i mg_cfg dla ustawień globalnych. Jeśli masz box o niskiej specyfikacji, lub po prostu chcesz cienkiego klienta pobierającego jedną lub dwie linie newcamd z minimalnym zużyciem RAM, mgcamd naprawdę dobrze radzi sobie z tą jedną pracą. Nie oczekuj, że zastąpi OScam w czymkolwiek poza tym.

gbox i opcje legacy — głównie historyczne

gbox wciąż istnieje, a niektórzy starzy dzielnicy przysięgają na jego model peer-to-peer, ale w tym momencie to niszowy wybór — głównie utrzymywany przy życiu przez ludzi, którzy zbudowali swoją sieć wokół niego dekadę temu. OScam natywnie obsługuje protokół gbox, jeśli potrzebujesz połączyć się z istniejącą siecią gbox bez uruchamiania samego gboxa.

Macierz funkcji: wsparcie protokołów, wsparcie lokalnych czytników, obsługa obciążenia, aktywny rozwój

Migracja z CCcam.cfg do OScam

To jest część, którą większość artykułów porównawczych całkowicie pomija, a to jest część, która naprawdę ma znaczenie, jeśli przechodzisz. Twój istniejący CCcam.cfg ma linie takie jak ta dla każdego peera, z którym się łączysz:

C: 123.45.67.89 12000 myuser mypass

To odpowiada blokowi OScam[reader] w oscam.server:

Polecccversion ma większe znaczenie, niż ludzie myślą. Niektórzy peerzy poprawnie nawiązują handshake tylko w wersji 2.0.11, inni oczekują 2.1.1 lub 2.3.0 — jeśli się pomylisz, zobaczysz połączenie, które się nawiązuje, a następnie natychmiast zrywa. Jeśli peer, którego migrowałeś, zawodzi w ciszy, to pierwsza rzecz do sprawdzenia.

Mapowanie linii C CCcam do bloku [reader] OScam

Każda linia C w twojej starej konfiguracji staje się jednym stanzą czytnika. Nadaj każdemu wyraźnylabel i przypisz go dogroup numeru — grupy to sposób, w jaki kontrolujesz, którzy klienci mają dostęp do których czytników później w oscam.user. Jeśli miałeś dziesięć linii C, będziesz miał dziesięć bloków czytników, co brzmi nudno, ale to pięciominutowa praca znajdź-i-zamień, gdy zobaczysz wzór.

Podstawowe pliki konfiguracyjne: oscam.conf, oscam.server, oscam.user, oscam.services

OScam dzieli konfigurację na kilka plików zamiast jednego płaskiego pliku jak CCcam.cfg. oscam.conf zawiera globalne ustawienia w sekcjach takich jak[global],[cs357x],[cccam], i[webif]. oscam.server zawiera definicje twoich czytników (to, co robiły linie C w CCcam.cfg). oscam.user definiuje klientów, którzy mogą łączyć się z twoim dekoderem, ich ustawienia AU (automatyczna aktualizacja) oraz które grupy czytników mogą osiągnąć. oscam.services służy do filtrowania SID, do czego przejdziemy poniżej. W większości obrazów Enigma2 znajdują się one w /etc/tuxbox/config/oscam/, chociaż niektóre obrazy używają /var/keys/ lub /usr/keys/ — sprawdź za pomocąfind / -name "oscam.server" 2>/dev/null jeśli nie jesteś pewien, który obraz używasz.

Włączenie interfejsu webowego (httpport = 8888) do monitorowania na żywo

Pod[webif] w oscam.conf, ustawhttpport = 8888 oraz nazwę użytkownika/hasło. Zrestartuj OScam i wskaż przeglądarkę na IP twojego dekodera na porcie 8888. Ta pojedyncza funkcja jest warta przełączenia się na nią — otrzymujesz status czytnika na żywo, czas ECM dla każdego klienta oraz logi połączeń bez konieczności przeglądania plików tekstowych przez SSH.

Konfiguracja wymiany pamięci podręcznej (CSP) i opcji antyzamrożeniowych

Wymiana pamięci podręcznej (cacheex) pozwala serwerom OScam dzielić się już zdekodowanymi słowami kontrolnymi, co znacznie zmniejsza obciążenie ECM, gdy uruchamiasz wiele dekoderów. Tryb 1 wysyła tylko, tryb 2 odbiera tylko, a tryb 3 robi obie rzeczy. Uważaj na tryb 3 między więcej niż dwoma serwerami — jeśli nie ustawisz limitów skoków cacheex poprawnie, możesz skończyć z burzami CW odbijającymi te same wpisy pamięci podręcznej w pętlach między serwerami, co w rzeczywistości zwiększa obciążenie zamiast je zmniejszać. Zacznij od trybu 1/2 między dwoma dekoderami, zanim spróbujesz pełnej siatki trybu 3.

Utrzymywanie CCcam i OScam obok siebie podczas przejścia

Nie musisz przełączać się w ciemno. Uruchom OScam na innym porcie (powiedzmy newcamd na 15001 zamiast zwykłego 12000 CCcam), podczas gdy CCcam nadal działa na swoim oryginalnym porcie. W Enigma2 ustawiasz, który softcam jest "aktywny" do dekodowania w menedżerze softcam obrazu, ale oba pliki binarne mogą być zainstalowane i skonfigurowane jednocześnie. Przetestuj swoją konfigurację OScam na rzeczywistych kanałach przez kilka dni, zanim przełączysz i całkowicie wyłączysz CCcam. To najbezpieczniejszy sposób na zweryfikowanie alternatywnej konfiguracji cccam bez ryzyka przestoju na dekoderze, na którym naprawdę polegasz.

Testowanie i rozwiązywanie problemów z nową konfiguracją

Gdy OScam działa, strona statusu webif to miejsce, w którym spędzisz większość czasu na rozwiązywaniu problemów. Każde połączenie klienta pokazuje czas ECM w milisekundach — poniżej 400 ms jest zdrowe i nie powinieneś zauważyć żadnego opóźnienia przy przełączaniu kanałów. Gdy konsekwentnie widzisz 800 ms lub więcej, coś jest nie tak w górę, albo przeciążony peer, albo czytnik, który ma problemy.

Odczytywanie strony statusu OScam webif (czas ECM, CW, kody rc)

Kolumna rc (kod zwrotny) informuje, co tak naprawdę się wydarzyło z każdym żądaniem. rc=0 oznacza, że znaleziono i dostarczono bez problemów. Wszystko inne wymaga uwagi, a dwa kody, które najczęściej zobaczysz podczas rozwiązywania problemów z nową migracją, są omówione poniżej.

Typowe kody błędów: odrzucone (rc=E2), brak karty, limit czasu ECM

rc=E2 oznacza odrzucenie — czytnik lub peer wyraźnie odmówił żądania, zazwyczaj dlatego, że klient nie ma prawa do tego SID lub linia nie obsługuje tego kanału. "Brak karty" oznacza, że sam czytnik nie odpowiada, co na lokalnym sprzęcie zazwyczaj oznacza złe połączenie USB lub źle umieszczoną kartę. Limit czasu ECM oznacza, że żądanie zostało wysłane, a nic nie wróciło na czas — sprawdź, czy peer jest przeciążony lub czy niezgodność wersji ccc powoduje ciche zrzuty.

Weryfikacja uprawnień czytnika i filtrowanie SID/usług

oscam.services pozwala dokładnie określić, które identyfikatory usług (SID) dany czytnik lub klient może uzyskać dostęp. To ma znaczenie, jeśli dzielisz się czytnikiem z innymi — bez filtrowania, peerzy mogą badać kanały, których twoja linia faktycznie nie zapewnia, co generuje niepotrzebne odrzucone żądania i zaśmieca twoje logi. Ustaw wyraźne listy SID dla każdej grupy, zamiast zostawiać wszystko otwarte.

Dostosowanie poziomu logowania i lokalizacja pliku oscam.log

Domyślnie OScam loguje do oscam.log w tym samym katalogu konfiguracyjnym (/etc/tuxbox/config/oscam/oscam.log w większości obrazów Enigma2). Jeśli debugujesz konkretny problem z połączeniem, zwiększloglevel = 4 albo w oscam.conf, albo na żywo przez webif, powtórz problem, a następnie ustaw z powrotem na 1 lub 2. Pozostawienie włączonego szczegółowego logowania na stałe zje pamięć flash na dekoderach z ograniczoną przestrzenią — widziałem, jak to zapełnia 512 MB wewnętrznej pamięci flash w ciągu kilku tygodni na ruchliwym serwerze wieloklientowym.

Wybór dostawcy linii dla alternatywnego softcamu (kryteria ogólne)

Cokolwiek wybierzesz, jakość twojej konfiguracji jest tak dobra, jak linie, które ją zasilają. Ta część ma znaczenie niezależnie od tego, czy korzystasz z CCcam, OScam, czy czegokolwiek innego — i warto to jasno powiedzieć: dotyczy to tylko dzielenia się własnymi legalnie posiadanymi kartami subskrypcyjnymi w sieci prywatnej/lokalnej. Jesteś odpowiedzialny za upewnienie się, że posiadasz ważną subskrypcję na wszystko, co dekodujesz, oraz za przestrzeganie warunków swojego dostawcy i lokalnego prawa.

Kompatybilność protokołów (czy linia działa czysto w cccam/newcamd?)

Potwierdź wersję protokołu, zanim przypiszesz konfigurację czytnika. Źródło działające na starej wersji handshake cccam nie zadziała z czytnikiem skonfigurowanym dla nowszej wersji, i odwrotnie — to ten sam problem z wersją ccc, o którym mówiono wcześniej, tylko z drugiej strony.

Czas odpowiedzi ECM i oczekiwania dotyczące czasu pracy serwera

Obserwuj czasy ECM w swoim webif przez kilka dni, zanim zdecydujesz, że źródło jest niezawodne. Konsekwentne czasy odpowiedzi poniżej 400 ms z okazjonalnymi krótkimi szczytami w godzinach szczytu są normalne. Stałe limity czasu lub odrzucenia rc=E2 są oznaką, że źródło jest zbyt obciążone lub źle skonfigurowane po ich stronie, a nie po twojej.

Lokalna karta vs współdzielona linia: kompromisy w zakresie opóźnienia i niezawodności

Lokalna karta w twoim własnym czytniku zawsze będzie lepsza od współdzielonej linii sieciowej pod względem opóźnienia i niezawodności, po prostu dlatego, że nie ma skoku sieciowego ani rywalizacji z innymi klientami. Współdzielone linie są wygodne, ale jesteś zdany na łaskę tylu innych osób, które jednocześnie korzystają z tego samego źródła.

Czerwone flagi przy ocenie jakiegoś źródła

Bądź ostrożny wobec wszystkiego, co obiecuje nieograniczone jednoczesne połączenia na jednej karcie — tak technicznie nie działa udostępnianie kart, a zazwyczaj oznacza to nadmiernie sprzedany dostęp, który zamarznie w godzinach szczytu. Niejasne odpowiedzi na temat tego, jaki protokół lub CAS linia faktycznie obsługuje, to kolejny znak ostrzegawczy. Przetestuj, zanim poświęcisz czas na rzeczywiste konfiguracje.