Porównanie ustawień Dreambox: Przewodnik OScam vs CCcam

Jeśli masz Dreamboxa lub jeden z klonów enigma2 siedzący pod telewizorem i próbujesz ustalić, czy uruchomić CCcam, OScam, czy jakąś mieszankę obu, nie jesteś sam. Ciągle mnie o to pytają, a szczera odpowiedź brzmi: to zależy od tego, co tak naprawdę próbujesz zrobić. To porównanie ustawień Dreambox przechodzi przez rzeczywiste ścieżki konfiguracji, rzeczywiste różnice protokołów i miejsca, w których ludzie zazwyczaj utknęli — zamarznięte kanały, brakujące CAMy po aktualizacji, czytniki, które się łączą, ale nigdy nic nie dekodują.

Przez lata zainstalowałem wystarczająco wiele tych boxów — oryginalny sprzęt Dreambox, Vu+ Solo, kilka klonów Zgemma — aby wiedzieć, że większość bólu nie pochodzi od samego softcamu. To niedopasowane założenia dotyczące ścieżek, architektur i wersji protokołów. Więc zacznijmy od rzeczywistych warstw, ponieważ to tam większość przewodników pomija krok.

Co naprawdę oznacza 'Ustawienie Dreambox': Obraz, Softcam i Warstwy Protokołów

Wiele osób mówi "moje ustawienie Dreambox" jakby to była jedna rzecz. To nie jest prawda. To stos, a każda warstwa może działać źle niezależnie od innych. Kiedy robisz porównanie ustawień Dreambox między CCcam a OScam, tak naprawdę porównujesz jedną warstwę z trójwarstwowego systemu, a mylenie warstw to sposób, w jaki ludzie kończą na ponownym flashowaniu boxa, który tego nie potrzebował.

Warstwa pierwsza to sam obraz enigma2 — OpenPLi, OpenATV, OpenViX, lub oryginalny system operacyjny Dreambox, jeśli masz oryginalny sprzęt. To określa układ systemu plików, menedżera pakietów (opkg feeds) i które wersje softcamu są w ogóle dostępne. Warstwa druga to menedżer CAM — SoftCam Panel to najczęstszy, a to w zasadzie wtyczka, która pozwala ci przełączać, który plik binarny softcamu jest "aktywny" bez edytowania skryptów init ręcznie. Warstwa trzecia to warstwa protokołu: CCcam mówi swoim własnym protokołem proprietarnym (często nazywanym cs357x lub cs378x w zależności od wersji) plus newcamd, podczas gdy OScam mówi szerszym zestawem — cccam, newcamd (warianty 525x), camd35 przez TCP lub UDP, i radegast do diagnostyki.

Na temat ścieżek konfiguracji: CCcam.cfg zazwyczaj znajduje się w/usr/keys/ lub czasami bezpośrednio w/etc/, w zależności od tego, jak feed go zainstalował. OScam jest bardziej modułowy — znajdzieszoscam.server,oscam.conf,oscam.user, ioscam.services w/etc/tuxbox/config/oscam/ w większości wersji OpenATV i OpenPLi, chociaż niektóre obrazy zagnieżdżają to pod/usr/keys/oscam/ zamiast tego. Jeśli nie możesz ich znaleźć, sprawdź aktywny skrypt startowy CAM w/etc/init.d/ — powie ci dokładnie, gdzie to wskazuje.

Oryginalny sprzęt Dreambox a klony ma większe znaczenie, niż ludzie się spodziewają. Oryginalny Dreambox działający na systemie Dreambox OS ma swoją własną strukturę feedów i czasami swoje własne wersje binarne. Vu+ lub Zgemma działające na OpenATV korzystają z wspólnego feedu społeczności, który zazwyczaj jest bardziej aktualny, ale może mieć opóźnienia w bardzo nowych rewizjach OScam SVN. W każdym razie, sam softcam pochodzi albo z feedu softcamu obrazu (zainstalowanego przez opkg, który automatycznie obsługuje architekturę), albo jest ręcznie umieszczany w/usr/bin/ — a ręczne umieszczanie to miejsce, gdzie wkradają się niedopasowania architektury, do których przejdę w sekcji rozwiązywania problemów.

