Najlepsze kanały telewizyjne satelitarne dla konfiguracji CCcam/OScam

Jeśli szukałeś najlepszych kanałów telewizyjnych satelitarnych do uruchomienia przez swoją skrzynkę CCcam lub OScam, prawdopodobnie zauważyłeś, że większość artykułów na ten temat jest bezużyteczna. Wymieniają ogólne nazwy pakietów i na tym kończą. Tak to nie działa.

To, co naprawdę decyduje o tym, czy kanał się otworzy, to to, czy jeden z twoich czytników może odpowiedzieć na ECM dla tej konkretnej usługi. Nie nazwa kanału, nie satelita, na którym się znajduje, nie pakiet, do którego jest przypisany w EPG twojego odbiornika. Najlepsze kanały telewizyjne satelitarne dla twojej konfiguracji to po prostu te, które twoje pokrycie CAID pozwala dekodować czysto i konsekwentnie. Wszystko inne — zacięcia, czarne ekrany, błędy NOK — sprowadza się do tego jednego mechanizmu.

Spędziłem wiele godzin w oscam.log o 2 w nocy, próbując zrozumieć, dlaczego jeden kanał w pakiecie dekoduje dobrze, podczas gdy obok niego jest czarny. Przejdźmy więc przez rzeczywiste mechanizmy, pliki konfiguracyjne i jak przetestować, czy twoja konfiguracja działa, zanim zainwestujesz w nią więcej czasu.

Jak CCcam i OScam decydują, które kanały się otwierają

Każdy zaszyfrowany kanał na transponderze zawiera opis CA w swoim PMT (Program Map Table). Ten opis zawiera CAID (identyfikator dostępu warunkowego, 4-cyfrowa wartość heksadecymalna, taka jak 0x1802 lub 0x0B00) i zazwyczaj identyfikator dostawcy związany z nim. Gdy twój odbiornik stroi kanał, pobiera ECM (Entitlement Control Message) odniesiony w tym PMT i przekazuje go do OScam lub CCcam do przetworzenia.

Wyjaśnienie CAID, identyfikatora dostawcy i identyfikatora usługi

Pomyśl o tym jako o trzech warstwach. CAID informuje system, który system dostępu warunkowego jest używany. Identyfikator dostawcy (provid) zawęża to do konkretnego operatora lub pakietu w tym systemie CA — dwa kanały mogą dzielić CAID, ale używać różnych identyfikatorów dostawcy, co ma ogromne znaczenie, gdy próbujesz zrozumieć, dlaczego jeden się otwiera, a drugi nie. Identyfikator usługi (SID) to po prostu konkretny kanał w multipleksie transpondera.

Żaden z tych trzech wartości nie istnieje w izolacji. Wpis czytnika w oscam.server odnosi się do CAID i identyfikatora dostawcy, a nie do przyjaznej nazwy kanału, którą pokazuje ci EPG. To jest rozłączenie, które myli ludzi.

Przepływ żądania ECM od odbiornika do czytnika

Oto rzeczywista sekwencja: odbiornik stroi transponder, wyciąga ECM ze strumienia, wysyła go do interfejsu CAM/softcam, OScam odbiera go przez API DVB, sprawdza CAID w odniesieniu do każdej skonfigurowanej linii caid= w czytnikach i przekazuje ECM do tego czytnika, który pasuje (lokalny czytnik kart, udostępnienie sieciowe lub peer OScam). Ten czytnik — lub fizyczna karta inteligentna za nim — deszyfruje ECM i zwraca słowo kontrolne (CW). OScam przekazuje to CW z powrotem do odbiornika, który używa go do dekodowania rzeczywistego strumienia wideo/audio.

Ta podróż tam i z powrotem odbywa się co 8-10 sekund, ponieważ mniej więcej tak często większość operatorów zmienia klucze. Jeśli jakakolwiek część tego łańcucha się łamie — błędne mapowanie CAID, brak skonfigurowanego czytnika dla tego provid, wolny peer — kanał nigdy się nie otworzy lub zamarza podczas rotacji.

Dlaczego 'najlepsze kanały' naprawdę dotyczą pokrycia CAID

To jest część, która jest pomijana w większości opisów. Nie ma uniwersalnej listy najlepszych kanałów telewizyjnych satelitarnych — jest tylko "kanały, których kombinacja CAID/provid jest pokryta przez przynajmniej jednego z moich czytników, z akceptowalnym czasem odpowiedzi ECM." Dwóch ludzi uruchamiających CCcam na identycznych odbiornikach może mieć zupełnie różne doświadczenia na tym samym transponderze, ponieważ ich pokrycie kart/udziałów różni się.

