Najlepszy przewodnik po konfiguracji OScam: Optymalne ustawienia 2026

Jeśli masz OScam skompilowany i działający, ale nadal obserwujesz czasy ECM przekraczające 1500 ms, lub kanał zamraża na dwie sekundy za każdym razem, gdy zmieniasz kanał, problem nigdy nie leżał w binarnej wersji. Problemem była konfiguracja. Przez lata odbudowałem więcej plików oscam.conf, niż mogę policzyć, a prawie każde zgłoszenie "jest zepsute" wraca do tej samej garstki źle skonfigurowanych wartości. Ten przewodnik przeprowadza przez najlepszą konfigurację oscam od podstaw — nie jest to plik do skopiowania i wklejenia, ale rzeczywiste uzasadnienie dla każdego parametru, abyś mógł dostosować go do swojego sprzętu i linków.

Co oznacza "najlepsza" konfiguracja OScam

Wyjaśnijmy jedną rzecz od razu. Nie ma jednego pliku, który byłby obiektywnie najlepszą konfiguracją OScam dla każdego. To, co "najlepsze" naprawdę oznacza, to najniższy stabilny czas ECM i najmniej zamrożeń dla twojego konkretnego sprzętu, twojej konkretnej karty lub sąsiadów sieciowych oraz twojego konkretnego odbiornika. Konfiguracja, która jest idealna na Vu+ Duo4K z lokalną kartą, będzie zachowywać się inaczej na Dreamboxie, który pobiera wszystko z czytników sieciowych przez mobilny hotspot.

Dlatego, gdy ludzie szukają najlepszej konfiguracji oscam, to, czego naprawdę potrzebują, to metodologia, a nie link do pobrania. To właśnie daje ci ten przewodnik.

Cztery podstawowe pliki konfiguracyjne i co każdy z nich kontroluje

OScam dzieli swoją konfigurację na cztery pliki, a pomieszanie, co należy gdzie, jest powszechnym źródłem zamieszania dla każdego, kto jest nowy w tym temacie.

• oscam.conf — globalne zachowanie: limity czasowe, logowanie, buforowanie, WebIf i mostek dvbapi do dekodera twojego boxa
• oscam.server — każdy czytnik, do którego się łączysz, niezależnie od tego, czy jest to lokalna karta smart, peer CCcam, czy serwer newcamd
• oscam.user — konta, które mają prawo łączyć się z twoją instancją OScam i pobierać z niej CW
• oscam.dvbapi (lub blok [dvbapi] w oscam.conf, w zależności od wersji) — jak OScam komunikuje się z lokalnym demuxerem do dekodowania na boxie

Błędne skonfigurowanie któregokolwiek z tych plików objawia się gdzie indziej — zły wpis czytnika w oscam.server często wygląda po prostu jak "brak obrazu" na odbiorniku, z niczym oczywiście nieprawidłowym w oscam.conf.

Lokalizacja pliku konfiguracyjnego: /etc/tuxbox/config vs /var/keys

Na odbiornikach Enigma2 zazwyczaj znajdziesz aktywną konfigurację pod/etc/tuxbox/config/oscam/, chociaż wiele obrazów tworzy dowiązania lub montuje to do/var/keys lub/usr/keys w celu zachowania po aktualizacjach. Na samodzielnym boxie Linux, na którym sam zbudowałeś OScam, domyślnie jest to zazwyczaj/usr/local/etc chyba że podałeś inną ścieżkę z flagą-c podczas uruchamiania.

Nie zgaduj. Ścieżka, z której OScam faktycznie odczytuje, jest drukowana na samym początku logu przy uruchamianiu, a także jest wyświetlana w WebIf w sekcji Status. Jeśli edytujesz plik i zmiany nie mają efektu, dziewięć razy na dziesięć edytujesz niewłaściwą kopię.

Dlaczego nie ma jednej uniwersalnej najlepszej konfiguracji

CAID-y różnią się w zależności od dostawcy i satelity. Limity reshare różnią się w zależności od tego, kto dzieli się z tobą. Sprzęt kart różni się — wewnętrzne czytniki zachowują się zupełnie inaczej niż dongle USB Phoenix. Konfiguracja dostosowana do stabilnego połączenia światłowodowego z lokalnym peerem będzie miała problemy z mobilnym uplinkiem 4G. Dlatego WebIf i plik logu są twoimi prawdziwymi narzędziami do dostrajania, a nie wątek na forum. Dostosowujesz jedną wartość, mierzysz efekt, zatrzymujesz to, co działa.

