Najlepsza konfiguracja OSCam: przewodnik po optymalnej konfiguracji (2026)

Jeśli używasz OSCam od dłużej niż tydzień, już wiesz, że domyślne konfiguracje krążące po forach to bałagan. Połowa z nich została napisana pod konfigurację kart, której nikt już nie używa, a druga połowa to wklejone wartości bez wyjaśnienia, co właściwie robią. Ten poradnik przeprowadzi Cię przez to, co nazwałbym najlepszą konfiguracją OSCam dla stabilnego, niskoopóźnieniowego zestawu readerów w 2026 roku — nie chodzi o najwyższy możliwy wynik na ekranie benchmarku, ale o konfigurację, która przetrwa tydzień prawdziwego ruchu, bez konieczności logowania się przez SSH o 2 w nocy, by zrestartować usługę.

Zakładam, że masz już skompilowany i działający OSCam. To nie jest wpis typu „czym jest cardsharing”. Chodzi o dostrojenie oscam.conf, oscam.server, oscam.user i oscam.services, tak aby czasy ECM pozostawały niskie, a Twoje readery nie padały pod obciążeniem.

Co tak naprawdę oznacza „najlepsza” konfiguracja OSCam

Oto coś, o czym nikt nie mówi z góry: nie istnieje jedna najlepsza konfiguracja OSCam, którą można wrzucić na dowolne urządzenie i o niej zapomnieć. Raspberry Pi obsługujące jedną lokalną kartę zachowuje się zupełnie inaczej niż VPS łączący się jednocześnie z sześcioma partnerami cache-ex przez newcamd i CCcam. „Najlepsze” ustawienia dla jednego są aktywnie szkodliwe dla drugiego — zwiększenie liczby wątków cache-ex na STB z 512 MB pamięci RAM po prostu doprowadzi do zabicia procesu przez OOM killer.

Optymalizacja pod kątem szybkości dekodowania a stabilność

Niski czas ECM świetnie wygląda na wykresie, ale zbyt agresywne dążenie do niego to prosta droga do niestabilnych konfiguracji. Jeśli ustawisz zbyt ciasne limity czasu, by zaoszczędzić 200 ms na czasie dekodowania, otrzymasz przedwczesny fallback readera i zerwanie obrazu w momencie, gdy Twoja sieć się zatnie. Naprawdę dobra konfiguracja równoważy oba te aspekty — na tyle szybka, by zmiana kanału wydawała się natychmiastowa, na tyle stabilna, by nie dostawać zgłoszeń o zawieszaniu się w godzinach szczytu.

Dlaczego nie istnieje jedna uniwersalna konfiguracja

Twój sprzęt, liczba readerów oraz mieszanka protokołów (lokalna karta vs. CCcam vs. newcamd vs. gbox) zmieniają to, jak wygląda „optymalna” konfiguracja. Konfiguracja dostrojona pod jedną lokalną kartę DVB-S2 bez żadnego udostępniania powinna wyglądać zupełnie inaczej niż ta zbudowana dla pięcioreaderowego urządzenia z równoważeniem obciążenia, pobierającego dane z wielu źródeł nadrzędnych. Ktoś, kto podaje Ci jeden uniwersalny plik oscam.conf, nie pytając o Twoją konfigurację, daje Ci punkt wyjścia, a nie gotowy produkt.

Cztery podstawowe pliki i ich rola

Wszystko znajduje się w czterech plikach, które współpracują ze sobą.oscam.conf obsługuje globalne zachowanie — logowanie, limity czasu, interfejs webowy, port monitora, anti-cascading.oscam.server definiuje Twoje readery: lokalne sloty kart chipowych, połączenia proxy do źródeł CCcam lub newcamd, peery gbox.oscam.user definiuje, kto może łączyć się z Twoim urządzeniem i co może widzieć.oscam.services grupuje CAID-y i identy w nazwane pakiety usług, które możesz umieścić na białej liście lub zablokować dla poszczególnych readerów i użytkowników. Ustaw poprawnie relację między tymi czterema plikami, a większość skarg typu „brak kanałów” zniknie sama.