Więc kiedy oceniasz, co możesz faktycznie oglądać, przestań myśleć w kategoriach nazw kanałów i zacznij myśleć w kategoriach pokrycia CAID. To przekształcenie to największa rzecz, która oddziela ludzi, którzy mają stabilną konfigurację, od ludzi, którzy spędzają tygodnie zdezorientowani, dlaczego "najlepsze kanały telewizyjne satelitarne" wciąż im znikają.

Ścieżka dekodowania lokalnej karty vs. udostępnienia sieciowego

Lokalny czytnik kart (fizyczna karta inteligentna w urządzeniu czytającym, odniesiona jako device = /dev/ttyUSB0 lub podobnie w oscam.server) odpowiada na ECM prawie natychmiast — zazwyczaj poniżej 100 ms — ponieważ nie ma skoku sieciowego. Udostępnienie sieciowe (inny serwer OScam lub CCcam przekazujący ECM przez TCP) dodaje opóźnienie proporcjonalne do odległości i obciążenia serwera. Dla kanałów z szybkim obracaniem kluczy, ta różnica w opóźnieniu to cała gra.

Mapowanie kanałów do CAID i identyfikatorów dostawców

Zanim będziesz mógł cokolwiek dostroić, musisz wiedzieć, o jaki CAID i provid prosi kanał. To jest krok, którego prawie nikt nie wyjaśnia poprawnie.

Odczytywanie CAID i identyfikatora dostawcy z ekranu informacji odbiornika

Na odbiornikach opartych na Enigma2, dostrój kanał i naciśnij przycisk informacji, a następnie przycisk CA/CAK (różni się w zależności od obrazu — w OpenATV zazwyczaj jest to długie naciśnięcie na EPG lub dedykowany plugin "CA info"). Otrzymasz odczyt pokazujący aktywny CAID i identyfikator dostawcy dla tej usługi, czasami z zielonym/czerwonym wskaźnikiem pokazującym, czy CW zostało faktycznie zwrócone.

Jeśli twój obraz nie ma dedykowanego ekranu informacji CA, plugin zrzutu PMT lub szybkie sprawdzenie w edytorze pakietów usług pokaże ci CAID osadzony w ciągu odniesienia usługi — Enigma2 koduje go bezpośrednio w odniesieniu.

Używanie oscamuser.log i statystyk Reader/EMM w interfejsie internetowym OScam

Szybszym sposobem, jeśli już masz uruchomione OScam, jest interfejs internetowy pod adresem http://SERVER_IP:8888 (domyślny port, zmień go w oscam.conf pod httpport, jeśli go przeniosłeś). Przejdź do Czytników, kliknij w historię ECM i zmień na kanał, który cię interesuje — zobaczysz przychodzące żądania ECM rejestrowane w czasie rzeczywistym z CAID, provid i SID rozdzielonymi w osobnych kolumnach.

Możesz również po prostu śledzić log bezpośrednio:

tail -f /var/log/oscam/oscam.log

Zwróć uwagę na linie pokazujące "znaleziono (przechwycone)" lub "znaleziono (cache)" obok par CAID/provid, gdy zmieniasz kanały. To najszybszy sposób, aby potwierdzić, co dokładnie żąda kanał, bez zgadywania.

Tworzenie grupy oscam.services dla pakietów kanałowych

Gdy już znasz triplet CAID/provid/SID, które cię interesują, pogrupuj je w oscam.services:

[sports-group]




Następnie odwołaj się do tej nazwy grupy w strofie czytnika w oscam.server przez services= (i opcjonalnie rsvd=, jeśli czytnik ma obsługiwać tylko te usługi i nic więcej). W ten sposób ograniczasz konkretny czytnik do konkretnych kanałów, zamiast pozwalać mu odpowiadać na wszystko, do czego jest technicznie zdolny — przydatne, gdy masz wolniejsze udostępnienie, które chcesz, aby tylko pełniło rolę zapasową dla wąskiego zestawu kanałów.

Typowe rodziny CAID i do jakich pakietów są przypisane