Jeszcze jedna rzecz dotycząca nazewnictwa, którą warto ustalić przed następną sekcją: "czytnik" w terminologii OScam to twoja lokalna karta lub połączenie upstream, które konsumujesz. "Konto" lub "użytkownik" to to, co przekazujesz czemuś, co konsumuje twój box. "Peer" w terminologii CCcam zazwyczaj oznacza inny box CCcam, z którym dzielisz się dwukierunkowo za pomocą linii C:. Trzymaj to prosto, ponieważ bloki konfiguracji wyglądają podobnie i łatwo pomylić, którą stronę konfigurujesz.

CCcam vs OScam vs Hybryda: Praktyczne Porównanie

Oto sedno porównania ustawień dreambox. Przejdę przez osie, które naprawdę mają znaczenie na co dzień, a nie punkty marketingowe.

CCcam: najprostsza konfiguracja, zamknięte źródło, konfiguracja w jednym pliku

Cała konfiguracja CCcam znajduje się w jednym pliku. Masz linie C: dla klientów, z którymi się łączysz, linie F: dla przyjaciół/serwerów, które obsługujesz, oraz garść dyrektyw, takich jak SERVER LISTEN PORT i WEBINFO LISTEN PORT. To naprawdę atrakcyjne, jeśli chcesz tylko jednego peera i nie chcesz o tym myśleć ponownie. Złapanie: CCcam jest zamkniętym źródłem i nie widziało znaczącego rozwoju od lat. To, co masz, to, co dostajesz — brak wsparcia dla nowych protokołów, brak aktywnych poprawek błędów i webif na porcie 16001, który daje ci minimalne informacje o statusie.

OScam: modułowy, aktywnie utrzymywany, lepsze logowanie i kontrola ECM

OScam dzieli konfigurację na wiele plików — oscam.conf dla ustawień globalnych, oscam.server dla czytników, oscam.user dla kont, oscam.services dla mapowania CAID/dostawcy, jeśli chcesz. Więcej plików oznacza więcej do zarządzania, pewnie. Ale jest aktywnie rozwijany (rewizje SVN nadal są regularnie wydawane), obsługuje znacznie więcej protokołów, a webif na porcie 8888 daje ci na żywo status ECM/EMM dla każdego czytnika, czasy odpowiedzi i kolorowe oznaczenie zdrowia połączenia. Jeśli coś jest nie tak, OScam informuje cię znacznie szybciej niż CCcam.

Pod względem użycia zasobów, na starszych boxach opartych na MIPS z 256MB RAM, oba działają dobrze z jednym lub dwoma czytnikami. Ślad OScam nieco wzrasta, jeśli włączysz rozbudowane logowanie lub uruchomisz wiele jednoczesnych czytników, ale nie jest to dramatyczne na nowoczesnych odbiornikach.

Hybrydowe łączenie OScam z CCcam za pomocą protokołu czytnika/klienta cccam

To jest część, którą większość przewodników całkowicie pomija, a szczerze mówiąc, to najlepsza odpowiedź dla wielu konfiguracji. Uruchamiasz OScam jako aktywne CAM — więc zachowujesz jego logi, webif i diagnostykę — ale dodajesz czytnik w oscam.server, który obsługuje protokół cccam, aby korzystać z źródła upstream, które oferuje tylko dostęp w stylu CCcam. Najlepsze z obu: nowoczesne narzędzia, źródło zgodne z dziedzictwem.

Przykładowy blok czytnika wygląda mniej więcej tak:

[reader]

Polecccversion ma większe znaczenie, niż ludzie myślą — niezgodne wersje CCcam podczas handshake powodują ciche błędy połączenia w niektórych implementacjach źródła. Ustawcccmaxhops na 0, chyba że chcesz konkretnie przekazywać dalsze udostępnienia, co wprowadza własne problemy z opóźnieniem (więcej na ten temat w sekcji oceny).