Optymalne globalne ustawienia oscam.conf

W większości buildów znajdziesz oscam.conf pod/etc/tuxbox/config/oscam.conf, chociaż niektóre dystrybucje używają/var/keys/ lub cokolwiek, co zostało ustawione jako ConfigDir podczas kompilacji za pomocą--with-configdir. Jeśli nie masz pewności, sprawdź stopkę interfejsu webowego lub uruchom OSCam z-c /path/to/configaby to wymusić.

[global] ustawienia logowania oraz nice/pidfile

Oto rozsądny blok [global], którego używam jako punktu wyjścia:

[global]

maxlogsize=50 sprawia, że plik logu nie rozrasta się powyżej 50KB przed rotacją — na sprzęcie STB z ograniczoną liczbą zapisów do pamięci flash ma to większe znaczenie, niż się wydaje.nice=-1 daje OSCam-owi lekko podwyższony priorytet szeregowania względem innych procesów, co pomaga w czasie odpowiedzi ECM na urządzeniach pełniących podwójną funkcję.preferlocalcards=1 mówi OSCam-owi, żeby zawsze najpierw próbował lokalnej karty, zanim przełączy się na czytnik sieciowy — dokładnie to, czego chcesz, jeśli jesteś właścicielem karty i używasz peerów jedynie jako zapasu.

[webif] włączanie interfejsu webowego na porcie 8888

[webif]

Port 8888 jest domyślny dla OSCam i nie ma powodu, by go zmieniać, chyba że coś innego na urządzeniu już go używa. To, co naprawdę ma znaczenie, tohttpallowed — ogranicz go do zakresu swojej sieci lokalnej. Pozostawienie otwartego interfejsu webowego na 0.0.0.0 na urządzeniu z portami widocznymi w internecie to prosty sposób na to, żeby ktoś wykradł dane uwierzytelniające do twojej karty. Wrócę do tego w FAQ dotyczącym bezpieczeństwa, ale traktuj to jako niepodlegające dyskusji.

Dostrajanie [monitor] i [anticasc]

[monitor]

Anti-cascading wykrywa, kiedy jedna karta jest współdzielona z zbyt wieloma jednoczesnymi klientami, i wtedy ją dławi lub blokuje. Jest to naprawdę przydatne na współdzielonym urządzeniu z wieloma niezaufanymi użytkownikami, ale na sprzęcie STB z małą ilością RAM-u dodaje stały narzut na sprawdzanie, którego prawdopodobnie nie potrzebujesz, jeśli jesteś jedynym klientem. Jeśli działasz na czymś takim jak 512MB Vu+ lub podobnym urządzeniu, zostawanticasc wyłączone i polegaj zamiast tego nauniq w oscam.user — jest to tańsze i wykonuje niemal to samo zadanie w konfiguracji z jednym właścicielem.

wartości clienttimeout, fallbacktimeout i cachedelay

clienttimeout=15000

clienttimeout (w milisekundach) to czas, przez jaki OSCam czeka na odpowiedź, zanim całkowicie zrezygnuje z żądania ECM — 15000ms to rozsądny limit górny.fallbacktimeout to ta wartość, którą ludzie stale ustawiają błędnie. Kontroluje ona, jak długo OSCam czeka na głównym czytniku, zanim spróbuje czytnika zapasowego dla tego samego ECM. Ustawiona zbyt nisko (powiedzmy poniżej 1000ms) powoduje przedwczesne przełączenie na zapas — OSCam przeskakuje do czytnika zapasowego, zanim główna karta w ogóle dostała uczciwą szansę, marnując przepustowość i czasem powodując zduplikowane żądania CW. Ustawiona zbyt wysoko sprawi, że słabo radzący sobie główny czytnik zablokuje cały twój łańcuch, zanim zadziała mechanizm zapasowy. 2500ms to dobry środek dla większości konfiguracji z lokalną kartą plus zapasem; obniżaj ją bliżej 1500ms tylko wtedy, gdy średni czas ECM twojego głównego czytnika jest konsekwentnie poniżej 500ms.

Konfigurowanie czytników w oscam.server