Nie wymieniając żadnego komercyjnego operatora, warto wiedzieć, że zakresy CAID mają tendencję do grupowania się według dostawcy dostępu warunkowego, a nie według nadawcy. Zakres 0x05xx zazwyczaj wskazuje jedną rodzinę dostawcy CA, 0x0Bxx inną, 0x18xx inną, i tak dalej. Wielu nadawców może licencjonować tego samego dostawcę CA i dzielić się zakresem CAID, różniąc się tylko identyfikatorem dostawcy. Dokładnie dlatego "kanał działa, ale ten drugi na tym samym satelicie nie" zazwyczaj jest niezgodnością provid, a nie niezgodnością CAID — sprawdź obie wartości, a nie tylko jedną.

Priorytet czytnika, zapas i pamięć podręczna, aby utrzymać stabilność kanałów

Gdy kanały się otwierają, następnym problemem jest utrzymanie ich stabilności. Tutaj równoważenie obciążenia i konfiguracja zapasowa mają rzeczywiste znaczenie, a wiele konfiguracji zawodzi w rzeczywistym użytkowaniu.

group= i przypisanie CAID w oscam.server

Każda sekcja readera otrzymuje swój własny numer grupy, a możesz przypisać wiele readerów do tej samej grupy, aby OScam traktował je jako wymienne w celach równoważenia obciążenia. Typowy blok readera wygląda tak:

[reader]









Numery grup pozwalają podzielić listę kanałów na logiczne pojemniki — grupa 1 dla głównego udostępnienia, grupa 2 dla zapasowego, i tak dalej — a następnie odwoływać się do tych grup z oscam.services lub oscam.dvbapi w razie potrzeby.

Ustawienie lb_weight i lb_priority dla równoważenia obciążenia

W oscam.conf w sekcji [global] ustaw lb_mode = 1, aby włączyć równoważenie obciążenia (jest kilka trybów; 1 to standardowy tryb oparty na niezawodności, w którym większość ludzi działa). Następnie dla każdego readera możesz dostosować priorytet za pomocą lb_weight — wyższa waga oznacza, że OScam częściej faworyzuje tego readera, gdy wiele readerów może odpowiedzieć na ten sam CAID/provid.

To ma znaczenie, gdy masz dwóch readerów pokrywających ten sam CAID: twoja lokalna karta powinna prawie zawsze mieć wyższą lb_weight niż udostępnienie sieciowe, ponieważ odpowiada szybciej i nie zależy od obciążenia serwera kogoś innego.

fallback= i fallbacktimeout, aby uniknąć zawieszeń

Ustaw fallback = 1 na wtórnym readerze, aby OScam korzystał z niego tylko wtedy, gdy główny reader przekroczy czas oczekiwania. Połącz to z fallbacktimeout (w milisekundach) w oscam.conf — coś takiego jak fallbacktimeout = 1500 oznacza, że OScam czeka 1,5 sekundy na główny reader, zanim spróbuje użyć zapasowego. Ustaw to zbyt wysoko, a zobaczysz widoczne zawieszenia, podczas gdy OScam czeka; zbyt nisko, a otrzymasz fałszywe wyzwalacze zapasowe na readerze, który był tylko chwilowo wolny.

W CCcam.cfg, równoważny koncept jest obsługiwany przez linie C: (dla udostępniania kart) i F: (dla uprawnień do udostępniania znajomym), przy czym priorytet jest efektywnie określany przez kolejność, w jakiej są wymienione readery i ich indywidualne czasy odpowiedzi. Możesz również przypisać konkretne SIDs do konkretnych połączeń readerów, używając parametru sid= w niektórych wersjach CCcam, co działa podobnie do grupowania services= w OScam.

cacheex i jak przyspiesza popularne kanały

Wymiana pamięci podręcznej (cacheex_mode = 1, 2 lub 3 w konfiguracji reader/user) pozwala partnerom dzielić się już zdekodowanymi słowami kontrolnymi, zamiast aby każdy serwer niezależnie łączył się z kartą. Tryb 1 to tylko odbiór, tryb 2 to tylko wysyłanie, tryb 3 to oba. Na ruchomym kanale może to dramatycznie skrócić czas odpowiedzi ECM, ponieważ CW, które ktoś inny już pobrał, jest ponownie używane zamiast ponownie żądane z karty.

Haczyk: cacheex nie dodaje pokrycia — tylko przyspiesza kanały, do których już masz ważny dostęp — a jeśli partner jest źle skonfigurowany lub wysyła przestarzałe CW, możesz otrzymać fałszywe trafienia, które powodują chwilowe uszkodzenia lub zawieszenia tuż po zmianie klucza. Traktuj to jako optymalizację, a nie jako rozwiązanie problemu z brakującym pokryciem.