Macierz decyzyjna: pojedynczy peer vs wielu peerów, obsługa EMM, czas ECM

Jeśli masz dokładnie jedno stabilne źródło i nie zależy ci na redundancji, zwykły CCcam jest w porządku — mniej do skonfigurowania, mniej do zepsucia. Jeśli uruchamiasz wiele źródeł z przełączaniem awaryjnym, chcesz routingu per-CAID (wysyłanie konkretnych dostawców do konkretnych czytników) lub po prostu chcesz zobaczyć, co się dzieje, gdy coś się psuje, OScam lub hybrydowa konfiguracja wygrywa bezapelacyjnie. Obsługa EMM to kolejny czynnik — OScam daje ci szczegółową kontrolę nad przetwarzaniem EMM dla każdego czytnika (cache, shared, unique), podczas gdy CCcam obsługuje to bardziej nieprzejrzysto. Dla każdego, kto uruchamia więcej niż jedną kartę lub źródło, ta szczegółowość jest warta dodatkowych plików konfiguracyjnych.

Krok po kroku: Konfiguracja każdej konfiguracji na Dreamboxie

Wgrywanie obrazu enigma2 i instalowanie feedu softcam

Zakładam, że już masz wgrany obraz — OpenATV 7.x i najnowsze wersje OpenPLi działają dobrze na obecnym sprzęcie. Po wgraniu, przejdź do menedżera feedów obrazu (zwykle w Menu > Ustawienia > System > Menedżer oprogramowania) i zainstaluj feed softcam pasujący do twojego dekodera. To tutaj opkg wykonuje dopasowanie architektury za ciebie — urządzenia MIPS otrzymują binaria MIPS, urządzenia ARM (nowsze modele Vu+ i niektóre modele Zgemma) otrzymują binaria ARM. Nie kopiuj ręcznie binariów z starszego dekodera bez wcześniejszego sprawdzenia architektury.

CCcam.cfg: linia serwera, linie klienta (F:) i opcje cache

Minimalny plik CCcam.cfg do korzystania z jednego źródła upstream wygląda tak:

C: hostname 12000 myuser mypass

Format linii C: to hostname, port, nazwa użytkownika, hasło i opcjonalnie blok filtru CAID/ident, jeśli chcesz, aby tylko konkretni dostawcy byli przekazywani. Zauważ, że słowa kluczowe są wrażliwe na wielkość liter — CCcam nie zinterpretuje "server listen port" w małych literach, musi dokładnie odpowiadać dokumentacji. To myli ludzi bardziej, niż byś pomyślał, zwłaszcza przy kopiowaniu fragmentów konfiguracji z starych postów na forum z niespójnym formatowaniem.

Podstawy oscam.conf, oscam.server, oscam.user i oscam.services

W oscam.conf, w sekcji [global], zazwyczaj pozostawiasz domyślne ustawienia, chyba że dostosowujesz cache lub logowanie. Blok webif:

[webif]

W oscam.user zdefiniuj konto z grupą, która pokrywa się z grupą twojego czytnika:

[account]

Ta group=1 musi odpowiadać group= w dowolnym czytniku, z którego chcesz, aby to konto korzystało — jeśli to przegapisz, konto się łączy, ale nic nie dekoduje.

Uruchamianie, ponowne uruchamianie i ustawianie aktywnego CAM w panelu SoftCam

Gdy konfiguracje są zapisane, ustaw chmod 600 na każdym pliku zawierającym dane uwierzytelniające — CCcam.cfg i oscam.user zawierają hasła w postaci tekstu jawnego, a nie ma powodu, aby miały uprawnienia do odczytu dla wszystkich. Wejdź do panelu SoftCam, wybierz CCcam lub OScam jako jedyne aktywne CAM i uruchom ponownie. Aby zobaczyć, co się dzieje, śledź log OScam — zwykle w/tmp/.oscam/oscam.log lub gdziekolwiek wskazuje twoja dyrektywa logu — za pomocącat /tmp/.oscam/oscam.log lub na żywotail -f jeśli busybox twojego dekodera to wspiera. Dla CCcam, albo telnetuj do portu nasłuchu, aby uzyskać komunikat o statusie, albo sprawdź webif na porcie 16001.