To tutaj dzieje się większość faktycznego dostrajania. Każdy[reader] blok definiuje jedną kartę lub jedno połączenie proxy.

Lokalny czytnik kart chipowych (device, mhz, cardmhz)

[reader]

mhz to częstotliwość taktowania, jakiej OSCam używa do komunikacji ze sprzętem czytnika;cardmhz to częstotliwość taktowania, którą negocjuje z samą kartą. Większość kart działa bez problemu przy standardowej wartości ISO 357/357. Niektóre karty obsługują szybsze odczyty przy 368, 369, a nawet 600 — ale jeśli ustawisz cardmhz na wartość, której karta faktycznie nie obsługuje, otrzymasz pętlę inicjalizacji karty, w której czytnik resetuje się w kółko zamiast ustabilizować się na ATR. Jeśli w logu widzisz powtarzające się błędy „card init” zaraz po restarcie, wróć najpierw do 357/357, upewnij się, że inicjalizacja przebiega czysto, i dopiero potem eksperymentuj z wyższymi wartościami.

Dodawanie czytników proxy cccam/newcamd/gbox

[reader]

Podczas testowania używaj tak jak tutaj adresów IP zastępczych — nigdy nie wpisuj na stałe rzeczywistej nazwy hosta dostawcy w konfiguracji, którą publikujesz publicznie. W przypadku czytników newcamd zamieńprotocol = newcamd i dodajkey = z kluczem DES, a także ustawieniaemmcache , jeśli chcesz buforowania EMM z tego źródła.

Filtrowanie CAID, ident i services dla każdego czytnika

caid = 1802,1801

disablecrccws=1 pomija sprawdzanie CRC dla control word — czasem potrzebne przy wadliwym firmwarze karty, który zwraca zniekształcone, ale poprawne CW, jednak zostaw wartość 0, chyba że masz potwierdzenie, że naprawdę tego potrzebujesz, ponieważ ukrywa to też rzeczywiste uszkodzenia danych.ecmwhitelist ogranicza, jakich PID-ów ECM czytnik w ogóle spróbuje użyć, co zmniejsza liczbę zbędnych żądań na transponderach z wieloma CAID.

Parametry group, fallback i cacheex_maxhop

group to najbardziej błędnie rozumiane ustawienie w całej konfiguracji, więc powiem to wprost: numer group czytnika musi zgadzać się z numerem group użytkownika, aby ten użytkownik w ogóle mógł zobaczyć karty z tego czytnika. Żadnego błędu, żadnego ostrzeżenia — klient po prostu się łączy i nic nie dostaje. Jeśli z tego artykułu masz zapamiętać jedną rzecz, niech będzie to właśnie ta.cacheex_maxhop ogranicza, przez ile skoków może przejść współdzielone CW w Twojej sieci peerów, zanim zostanie odrzucone — więcej na ten temat w następnej sekcji, ponieważ błędne ustawienie tego parametru sprawia, że sieci cache-ex zamieniają się w burze duplikatów CW.

Dostęp klientów i uprawnienia w oscam.user

Definiowanie użytkowników, mapowania grup i AU

[account]

Jeszcze raz —group = 1 musi tutaj odpowiadać grupie czytnika, aby ten użytkownik mógł cokolwiek zobaczyć z tej karty.au (auto-update) powinno wskazywać dokładnie na jedną zaufaną etykietę czytnika i, szczerze mówiąc, tylko jeden klient na kartę powinien mieć włączone AU. Jeśli włączysz AU na tej samej karcie dla dwóch różnych kont klientów, otrzymasz jednoczesne zapisy EMM do karty z dwóch kierunków — to szybki sposób na uszkodzenie wewnętrznego stanu karty lub spowodowanie konfliktów zapisu, które objawiają się losowymi błędami dekodowania kilka dni później.

caidtab, betatunnel i services dla poszczególnych użytkowników

caidtab = 1802:0500,1801:0000