Testowanie i rozwiązywanie problemów z dekodowaniem kanałów

To jest sekcja, którą większość przewodników całkowicie pomija, a to ta, która naprawdę oszczędza czas.

Odczytywanie czasu ECM i kodów statusu w interfejsie webowym

W interfejsie webowym OScam w sekcji Readers, kolumna statusu ECM pokaże zielony dla OK, czerwony dla NOK i pusty, jeśli żaden ECM nie został w ogóle zażądany. Obok niej kolumna czasu ECM pokazuje czas odpowiedzi w milisekundach. Poniżej 200 ms jest świetne, do 500 ms jest zazwyczaj w porządku dla standardowych kanałów, a wszystko, co konsekwentnie przekracza 500 ms, zaczyna ryzykować widoczne zawieszenia na kanałach z szybkim obrotem kluczy — szczególnie transmisje sportowe. Po 1000 ms, oczekuj zawieszeń na prawie wszystkim.

Diagnozowanie czarnego ekranu vs. zawieszenia vs. zniekształcenia

To trzy różne problemy z trzema różnymi przyczynami. Czarny ekran bez obrazu zazwyczaj oznacza, że żaden reader nie odpowiada na ten CAID/provid — sprawdź oscam.log pod kątem "brak pasującego readera" lub "odrzucona grupa" obok żądania ECM. Zamarznięty obraz, który ostatecznie się wznawia, wskazuje na wolną odpowiedź ECM — CW dotarło, ale zbyt późno. Zniekształcony/zakłócony obraz, który nigdy się nie wyczyści, zazwyczaj oznacza, że otrzymujesz słowo kontrolne, ale jest ono błędne lub wygasło, co często objawia się powtarzającymi się wpisami NOK z readera, który ma CAID, ale którego karta nie jest autoryzowana do tej konkretnej warstwy usługi.

Sprawdzanie zapory i portów dla łączności udostępniania

Domyślny interfejs webowy OScam działa na porcie 8888. Porty udostępniania różnią się znacznie w zależności od operatora — zazwyczaj gdzieś w zakresie 10000-30000 — więc sprawdź linię device= swojego konkretnego readera, aby uzyskać rzeczywisty używany port. Przetestuj łączność za pomocą:

nc -zv SERVER_IP PORT

Jeśli to się zawiesza lub odmawia, sprawdź zarówno zasady zapory wychodzącej, jak i, jeśli hostujesz readera lokalnie dla innych do połączenia, zasady iptables dla przychodzących oraz wszelkie przekierowania portów na swoim routerze. Reader utknął na CONNECTING zamiast CONNECTED w interfejsie webowym prawie zawsze wraca do problemu z portem lub zaporą, a nie literówki w konfiguracji.

Weryfikacja liczby ECM/EMM w celu potwierdzenia aktywnej karty

W widoku szczegółów readera w interfejsie webowym obserwuj liczniki ECM i EMM. Wzrost liczby ECM OK potwierdza, że karta aktywnie dekoduje. Liczby EMM powinny również okresowo wzrastać — to karta otrzymująca aktualizacje uprawnień. Reader, który pokazuje CONNECTED, poprawny CAID, ale płaską liczbę EMM i rosnącą liczbę NOK zazwyczaj oznacza, że poziom subskrypcji karty nie obejmuje tej konkretnej usługi, mimo że CAID technicznie pasuje.

Na co zwrócić uwagę przy wyborze źródła udostępniania (ogólnie)

Jeśli oceniasz źródło udostępniania, a nie uruchamiasz własnej karty, oceniaj je na podstawie mierzalnych kryteriów — a nie twierdzeń marketingowych.

Pokrycie CAID a kanały, które Cię interesują

Zapytaj konkretnie, które kombinacje CAID/provid są objęte, a nie tylko "jakie pakiety". Źródło twierdzące o szerokim pokryciu, ale niejasne w szczegółach, to czerwony flag. Porównaj ich odpowiedź z listą CAID, którą wcześniej stworzyłeś na podstawie ekranu informacji swojego odbiornika.

Czas działania serwera, czas ECM i liczba hopów