Jak ocenić źródło udostępniania kart upstream (ogólnie)

Nie będę wymieniał żadnego dostawcy tutaj — to nie jest celem porównania konfiguracji dreamboxa, a szczerze mówiąc, konkretna nazwa ma znacznie mniejsze znaczenie niż to, czy podstawy techniczne się zgadzają. Oto, na co naprawdę zwrócić uwagę.

Kompatybilność protokołu i wersji z twoim CAM

Jakiekolwiek źródło, które oceniasz, powinno być w stanie jasno powiedzieć, czy to protokół newcamd czy cccam, i która wersja. Jeśli uruchamiasz OScam i oferują tylko newcamd, to w porządku — OScam obsługuje to natywnie. Jeśli mówią tylko cccam i chcesz pozostać przy OScam dla diagnostyki, to jest twój scenariusz hybrydowego czytnika z wcześniejszego opisu. Niezgodne lub nieokreślone wersje protokołu to czerwony flag.

Czas odpowiedzi ECM, czas działania i pokrycie CAID/dostawcy

To jest jedyna najbardziej użyteczna liczba, którą możesz zmierzyć samodzielnie, a prawie nikt nie wyjaśnia jak. W webif OScam, kliknij w czytnik i spójrz na kolumnę czasu ECM — dobre dekodowanie zazwyczaj jest poniżej 400ms. Jeśli konsekwentnie widzisz czasy ECM trwające kilka sekund, to właśnie tam wyjaśnia się twoje zamrażanie, niezależnie od tego, co źródło twierdzi o czasie działania lub pokryciu. Sprawdź również, czy CAID i identyfikatory dostawcy, które źródło faktycznie dostarcza, odpowiadają tym, które używają twoje docelowe kanały — roszczenia o pokrycie nic nie znaczą, jeśli konkretny CAID nie znajduje się na liście.

Karty lokalne vs udostępniane i co 'lokalne' powinno oznaczać technicznie

Prawdziwa karta lokalna, technicznie, pojawia się jako czytnik z jedną hopką z szybkim, regularnym aktualizowaniem EMM i konsekwentnie niskim czasem ECM — ponieważ nie ma łańcucha przekaźników dodających opóźnienie. Karta udostępniana z głębokim skokiem może nadal dekodować, ale każdy skok w łańcuchu dodaje opóźnienie i niestabilność, co jest dokładnie tym, co dekoduje dobrze przez dziesięć minut, a potem zamraża się pod obciążeniem. Jeśli cccmaxhops w czytniku, z którego korzystasz, jest ustawione wysoko, lub źródło nie może powiedzieć, ile skoków jest zaangażowanych, traktuj to jako udostępniane i z dużą ilością skoków, nawet jeśli nazywają to "lokalnym".

Czerwone flagi: nierealistyczne listy kanałów, brak szczegółów protokołu, brak okna testowego

Ogólnie: bądź sceptyczny wobec wszystkiego, co obiecuje niewiarygodnie dużą listę kanałów z jednego źródła, wobec każdego, kto nie poda protokołu lub pokrycia CAID w sposób jasny, oraz wobec każdego, kto nie chce pozwolić ci zweryfikować, czy połączenie rzeczywiście działa przed podjęciem decyzji. To są tylko mierzalne sygnały techniczne, a nie opinie — możesz sprawdzić każdy z nich samodzielnie w interfejsie OScam lub na ekranie statusu CCcam w ciągu kilku minut od połączenia.

Rozwiązywanie najczęstszych problemów z udostępnianiem na Dreamboxie

Zawieszanie się kanałów i długie czasy ECM