Optymalizowany oscam.conf: Ustawienia globalne, które mają znaczenie

To tutaj odbywa się większość rzeczywistego dostrajania. Poniżej znajduje się blok [global], od którego zaczynam każdą odbudowę, z uzasadnieniem dla każdej linii.

[global] nice, maxlogsize, preferlocalcards i clienttimeout

[global]

nice = -1 podnosi priorytet planowania CPU OScam nieznacznie powyżej domyślnego, co ma znaczenie na niedostatecznie wydajnych boxach ARM, gdzie proces może zostać zablokowany podczas intensywnych skanów EPG.maxlogsize = 100 ogranicza log do 100KB przed rotacją — wystarczająco dużo historii do debugowania, nie tak dużo, aby zjadało twoją pamięć flash.

clienttimeout = 5000 oznacza, że OScam czeka do 5 sekund na odpowiedź CW, zanim całkowicie się podda.fallbacktimeout musi być niższy — używam 2500ms — aby wolny lub martwy czytnik został pominięty na rzecz źródła zapasowego, zanim całe żądanie wygaśnie. Jeśli ustawisz fallbacktimeout równy lub wyższy niż clienttimeout, tracisz cały sens posiadania zapasowego: OScam po prostu czeka na ten sam wolny czytnik.

preferlocalcards = 1 mówi OScam, aby faworyzował bezpośrednio podłączoną kartę inteligentną nad sieciowym rówieśnikiem, gdy obie mogą dekodować ten sam CAID. Jeśli masz lokalną kartę, zawsze to włączaj — to największe skrócenie czasu ECM, które możesz uzyskać za darmo, ponieważ nie ma zaangażowanej podróży przez gniazdo sieciowe.

[cache] i buforowanie cw (podstawy cacheex)

[cache]

Jeśli uruchamiasz odpowiednią konfigurację wymiany buforów CW między wieloma urządzeniami w swojej sieci (tryb cacheex 1, 2 lub 3 w zależności od roli), włącz statystyki, abyś mógł rzeczywiście zobaczyć wskaźniki trafień w WebIf. Bez tego dostrajanie jest na ślepo. Nie będę wchodził w szczegóły topologii cacheex, ponieważ zasługuje na osobny opis, ale krótka wersja: węzeł buforujący, który głównie serwuje przestarzałe lub błędne CW, pogorszy twój czas ECM bardziej niż brak bufora, więc obserwuj statystyki, zanim mu zaufasz.

[webif] na porcie 8888 z httpuser/httppwd i TLS

[webif]użyj tutaj silnego, unikalnego hasła

Port 8888 jest standardowy, ale sprawdź, czy nic innego na twoim urządzeniu nie jest już do niego przypisane — niektóre wtyczki Enigma2, a nawet niektóre demony strumieniowe domyślnie zajmują 8888, a OScam po prostu nie będzie w stanie się związać, jeśli jest zajęty. Zmień go na coś takiego jak 8889, jeśli napotkasz konflikt.

Ustawhttpallowed na zakres swojej sieci LAN, aby WebIf nie był w ogóle dostępny z zewnątrz twojej sieci. Jeśli naprawdę potrzebujesz zdalnego dostępu, włącz TLS i użyj prawdziwych danych uwierzytelniających — nigdy nie zostawiaj httpuser/httppwd pustych na czymkolwiek z publicznie dostępnym portem. Otwarty WebIf przekazuje pełną kontrolę nad czytnikiem i kontem każdemu, kto go znajdzie.

[monitor] i bloki [dvbapi]

[monitor]

au = 1 włącza automatyczne aktualizacje EMM, aby twoje uprawnienia były aktualne bez ręcznej interwencji.pmt_mode = 6 mówi OScam, aby odczytywał PMT za pomocą standardowej metody gniazdowej, której oczekują większość obrazów Enigma2 — jeśli jesteś na innym typie odbiornika, możesz potrzebować pmt_mode 0 lub 1, sprawdź dokumentację swojego obrazu.user powinien wskazywać na konto zdefiniowane w oscam.user, co ma znaczenie dla późniejszego dopasowywania grup.