Liczba hopów ma większe znaczenie, niż ludzie zdają sobie sprawę — połączenie hop 1 (reader rozmawia bezpośrednio z serwerem karty) prawie zawsze przewyższa łańcuch hop 3 lub 4, gdzie twój ECM jest przekazywany przez wiele pośrednich serwerów, zanim dotrze do rzeczywistej karty. Każdy hop dodaje opóźnienie i kolejny punkt awarii. Zapytaj bezpośrednio o typowe czasy odpowiedzi ECM i ile hopów będziesz miał do pokonania.

Wsparcie protokołów: CCcam, newcamd i OScam-to-OScam

Potwierdź, który protokół rzeczywiście wspierają — CCcam (linia C:), newcamd (linia N:, zazwyczaj przez cs378x w OScam) lub natywny OScam-to-OScam. Ma to wpływ na to, który plik konfiguracyjny będziesz edytować i jakie oprogramowanie klienckie potrzebuje twój odbiornik. Jeśli już używasz OScam, połączenie OScam-to-OScam zazwyczaj jest najbardziej konfigurowalne z trzech, dając pełny dostęp do ustawień group=, lb_weight i cacheex na tym połączeniu.

Czerwone flagi, które wskazują na niestabilne lub przeciążone źródło

Ciągłe ponowne połączenia w twoim logu, czasy ECM konsekwentnie powyżej 1000ms oraz każde źródło, które prosi cię o wyłączenie logowania, to wszystkie znaki ostrzegawcze. Tak samo jak konfiguracja bez ścieżki zapasowej — pojedynczy punkt awarii, który wyłącza każdy kanał w momencie, gdy jeden serwer ma problem. Źródło, które potrafi wyjaśnić swoje własne czasy działania i charakterystyki odpowiedzi bez machania rękami, jest warte więcej niż takie, które składa ogólne obietnice o posiadaniu najlepszych dostępnych kanałów telewizyjnych satelitarnych.

Przypadki brzegowe, o których warto wiedzieć

Kilka rzeczy, które mogą zaskoczyć ludzi po tym, jak myślą, że wszystko jest już ustawione.

Kanały czasami zmieniają CAID lub identyfikator dostawcy podczas okien konserwacyjnych operatora lub sezonowych zmian pakietów, co psuje przypisanie czytnika, które działało dobrze przez miesiące. Jeśli kanał, który wcześniej się otwierał, nagle staje się czarny, sprawdź jego CAID/provid, zanim założysz, że twój czytnik przestał działać — przeszukaj log pod kątem SID i porównaj z tym, co pierwotnie skonfigurowałeś.

Regionalne transmisje i kanały symultaniczne czasami dzielą identyfikator usługi w różnych regionach, ale wymagają innego identyfikatora dostawcy w każdym regionie — to częsta przyczyna "działa dla mojego przyjaciela, ale nie dla mnie", nawet na tym samym nominalnym kanale.

Kanały z szybkim obrotem kluczy, powszechne w niektórych transmisjach sportowych, mogą się zawieszać nawet przy czasach ECM, które byłyby całkowicie w porządku na normalnym kanale. Jeśli konkretny kanał się zawiesza, podczas gdy wszystko inne działa płynnie, sprawdź, czy obraca klucze szybciej niż zwykle i nadaj priorytet swojemu najszybszemu czytnikowi specjalnie dla niego.

Jeśli twój odbiornik znajduje się za CGNAT lub w konfiguracji podwójnego NAT, połączenia udostępniania wychodzącego zazwyczaj nadal działają dobrze, ale wymiana cacheex (gdzie peer musi się z tobą skontaktować) często zawodzi bez żadnych komunikatów. Jeśli cacheex nie działa zgodnie z oczekiwaniami, sprawdź swoją sytuację NAT, zanim założysz błąd w konfiguracji.

I zwróć uwagę na przypadek, gdy czytnik pokazuje STATUS POŁĄCZENIA, CAID się zgadza, ale nadal otrzymujesz NOK — to poziom subskrypcji karty nie obejmujący tej usługi, a nie problem z konfiguracją. Żaden tuning priorytetu czytnika tego nie naprawi; potrzebujesz pokrycia dla tego konkretnego provid, a nie tylko CAID.

Na koniec, gdy wiele czytników dzieli ten sam CAID, wolny peer może nadal wygrać wyścig równoważenia obciążenia sporadycznie, jeśli lb_weight nie jest ustawiony wystarczająco zdecydowanie — prowadzi to do sporadycznego zawieszania, które wydaje się losowe, ale w rzeczywistości jest po prostu OScam wybierającym wolniejszy czytnik w pewnym procencie czasu.