caidtab ogranicza konkretnego użytkownika do określonych CAID, nawet jeśli czytnik, do którego jest przypisany, obsługuje więcej.betatunnel ma znaczenie w środowiskach z mieszanymi CAID — jeśli masz kartę Nagra (1801/1802) i musisz dekodować krzyżowo kanały oznaczone jako Seca, które w rzeczywistości niosą ten sam sygnał, betatunnel przemapowuje CAID w locie, dzięki czemu odbiornik akceptuje CW. Bez tego mieszane konfiguracje Nagra/Seca po prostu po cichu nie dekodują niektórych kanałów, mimo że karta technicznie potrafi wygenerować prawidłowy CW.

Ograniczanie przepustowości za pomocą cccmaxhops i sleep

cccmaxhops = 2

cccmaxhops ogranicza, jak daleko udział CCcam może się rozprzestrzeniać poprzez dalsze udostępnianie w dół — trzymaj tę wartość na 2, chyba że masz konkretny powód, by pozwolić kartom podróżować dalej, ponieważ każdy dodatkowy skok zwiększa opóźnienie i ryzyko obciążenia.sleep rozłącza bezczynnych klientów po N minutach, co zwalnia sloty połączeń na obciążonym serwerze zamiast trzymać martwe sesje.

Zabezpieczanie kont i wyłączanie nieużywanych użytkowników

uniq = 1 uniemożliwia jednoczesne zalogowanie się na to samo konto z dwóch miejsc — ustaw to na każdym koncie, chyba że masz konkretny powód, by tego nie robić, ponieważ współdzielone dane logowania to najczęstszy sposób nadużycia konta. Kont, których obecnie nie używasz, nie usuwaj — ustawenabled = 0 zamiast tego, dzięki czemu zachowasz historię konfiguracji, nie zostawiając otwartych, aktywnych drzwi.

Cache-ex, Peering i strojenie wydajności

To jest część, którą pomija większość poradników, a szczerze mówiąc to właśnie ona stanowi różnicę między dobrą konfiguracją a najlepszą konfiguracją OSCam dla ustawienia z wieloma czytnikami. Cache-ex to mechanizm, który pozwala boksom OSCam współdzielić już zdekodowane control words między sobą, zamiast żeby każdy boks odpytywał własną kartę o to samo ECM.

Wyjaśnienie trybów cacheex 1, 2 i 3

Tryb 1 to tylko cache — czytnik przechowuje CW, które widzi, ale aktywnie ich nie wypycha ani nie pobiera. Tryb 2 wypycha CW na zewnątrz do peerów (ty jesteś źródłem). Tryb 3 pobiera CW od peerów (ty jesteś odbiorcą). Pomyl kierunek, a albo zalejesz peerów CW, o które nie prosili, albo będziesz czekać na czytniku w trybie „pull”, do którego nikt faktycznie nie wypycha danych. Ustawcacheex = 2 na czytnikach reprezentujących karty, które posiadasz i chcesz udostępniać, orazcacheex = 3na czytnikach reprezentujących peerów nadrzędnych, z których korzystasz.

cacheex_maxhop i unikanie pętli cache

Oto tryb awarii, który dopada osoby prowadzące trzech lub więcej peerów: bez rozsądnegocacheex_maxhop, CW może odbijać się między peerem A, B i C wielokrotnie, a każda skrzynka rozgłasza go ponownie, jakby był nowy. To jest sztorm duplikatów CW, który pożera przepustowość i CPU bez żadnej korzyści. Trzymajcacheex_maxhop = 2 jako domyślną wartość i nigdy nie ustawiaj go powyżej 3 w mesh z wieloma peerami, chyba że w pełni kontrolujesz każdą skrzynkę w tym mesh i zweryfikowałeś, że w topologii nie ma pętli.

csp (cache server protocol) i lb_mode balansowanie obciążenia

[csp]

lb_mode = 1 włącza wbudowany balancer obciążenia OSCam na twoich czytnikach, klasyfikując je według historycznego czasu odpowiedzi ECM.lb_nbest_readers kontroluje, ile najlepiej działających czytników jest próbowanych równolegle dla danego ECM — 2 to rozsądna wartość domyślna dla większości konfiguracji z więcej niż jednym realnym źródłem na CAID.lb_reopen_seconds to czas, przez jaki czytnik oznaczony jako zły pozostaje wyłączony z użycia, zanim OSCam da mu kolejną szansę; 900 sekund (15 minut) pozwala uniknąć nękania czytnika, który po prostu ma chwilowo gorszą minutę, jednocześnie ostatecznie go przywracając.