Jedna uwaga dotycząca logowania: podnieś poziom debugowania za pomocą-d 2 (lub-d 255 dla pełnego strumienia) tylko podczas aktywnego diagnozowania problemu. Pozostawienie szczegółowego debugowania na stałe szybko zapełnia twój log i dodaje niepotrzebne obciążenie I/O na pamięci flash.

oscam.server i oscam.user: Tuning czytnika i klienta

To jest sekcja, w której większość problemów "po prostu nie łączy się" rzeczywiście występuje. Poprawne zdefiniowanie czytnika i konta sprawia, że wszystko, co następuje, działa.

Blok czytnika CCcam: urządzenie, port, klucz, timeout bezczynności

[reader]

inactivitytimeout = 30 przerywa i ponownie łączy gniazdo czytnika, które milczało przez 30 sekund — przydatne do wychwytywania półmartwych połączeń, które wyglądają na "działające", ale tak naprawdę nie przesyłają danych.reconnecttimeout kontroluje, jak długo OScam czeka przed ponownym próbą po przerwaniu.ccckeepalive = 1 wysyła okresowe pakiety keepalive, aby routery NAT i zapory nie zabijały cicho bezczynnego połączenia, co jest bardzo powszechną przyczyną, dla której czytnik działa dobrze przez godzinę, a potem po prostu przestaje.

składnia czytnika newcamd/mgcamd i klucz DES

[reader]

Klucz pole to klucz DES negocjowany z tym konkretnym serwerem newcamd — nie jest wymienny między dostawcami, a błędny klucz powoduje natychmiastowe odrzucenie połączenia, które zobaczysz w dzienniku jako błąd autoryzacji, a nie jako przekroczenie czasu, więc sprawdź to najpierw, jeśli ten czytnik nie działa.grupa, caid, identyfikator i limity reshare

To jest część, której prawie nikt nie wyjaśnia poprawnie, a to jest główny powód większości przypadków "czytnik pokazuje połączenie, ale żaden CW nigdy nie przychodzi". Numery grup istnieją wyłącznie w celu kierowania żądaniami — konto oscam.user z

group = 1 może pobierać tylko z czytników, które również majągroup = 1 (lub grupę, która pokrywa się przez bitmaskę, jeśli używasz wielu grup). Jeśli twoje konto to grupa 1, a twój czytnik to grupa 2, OScam nigdy nie skieruje ECM między nimi, koniec kropka, i nie ma komunikatu o błędzie, który by ci to bezpośrednio powiedział — po prostu cicho nigdy nie znajdzie CW.Ogranicz czytniki według CAID i identyfikatora, gdzie to możliwe:

caid = 0500,1802

To zmniejsza zbędne obciążenie — OScam nie będzie tracić czasu na zapytanie czytnika o CAID, którego nie może odkodować, co skraca rzeczywisty czas wyszukiwania ECM, gdy masz skonfigurowanych kilka czytników.

oscam.user: pwd, dopasowanie grupy, au i monlevel

[account]

Jedno konto na box, zawsze. Udostępnianie danych logowania między wieloma odbiornikami uniemożliwia ustalenie, który box generuje dany ECM w dzienniku, i psuje statystyki per-klient w WebIf.

monlevel = 1 pozwala temu kontu zobaczyć swój własny status połączenia w porcie monitorującym bez pełnej widoczności administratora. Dopasujgroup wartość tutaj do tych czytników, z których naprawdę chcesz, aby ten konkretny box pobierał — to jest dokładne dopasowanie, które ciągle myli ludzi, więc sprawdź to jeszcze raz w oscam.server, zanim zaczniesz szukać gdzie indziej.Lokalne odczyty kart i konfiguracja dekodowania dvbapi

Jeśli masz fizyczną kartę inteligentną w odbiorniku, blok czytnika wygląda zupełnie inaczej niż w przypadku peer'a sieciowego, a wartości specyficzne dla sprzętu mają znacznie większe znaczenie, niż ludzie się spodziewają.

Blok czytnika karty inteligentnej: device = /dev/ttyUSB0 i protokół

[reader]

Dla czytnika kart inteligentnych w stylu USB Phoenix,