Najpierw sprawdź status czytnika w interfejsie OScam — jeśli czas ECM przekracza jedną sekundę, to jest przyczyna. Wyłącz czytniki, których nie używasz aktywnie (każdy aktywny czytnik zwiększa obciążenie), dostosuj linie cache i pref w CCcam, jeśli korzystasz z CCcam, i sprawdź podstawowe zdrowie sieci — wysoka latencja lub utrata pakietów do źródła będą bezpośrednio objawiać się jako opóźnienie ECM. W przypadku CCcam, ustawienia CACHEEX mogą również wpływać na to, jeśli jesteś połączony z innymi partnerami CCcam.

Zielony/czarny ekran i 'brak CAM' po aktualizacji obrazu

To prawie zawsze jedna z trzech rzeczy: wersja feedu softcamu nie zsynchronizowała się z aktualizacją obrazu i wymaga ponownej instalacji, wybrano niewłaściwy CAM w panelu SoftCam po aktualizacji, która go zresetowała, lub — i to jest to, o czym nikt nie mówi — architektura binarna się nie zgadza. Jeśli ręcznie wrzuciłeś binarny plik MIPS na box, który zaktualizował się, aby działać na ARM (lub przeniosłeś konfiguracje ze starego boxa MIPS do nowego odbiornika opartego na ARM), binarny plik cicho nie uruchomi się bez wyraźnego błędu. Zainstaluj odpowiednią wersję architektury z feedu zamiast debugować binarny plik, który nie może się uruchomić.

Czytnik połączony, ale brak dekodowania (niedopasowanie grupy/CAID)

"Połączony" w interfejsie oznacza tylko, że handshake TCP się powiódł — nie mówi nic o tym, czy uprawnienia rzeczywiście przepływają. Dwie przyczyny obejmują prawie każdy przypadek: group= w czytniku nie pokrywa się z group= na koncie użytkownika, które próbuje go użyć, lub źródło dostarcza tylko CAID/ident, który nie pasuje do tego, co rzeczywiście wymaga kanał, który oglądasz. Sprawdź logi pod kątem "brak pasującego czytnika" — to OScam mówi ci dokładnie to. Możesz również ręcznie sprawdzić widok uprawnień, aby potwierdzić, jakie CAID-y czytnik rzeczywiście przedstawia.

Synchronizacja czasu, NTP i dlaczego zły zegar przerywa połączenia

To jest coś, co jest ciągle pomijane. Zarówno handshake newcamd, jak i cccam są wrażliwe na dryf zegara — jeśli zegar systemowy twojego Dreamboxa jest nieprawidłowy (częste w boxach bez zasilania bateryjnego RTC lub po przerwie w zasilaniu), handshake może całkowicie nie powieść się, mimo że wszystko inne jest skonfigurowane poprawnie. Włącz NTP w Menu > Ustawienia > System > Czas, ustaw poprawną strefę czasową i uruchom ponownie. Jeśli widzisz sporadyczne "timeout ecm" lub błędy handshake bez innej oczywistej przyczyny, sprawdź zegar, zanim dotkniesz czegokolwiek innego.

Dwa inne szybkie pułapki, które warto zaznaczyć: pliki konfiguracyjne edytowane w systemie Windows czasami mają zakończenia linii CRLF, na które niektóre parsery CCcam/OScam mogą nie reagować — zapisz ponownie jako zakończenia linii Unix, jeśli konfiguracja, która wygląda poprawnie, nadal nie będzie się analizować. A jeśli jesteś za CGNAT lub w rygorystycznej zaporze, połączenia wychodzące na porcie nasłuchu newcamd/cccam mogą być cicho blokowane — przetestuj za pomocą podstawowego sprawdzenia portu z zewnątrz swojej sieci, zanim założysz, że konfiguracja jest błędna. Nie wybieraj również dwóch aktywnych softcamów w panelu SoftCam jednocześnie — będą konkurować o tuner i ścieżkę ECM, a żaden z nich nie będzie dekodować niezawodnie.