Redukowanie ustawień czasu i interwału ECM

Strona statystyk czytników w interfejsie webowym pokazuje średni czas ECM na czytnik — to twoje prawdziwe narzędzie diagnostyczne, a nie zgadywanie. Jeśli widzisz błędy dekodowania (karta nie zwróciła nic użytecznego) w innej proporcji niż timeouty (nic w ogóle nie wróciło) w zależności od czytnika, to mówi ci różne rzeczy: błędy dekodowania zwykle wskazują na niezgodność CAID/ident lub kartę mającą problemy, timeouty zwykle wskazują na opóźnienia sieciowe lub przeciążonego peera nadrzędnego. Obserwuj tę stronę przez dzień, zanim zaczniesz zmieniać wartości timeoutów na ślepo.

Rozwiązywanie typowych problemów z konfiguracją OSCam

Karta się nie inicjalizuje (błędy mhz / urządzenia)

Jeśli w logu widzisz powtarzające się błędy ATR albo karta resetuje się w pętli, sprawdź najpierw ścieżkędevice — czytnik USB może zmienić się z/dev/ttyUSB0 na/dev/ttyUSB1 po restarcie, jeśli cokolwiek innego na magistrali zmieniło kolejność. Jeśli ścieżka urządzenia jest prawidłowa, zejdź zmhz/cardmhz z powrotem do 357/357 jako testu bazowego.

Klient się łączy, ale żaden kanał się nie dekoduje

W dziewięciu przypadkach na dziesięć to niezgodność grup, o której wspominałem wcześniej — sprawdź linięgroupczytnika (reader) w porównaniu z liniągroupużytkownika. Jeśli się zgadzają, a mimo to nie działa, sprawdź oscam.services — łatwo jest mieć poprawnie ustawione CAID i grupę, podczas gdy wpis w pliku services po cichu wyklucza ident konkretnego kanału, co z perspektywy klienta wygląda identycznie jak problem z grupą, ale nie ma nic wspólnego z uprawnieniami.

Zamrożony obraz i wysokie czasy ECM

To niemal zawszefallbacktimeoutustawiony zbyt agresywnie nisko, co powoduje, że łańcuch czytników miota się między głównym a zapasowym w trakcie transmisji, albo czytnik, który jest rzeczywiście przeciążony przez zbyt wielu jednoczesnych peerów cache-ex pobierających z niego dane. Sprawdź stronę statystyk czytnika pod kątem skoków czasu ECM skorelowanych z godzinami szczytowego użycia.

Odczytywanie logów oscam w celu znalezienia etapu, na którym występuje błąd

Uruchom OSCam na pierwszym planie z pełnym debugowaniem czytnika:oscam -b -r 2. Przeszukaj log pod kątem dwóch konkretnych ciągów —"not found ("mówi, o jaki CAID/ident poprosił klient, którego żaden czytnik nie mógł obsłużyć, a"rejected"mówi, że doszło do blokady na poziomie uwierzytelniania lub grupy, zanim żądanie w ogóle dotarło do czytnika. Same te dwa ciągi wskażą etap, na którym występuje błąd, szybciej niż czytanie całego logu od góry do dołu.

Żadna z tych rzeczy nie jest niczym egzotycznym — chodzi głównie o zrozumienie, co faktycznie robi każdy parametr, zamiast ślepo kopiować konfigurację. Jeśli miałbyś zapamiętać jedną rzecz z tego wszystkiego, to tę, że najlepsza konfiguracja OSCam dla Twojego sprzętu to ta, która pasuje do Twojego rzeczywistego sprzętu i liczby czytników, a nie to, co ktoś wkleił na forum w 2019 roku. Zacznij od powyższych wartości domyślnych, obserwuj przez kilka dni stronę statystyk czytnika i dostosowuj po jednej wartości na raz.