protocol = mouse i ścieżka urządzenia jak/dev/ttyUSB0 jest standardem. Jeśli twój odbiornik ma zamiast tego wewnętrzny slot na kartę, zazwyczaj użyjeszprotocol = internal z ścieżką urządzenia jak/dev/sci0 idetect = cd.mhz, cardmhz i ustawienia detect dla stabilnego ATR

To jest ustawienie, które ludzie ciągle mylą. Dla czytnika USB Phoenix,

This is the setting people get wrong constantly. For a USB Phoenix reader, mhz = 357 icardmhz = 357 jest poprawne — to natywna częstotliwość zegara karty. Dla wewnętrznego czytnika w większości sprzętu Enigma2,cardmhz = 2700 to, czego potrzebujesz zamiast tego. Ustawienie błędnej wartości powoduje, że karta albo w ogóle się nie inicjalizuje, albo daje niestabilny ATR, który losowo spada pod obciążeniem, co wygląda dokładnie jak zła karta, nawet gdy sprzęt jest w porządku.

Potwierdź, że to zadziałało, sprawdzając log tuż po uruchomieniu OScam — szukasz linii pokazującej bajty ATR i komunikat o pomyślnej inicjalizacji karty. Jeśli zamiast tego widzisz powtarzające się próby resetu, to znak, że wartości mhz/cardmhz nie pasują do typu twojego czytnika.

oscam.services dla grupowania CAID/dostawcy

Kiedy mieszają się CAID-y — powiedzmy, lokalna karta obsługująca CAID jednego dostawcy i sąsiedzi sieciowi obsługujący inne —oscam.services pozwala na grupowanie kombinacji CAID/dostawca pod nazwanym grupą usług, do której mogą odnosić się zarówno twoje czytniki, jak i twój [dvbapi] sidtab. Bez tego grupowania, dvbapi nie ma czystego sposobu, aby wiedzieć, który czytnik powinien być próbowany dla którego kanału, a kończysz z wolniejszym, mniej przewidywalnym routowaniem ECM w mieszanych konfiguracjach.

sysfs/rozwiązywanie problemów z czytnikiem phoenix

Jeśli czytnik USB Phoenix w ogóle się nie wyświetla, najpierw sprawdź, czy urządzenie faktycznie istnieje:ls -la /dev/ttyUSB0. W niektórych dystrybucjach Linuksa moduł jądra musi być ładowany ręcznie, lub udev przypisuje inny numer ttyUSB, jeśli masz podłączone inne urządzenia szeregowe USB. Nie zakładaj, że to zawsze ttyUSB0 — sprawdźdmesg | tail tuż po podłączeniu czytnika, aby potwierdzić, na którym węźle urządzenia faktycznie wylądował.

Weryfikacja i testowanie konfiguracji

Napisanie konfiguracji to połowa pracy. Drugą połową jest udowodnienie, że to faktycznie działa, a ten krok większość przewodników pomija całkowicie.

Odczytywanie czasu ECM na stronie statusu WebIf

Zaloguj się do WebIf podhttp://your-box-ip:8888 i przejdź do Status. Każdy aktywny klient i czytnik pokazuje kolumnę czasu ECM, aktualizowaną na żywo w miarę przychodzenia żądań. Ta liczba, w milisekundach, jest najważniejszym wskaźnikiem, który masz do oceny, czy twoja konfiguracja oscam jest rzeczywiście dobra, czy tylko wygląda dobrze na papierze.

Interpretacja stanów czytnika: POŁĄCZONY, KARTA, WYŁĄCZONY

Czytnik pokazującyKARTA na zielono oznacza, że lokalna karta inteligentna jest zainicjalizowana i gotowa.POŁĄCZONY na zielono oznacza, że sąsiad sieciowy jest uwierzytelniony i odpowiada. Cokolwiek na czerwono — w tymWYŁĄCZONY — oznacza, że ten czytnik w tej chwili nie dostarcza CW, a każdy klient polegający wyłącznie na nim dla danego CAID-u będzie miał problemy lub przełączy się gdzie indziej, jeśli w ogóle istnieje alternatywa.

Używanie logu (-d 255) do śledzenia żądania ECM od początku do końca

Uruchom OScam z-d 255 tymczasowo i przefiltruj wyjście:

tail -f /tmp/oscam.log | grep -i "ecm\|not found"

Zobaczysz pełny cykl życia żądania — który czytnik był próbowany, ile to trwało i czy zakończyło się sukcesem, czy wróciło "nie znaleziono". CAID, który konsekwentnie zwraca "nie znaleziono" w każdym skonfigurowanym czytniku, oznacza, że żaden z twoich czytników faktycznie nie ma tego uprawnienia, co jest problemem z przydzieleniem, a nie błędem konfiguracji.

Docelowe metryki: czas ECM poniżej 500ms, zero timeoutów

Jako działający benchmark: poniżej 500ms daje ci niemal natychmiastowe przełączanie, które wydaje się nieodróżnialne od niezaszyfrowanego kanału. 500-1000ms jest użyteczne, ale zauważysz opóźnienie przy zmianie kanału. Cokolwiek konsekwentnie powyżej 1000ms spowoduje widoczne zacięcia, szczególnie na kanałach z krótkimi czasami cyklu CW. Testuj jedną zmianę parametru na raz — zamień fallbacktimeout, obserwuj WebIf przez kilka minut, a następnie przejdź do następnej wartości. Zmiana pięciu rzeczy jednocześnie oznacza, że nigdy nie będziesz wiedział, która z nich faktycznie pomogła.

Typowe błędy konfiguracji i co nie działa

Tak samo użyteczne jak wiedza o tym, co działa, jest wiedza o tym, co niezawodnie nie działa, ponieważ te błędy pojawiają się w kółko.

Niedopasowane numery grup między serwerem a użytkownikiem

Omówione powyżej, ale warto powtórzyć, ponieważ to jest numer jeden przyczyny "wszystko wygląda na połączone, ale nic nie dekoduje." Jeśli twój czytnik jest w grupie 4, a twoje konto w grupie 1, nigdy się nie zobaczą, a nie ma wyraźnego błędu — tylko cisza tam, gdzie powinien być CW.

Skopiowane 'najlepsze' konfiguracje z forów, które nie pasują do twojego CAID

Pełny plik oscam.conf pobrany z wątku na forum prawie nigdy nie działa tak, jak jest. CAID, porty i numery grup w tym pliku były dostosowane do czytników kogoś innego i dostawców kogoś innego. Użyj znanego dobrego pliku jako strukturalnego szkieletu w najlepszym przypadku — układ sekcji i ogólny zestaw parametrów — ale każde poświadczenie, port, CAID i wartość grupy muszą być zastąpione twoimi własnymi.

Zbyt wysokie cccmaxhops powodujące pętle i wolne CW

Ustawieniecccmaxhops zbyt wysoko — ludzie czasami ustawiają to na 10 lub więcej, myśląc, że znajdą więcej źródeł — w rzeczywistości robi odwrotnie. Każdy dodatkowy skok dodaje opóźnienie do ścieżki ECM, a wysoka liczba skoków w słabo utrzymanym łańcuchu udostępniania zwiększa ryzyko pętli routingu, które całkowicie zatrzymują żądania. Utrzymuj skoki i głębokość ponownego udostępniania w konserwatywnych granicach; 3-5 to rozsądny sufit dla większości konfiguracji.

Błędne uprawnienia plików i błędy zakończenia linii (CRLF)

Dwie nudne, ale bardzo powszechne awarie. Po pierwsze: edytowanie plików konfiguracyjnych w systemie Windows za pomocą edytora, który nie obsługuje zakończeń linii Unix, wprowadza znaki CRLF, które OScam analizuje w sposób niespójny — czasami cicho, czasami jako uszkodzoną linię. Zawsze zapisuj jako tylko LF, lub edytuj bezpośrednio na urządzeniu za pomocą nano lub vi. Po drugie:chmod 600 twoje pliki konfiguracyjne, ponieważ oscam.server i oscam.user zawierają hasła w postaci tekstu jawnego i nie ma powodu, dla którego inni użytkownicy w systemie powinni mieć możliwość ich odczytu.

I jeszcze jedna rzecz, którą warto powiedzieć bezpośrednio — całkowite wyłączenie clienttimeout lub ustawienie go absurdalnie wysoko nie naprawia zawieszeń. Po prostu je ukrywa, ponieważ teraz OScam czeka tam w nieskończoność na martwego czytnika zamiast szybko zawieść i spróbować alternatywy. Jeśli zawieszenia są twoim problemem, obniż i dostosuj wartości timeout, nie usuwaj ich.