Przewodnik konfiguracji OScam dla Zgemma H9S - Konfiguracja&Dostrajanie

Prawidłowe ustawienie oscam zgemma h9s to jedno z tych zadań, gdzie precyzja się liczy. Źle skonfiguruj, a spędzisz godziny na gonićeniu timeoutów i błędów SID. Zrób to dobrze, a masz stabilne, responsywne ustawienie cardsharing, które faktycznie działa. Przeszedłem wystarczająco wiele nieudanych deploymentów, żeby wiedzieć, co się psuje – i co nie.

Zgemma H9S to zdolny odbiornik, ale nie jest potęgą obliczeniową. Ma ograniczoną RAM, procesor ARM średniej klasy i ograniczenia pamięci masowej, które gryzą, jeśli nie będziesz ostrożny. To oznacza, że sposób konfiguracji oscam zgemma h9s ma tutaj większe znaczenie niż na potężniejszym sprzęcie. Ten przewodnik obejmuje dokładne kroki, pułapki i dostrajanie, które musisz wykonać, aby to zadziałało prawidłowo.

Przegląd sprzętu Zgemma H9S&Kompatybilność OScam

Specyfikacje procesora i RAM

H9S zwykle działa na procesorze opartym na ARM – zazwyczaj wariancie dwurdzeniowym taktowany około 1,5GHz. RAM to prawdziwe ograniczenie: patrzysz na 512MB w większości konfiguracji, czasami rozszerzalne do 1GB w zależności od wersji płyty. Te 512MB brzmią dobrze, dopóki nie zaczniesz ładować dużych list SID i uruchamiać jednocześnie wielu czytników sieciowych.

Gdy OScam się uruchamia, parsuje bazę danych SID do pamięci. Lista z 5000+ SID może zużyć 100-150MB w zależności od tego, jak gęsto je konfigurujesz. Dodaj trzech czytników sieciowych z obsługą timeoutów, aktywne połączenia klientów i rejestrowanie – zużywasz połowę RAM tylko dla OScam. Dla sprzętu H9S w szczególności to ma znaczenie, ponieważ wciąż potrzebujesz miejsca dla głównego systemu operacyjnego odbiornika i wszelkich innych usług.

Obsługiwane typy obrazów i wersje oprogramowania sprzętowego

H9S może uruchamiać wiele typów obrazów, ale obrazy oparte na Enigma2 to gdzie OScam siedzi najnaturalniej. OpenPLi, warianty oparte na Openpli i kompilacje społeczności zwykle zawierają OScam w swoich repozytoriach pakietów. Starsze obrazy – szczególnie te zbudowane przed 2020 rokiem – mogą brakować niezbędnych zależności (wersje libc, biblioteki SSL) dla nowoczesnych binarów OScam.

Zanim cokolwiek zainstalujesz, sprawdź, jaką wersję oprogramowania sprzętowego uruchamiasz. SSH do pudła i sprawdź/etc/issuelub sprawdź nazwę obrazu w menu ustawień. Jeśli twój obraz ma więcej niż trzy lata, prawdopodobnie natrafisz na błędy niezgodności architektury podczas próby instalacji OScam. Sprzęt jest taki sam, ale biblioteki libc i runtime posunęły się naprzód.

Dlaczego H9S dobrze współpracuje z OScam

Pomimo ograniczeń RAM, H9S jest faktycznie solidny dla OScam. Procesor ARM obsługuje żądania ECM wystarczająco szybko do oglądania telewizji w czasie rzeczywistym. Wydajność sieciowa jest przyzwoita dla połączeń czytników – gigabitowy Ethernet oznacza małe opóźnienia dla twoich źródeł cardsharing. Pamięć masowa, choć ograniczona (zwykle 4-8GB), wystarczy dla binarów OScam, konfiguracji i dzienników, jeśli nimi zarządzasz prawidłowo.

Słodki punkt to uruchamianie oscam zgemma h9s z dwoma do trzema czytnikami sieciowymi, 3000-5000 SID i aktywnym buforowaniem. Przekrocz to i uderzyć będziesz w ściany pamięci. Sprzęt nie jest zepsuty na tych limitach – to tylko, że H9S zmusza cię do selektywności w stosunku do tego, co ładujesz.

Ograniczenia sprzętu, o których należy wiedzieć

Wewnętrzny slot CAM jest wart wzmiankowania. Jeśli twój H9S ma wbudowany fizyczny czytnik karty inteligentnej, musisz zdecydować: użyć go z OScam, czy całkowicie go wyłączyć. Pozostawienie go włączonego, ale nieużywanego, po prostu marnotrawi CPU i może powodować konflikty czytników, jeśli nie będziesz ostrożny z konfiguracją. Większość użytkowników w środowiskach, gdzie uruchamialibyś oscam zgemma h9s, używa setup'u tylko sieciowego.

Zapełnianie pamięci masowej to rzeczywisty problem. Partycja /var, gdzie znajdują się dzienniki, czasami jest minuscule (100-200MB). Rejestrowanie OScam, jeśli ustawione na poziomie DEBUG, może to zapełnić w godziny. Będziesz potrzebować rotacji dzienników lub limitów rozmiaru w oscam.conf. W przeciwnym razie zobaczysz, że OScam się zawala bez wyraźnego powodu – system plików pełny, nie można pisać dzienników, proces umiera.

Throttling CPU na H9S zachodzi pod ciągłym obciążeniem. To nie jest przełomowe, ale jeśli uruchamiasz wiele jednoczesnych żądań ECM (dziesiątki użytkowników bombardujących pudło), zobaczysz, że czas odpowiedzi rośnie. Bufforowanie pomaga tutaj – więcej trafiów cache'u oznacza mniej pośrednich żądań ECM do twoich czytników.

Instalacja OScam na Zgemma H9S krok po kroku

Warunki wstępne i wymagane narzędzia

Potrzebujesz dostępu SSH do twojego H9S. To jest nie do negocjacji. Jeśli SSH nie jest włączony w ustawieniach, włącz to teraz – Ustawienia sieciowe → Serwer SSH. Domyślne poświadczenia to zwyklerootz hasłemdreambox, ale sprawdź dokumentację twojego obrazu, ponieważ niektóre kompilacje to zmieniają.

Musisz również wiedzieć, który menedżer pakietów używa twój obraz. Obrazy oparte na OpenPLi używająopkg. Niektóre inne kompilacje Enigma2 używająapt. Sprawdź, SSH'ując i uruchamiającopkg --versionlubapt-get --version. Jeśli nic nie działa, twój obraz jest za stary – będziesz musiał flashować nowszy.

Na koniec, sprawdź miejsce na dysku. Uruchomdf -h /i sprawdź, czy /root lub /home mają co najmniej 20MB wolnego. Jeśli jesteś mały, oczyść stare dzienniki lub pliki tymczasowe.

Dostęp SSH i przygotowanie systemu plików

SSH z twoimi poświadczeniami. Po zalogowaniu utwórz katalogi OScam, jeśli nie istnieją. Dla większości obrazów Enigma2 uruchamiających oscam zgemma h9s, standardowe ścieżki to:

mkdir -p /etc/oscam

Ustaw własność i uprawnienia, aby OScam mógł pisać do tych katalogów:

chown -R root:root /etc/oscam

Sprawdź, czy katalogi istnieją, uruchamiającls -la /etc/oscam/. Powinieneś zobaczyć pusty katalog gotowy do plików konfiguracyjnych.

Pobieranie i instalacja binarów OScam

Najłatwiejsza metoda to za pośrednictwem menedżera pakietów twojego obrazu. Spróbuj najpierw zainstalować z repozytorium:

opkg update

Jeśli to się powiedzie, OScam jest instalowany do ścieżki binarnej systemu (zwykle/usr/bin/oscamlub/usr/local/bin/oscam). Sprawdź za pomocąwhich oscam.

Jeśli pakiet nie jest dostępny w twoim repozytorium, będziesz musiał pobrać binarny ręcznie. Odwiedź oficjalne repozytorium projektu OScam i pobierz binarny ARM pasujący do architektury twojego H9S. Rozpakuj go i umieść w/usr/local/bin/oscam. Uczyń go wykonywalnym:

chmod +x /usr/local/bin/oscam

Przetestuj binarny, uruchamiając/usr/local/bin/oscam -h. Jeśli widzisz tekst pomocy, binarny jest kompatybilny. Jeśli otrzymasz „command not found" lub „cannot execute", masz niezgodność architektury – binarny został skompilowany dla innego wariantu ARM. Reflashuj z nowszym obrazem i spróbuj ponownie.

Weryfikacja instalacji i sprawdzenie dzienników systemu

Przed uruchomieniem OScam sprawdź, czy jakieś poprzednie instancje wciąż działają. Wiele pozostałych procesów powoduje konflikty portów, które są szalone do debugowania:

ps aux | grep oscam

Jeśli zobaczysz procesy OScam na liście, je zabij:

killall -9 oscam

Teraz uruchom OScam ręcznie, aby złapać wszelkie bezpośrednie błędy:

/usr/local/bin/oscam -c /etc/oscam

Sprawdź dzienniki systemu pod kątem komunikatów uruchomieniowych:

tail -f /var/log/messages

Powinieneś zobaczyć OScam inicjujący, wiążący się z portami i ładujący pliki konfiguracyjne. Jeśli natychmiast się zamyka, sprawdź/var/log/oscam.logpod kątem szczegółów błędów. Typowe błędy uruchomieniowe: brakujące pliki konfiguracyjne (oscam.server nie znaleziony), port już w użyciu (inna usługa uruchomiona na 988), lub błędy uprawnień (nie można pisać do /var/oscam).

Ustawianie prawidłowych uprawnień do plików

OScam musi czytać konfiguracje i pisać dzienniki. Po umieszczeniu plików konfiguracyjnych sprawdź uprawnienia:

chmod 644 /etc/oscam/oscam.conf

Jeśli OScam działa jako root (co zwykle robi na H9S), uprawnienia do plików są mniej krytyczne, ale ustawienie ich prawidłowo zapobiega przyszłym problemom, jeśli kiedykolwiek zmienisz użytkownika usługi. Pliki dzienników powinny być czytelne:

chmod 644 /var/log/oscam.log

Przetestuj, uruchamiającoscam -c /etc/oscamponownie. Jeśli uruchomi się czysty i zostanie uruchomiony przez 30 sekund bez wychodzenia, uprawnienia są prawdopodobnie prawidłowe.

Pliki konfiguracyjne OScam dla H9S – Podstawowe ustawienie

oscam.conf – Ustawienia portu serwera i protokołu

Główny plik konfiguracyjny to/etc/oscam/oscam.conf. Oto działająca linia bazowa dla H9S:

[global]

Port 988 jest standardowym portem dla nasłuchiwania protokołu CCcam. To jest gdzie zdalny czytnik i klienci łączą się z twoim H9S. Jeśli coś innego wykorzystuje port 988, zmień go – ale upewnij się, że twoi czytniki znają nowy port.

Klucz to twój klucz klastra – 32-bajtowy ciąg hex. Ten powyżej jest przykładem i niezabezpieczony. Wygeneruj prawdziwy lub zostaw go pusty, jeśli używasz wyłącznie protokołu newcamd. Katalog cache przechowuje cache ECM – kluczowy dla wydajności H9S. Ustaw go na /var/oscam, który utworzyłeś wcześniej.

Maxlogsize ogranicza rozmiar pliku dziennika w megabajtach. Na H9S z małą partycją /var, ustawienie go na 1024MB jest rozsądne. OScam będzie obraca dzienniki, gdy przekroczą ten rozmiar, zapobiegając zapełnieniu systemu plików.

oscam.server – Konfiguracja czytników i filtrowanie SID

Ten plik definiuje twoich czytników – źródła, które dostarczają klucze ECM. Oto szablon z dwoma czytnikami sieciowymi:

[reader]

Zastąp remote_ip i remote_port rzeczywistymi adresami czytników. Pole priority jest krytyczne: niższe numery są próbowane w pierwszej kolejności. Jeśli reader_primary jest powolny lub wyłączony, OScam pada do reader_backup (priority 2).

Numery grupy utrzymują czytniki zorganizowane. Ta sama grupa oznacza, że są oni parami do równoważenia obciążenia. Różne grupy oznaczają hierarchię. Dla H9S z ograniczonymi połączeniami, używanie dwóch grup (główny i zapasowy) jest czysty i prosty.

CAID (Conditional Access ID) filtruje, które standardy szyfrowania czytnik obsługuje. Wspólne CAID: 0100 (Seca), 0500 (Viaccess), 1700 (NDS), 1801 (Nagravision). Wypisz te, które twoji czytniki faktycznie dostarczają. Jeśli wymienisz CAID, które czytnik nie ma, zobaczysz błędy timeout, gdy OScam będzie żądać klucze dla tych CAID.

Timeout jest w sekundach. Na H9S, powolne czytniki przez zagęszczoną sieć mogą potrzebować timeoutów 8-10 sekund. Szybsze, lokalne czytniki mogą używać 4-5 sekund. Jeśli timeout są zbyt krótkie, zobaczysz błędy „CW not found". Zbyt długo i twoje doświadczenie TV będzie się czuć lenią.

Do filtrowania SID, dodaj to do oscam.server:

[reader]

Pole sids ogranicza, które SID ten czytnik dostarcza. Bez niego, czytnik jest proszony o wszystkie SID, które zna. Na H9S, zawężenie tego na czytnika jest inteligentne – zmniejsza to ruch ECM i przyspieszaśmy czasy odpowiedzi. Jeśli reader_primary obsługuje tylko kanały HBO (określone SID), wyświetl tylko te.

oscam.user – Kontrola dostępu klienta

Zdefiniuj, którzy klienci mogą się łączyć z twoim oscam zgemma h9s pudłem. Utwórz/etc/oscam/oscam.user:

[account]

Pole group udziela dostępu do czytników w tych grupach. Client1 może używać czytników z grup 1 i 2. Client2 ma dostęp tylko do czytników z grupy 1. Uniq = 0 oznacza, że ten sam klient może zalogować się z wielu adresów IP. Uniq = 1 wymusza jedno połączenie na klienta – przydatne, jeśli chcesz zapobiec współdzieleniu poświadczeń.

Zmień hasła. Nie używaj symboli zastępczych w produkcji. Jeśli to osobista konfiguracja H9S, nawet podstawowa ochrona jest dobra. Jeśli dzielisz dostęp, silne unikatowe hasła na użytkownika zapobiegają wypadkom.

oscam.srvid – Mapowania identyfikatora usługi

Ten plik mapuje SID na czytelne dla człowieka nazwy kanałów i informacje CAID. Jest opcjonalny, ale pomocny do debugowania. Utwórz/etc/oscam/oscam.srvid:

0100:0001:HBO East

Format to CAID:SID:nazwa. Kiedy sprawdzisz dzienniki lub interfejs sieciowy, zobaczysz „HBO East" zamiast „0100:0001". Na H9S, jest to głównie kosmetyczne, ale oszczędza czas w rozwiązywaniu problemów. Możesz wygenerować ten plik z listy kanałów twojego obrazu, jeśli jest dostępna.

Numery portów i konfiguracja bezpieczeństwa

Port 988 (CCcam) jest standardem. Protokół Newcamd używa portów w zakresie 1024-1030. Jeśli obraz H9S już wykorzystuje te porty dla czegoś innego, otrzymasz błędy „Address already in use".

Sprawdź konflikty:

netstat -tlnp | grep LISTEN

Jeśli port 988 jest wymieniony, zmień port nasłuchu OScam w oscam.conf na coś innego (np. 989). Upewnij się, że zdalni czytniki i klienci znają nowy port.

Bezpieczeństwo: Nie odsłaniaj OScam bezpośrednio do Internetu bez zapory. Użyj iptables, aby ograniczyć połączenia, lub uruchom OScam tylko na sieci LAN. Jeśli musisz go odsłonić, użyj silnych haseł i rozważ whitelist IP w zaporze lub routerze.

Wybór protokołu (CCcam vs. Newcamd vs. Radegast)

Protokół CCcam jest najbardziej rozpowszechniony do łączenia się ze zdalnymi czytnikami. Jest wydajny i szeroko wspierany. Użyj go, chyba że masz konkretny powód, żeby nie.

Newcamd jest starszy, ale wciąż niezawodny. Niektóre starsze czytniki go tylko obsługują. Jeśli twój czytnik mówi „tylko newcamd", skonfiguruj czytnik protokołu newcamd i określ port w zakresie 1024-1030 w oscam.server.

Radegast jest mniej rozpowszechniony. Niektórzy wyspecjalizowani dostawcy go używają, ale jeśli zaczynasz z oscam zgemma h9s, trzymaj się CCcam lub newcamd. Konfiguracja Radegast jest bardziej kapryśna i wolniejsza na sprzęcie H9S.

Rozwiązywanie problemów&Dostrajanie wydajności dla Zgemma H9S

OScam nie uruchamia się – wspólne kody błędów i naprawy

Uruchom OScam na pierwszym planie, aby natychmiast zobaczyć błędy:

/usr/local/bin/oscam -c /etc/oscam

Słuchaj wyników. Typowe niepowodzenia:

„Address already in use":Inny proces posiada port 988. Sprawdź za pomocąnetstat -tlnp | grep 988i zabij konfliktujący proces. Czasami stare instancje OScam się nie czyszczą. Zabij wszystko za pomocąkillall -9 oscam, a następnie uruchom ponownie.

„Config file not found":oscam.conf lub oscam.server brakuje. Sprawdź, czy pliki istnieją:ls -la /etc/oscam/. Jeśli jest pusty, skopiuj lub odtwórz je z przykładów.

„Cannot bind to socket":Błąd uprawnień lub port poniżej 1024 bez root. Upewnij się, że działasz jako root:whoamipowinien wydrukować „root". Jeśli uruchamiasz jako użytkownik usługi, dodaj tego użytkownika do sudoers lub uruchom OScam jako root.

„libc not found":Niezgodność architektury binarnej. Pobierz prawidłowy binarny ARM dla wariantu H9S. Sprawdź szczegóły twojego obrazu:cat /etc/issuepowinien powiedzieć, czy jest to ARMv6, ARMv7 czy ARMv8.

Wysokie użycie CPU/pamięci na ograniczonym sprzęcie H9S

Monitoruj użycie zasobów za pomocą:

top -n1 | head -20

Lub dla ciągłego monitorowania:

htop

Jeśli OScam konsekwentnie zużywa 70%+ CPU, jesteś przeciążony. Przyczyny: zbyt wielu aktywnych klientów, lista SID zbyt duża, lub czytnik wiszący (nie reaguje na żądania).

Zmniejsz obciążenie poprzez:

• Zmniejsz listę SID.Zachowaj tylko SID, które faktycznie oglądasz. Usuń stare lub nieużywane kanały. Lista 3000 SID zużywa mniej więcej 150MB. Skaluj odpowiednio.
• Zwiększ wartości timeout.Jeśli OScam stale ponawia próby powolnych czytników, podnieś timeout w oscam.server. Timeout 5 sekund oznacza, że OScam próbuje 12 razy na minutę na żądanie. Ustaw go na 8-10 sekund, aby zmniejszyć burze ponownych prób.
• Ogranicz maksymalne żądania ECM.Dodaj do oscam.conf:max_pending_ecm = 100. To limituje jednoczesne żądania, zapobiegając bezkontrolnym powodzią ECM.
• Włącz buforowanie ECM.OScam cache'uje odpowiedzi ECM w /var/oscam. Upewnij się, że ten katalog ma miejsce. Trafienie cache'u unika żądania sieciowego – krytyczne na H9S.
• Wyłącz nieużywane funkcje.Jeśli nie używasz interfejsu sieciowego, skomentuj [webif] w oscam.conf. Każda wyłączona funkcja oszczędza RAM.

Jeśli pamięć jest maksymalnie (polecenie free pokazuje mało dostępne), OScam może się zapaść z braku pamięci. Sprawdź syslog na wiadomości OOM killer:tail /var/log/messages | grep OOM. Jeśli znalezione, musisz zmniejszyć rozmiar listy SID lub liczbę czytników.

Powolne czasy odpowiedzi ECM i optymalizacja buforowania

Czas odpowiedzi ECM to jak szybko otrzymujesz klucze podczas dostrajania kanału. Na H9S, zdrowy czas odpowiedzi ECM to poniżej 300ms. Powyżej 500ms czuje się lenią.

Sprawdź oscam.log pod kątem timingów ECM:

grep "ECM" /var/log/oscam.log | tail -20

Szukaj wpisów takich jak „ECM from reader_primary in 125ms". Jeśli większość jest powolna (500ms+), twoi czytniki są przeciążeni lub daleko (wysokie opóźnienie).

Stosunek trafień cache'u to twój najlepszy przyjaciel. Uruchom:

grep "cache hit" /var/log/oscam.log | wc -l

Porównaj z całkowitymi żądaniami ECM. Wysoki stosunek trafiania (70%+) oznacza, że otrzymujesz klucze z lokalnego cache'u, nie z pośrednimi sieciowymi. To jest gdzie wydajność H9S się sprawdza.

Aby poprawić trafienia cache'u:

• Dostroić timeout cache'u ECM. W oscam.conf, dodajecmcache = 30(30 sekund). Klucze są cache'owane przez ten czas. Krótsze oznacza świeże klucze, ale więcej misses. Dłuższe oznacza stare klucze, ale lepsze trafienia cache'u. 20-30 sekund to dobry balans.
• Obserwuj popularne kanały. Kanały, które często dostrajasz, powinny się cache'ować dobrze. Rzadko oglądane kanały będą miały niskie wskaźniki trafiania cache'u – to jest normalne.
• Monitoruj rozmiar cache'u. Sprawdźls -lah /var/oscam/. Jeśli pliki cache'u rosną w rozmiarze, ruch ECM jest wysoki. To jest znak, że twoji czytniki lub lista SID są dobrze dostrojeni.

Problemy łączności sieciowej – czytnik niedostępny

Jeśli czytnik przestaje reagować, OScam ponawia próby do timeout. Podczas tego okna (domyślnie 5-10 sekund), kanały na tym czytniku się odbijają lub zamrażają. Dzienniki pokazują „reader not responding".

Diagnozuj:

ping remote_ip

Jeśli ping się nie powiedzie, łączność sieciowa jest zerwana. Sprawdź router, zaporę, DNS. Jeśli ping działa, ale OScam nie może dotrzeć do portu czytnika:

telnet remote_ip remote_port

Jeśli telnet się zawiesza lub odmawia, port jest zamknięty lub chroniony zaporą. Sprawdź reguły zapory czytnnika – może to wymagać twojego adresu IP H9S na białej liście.

Jeśli łączność jest sporadyczna, dodaj keepalive. W oscam.server, dodaj do bloku czytnika:

keepalive = 1

To wysyła okresowe pingi, aby utrzymać połączenie żywe. Pomocne dla czytników, które usuwają bezczynne połączenia.

Jeśli czytnik jest

SID Not Working or Bouncing Channels

A "bouncing" channel is one that constantly switches between encrypted and decrypted, or freezes intermittently. Usually means OScam can't get a valid CW (control word/key) consistently.

Check oscam.log for the SID:

grep "0100:0001" /var/log/oscam.log | tail -50

Look for "CW not found", "no reader", or "timeout" messages. If the SID is listed in multiple readers, there may be a conflict. OScam tries readers in priority order. If the high-priority reader doesn't have the SID, it should fall back to the backup reader—but sometimes this fails if the reader didn't advertise the SID properly.

Fix:

• Verify the SID exists. Check if channels using that SID are actually broadcast. Removed channels have dead SIDs.
• Check reader group assignments. Ensure both readers with the SID are accessible to the client trying to watch.
• Add sids filtering. If reader_primary handles the SID, add sids = 0100:0001 to that reader block in oscam.server. This tells OScam not to ask other readers for it.
• Review logs for "CW error" or "bad CW". If keys are invalid, the reader has a problem—not OScam.

Log Analysis—Where to Look for Problems

OScam logs everything to /var/log/oscam.log. With verbose logging, it's massive—rotation is mandatory or your disk fills.

Key search patterns:

tail -f /var/log/oscam.log | grep -i "error"

Watch for errors in real-time. Startup errors, reader connection failures, and CW errors appear here.

grep "reader" /var/log/oscam.log | grep -i "timeout"

This shows readers that are timing out. If consistent, the reader is slow or unreachable.

grep "ECM" /var/log/oscam.log | grep -i "timeout"

ECM timeouts mean OScam waited the full timeout window without getting a key. Causes: reader overloaded, network latency, or reader doesn't have the SID.

grep "accepted\|connection" /var/log/oscam.log | wc -l

Count active connections. If this number grows without bound, you have a client connection leak—clients not disconnecting cleanly.

For sustained troubleshooting, set log level to INFO in oscam.conf:

[global]
logfile = /var/log/oscam.log
loglevel = 1

This reduces noise compared to DEBUG level. You still see important events without log spam.

Restart and Cleanup Procedures

To restart OScam gracefully, first kill the process:

killall oscam

Wait a few seconds, then restart:

/usr/local/bin/oscam -c /etc/oscam -d

The -d flag daemonizes (runs in background). Check it started:

ps aux | grep oscam

If you see an oscam process, it's running. Check logs:

tail /var/log/oscam.log

Should see "OScam started" or similar.

For automated restarts, create a cron job. If OScam tends to hang after hours, restart it nightly:

0 2 * * * killall oscam 2>/dev/null; sleep 2; /usr/local/bin/oscam -c /etc/oscam -d

Add this to root's crontab: crontab -e, paste the line, save. This restarts OScam at 2 AM every night.

To clean up old logs, use logrotate. Create /etc/logrotate.d/oscam:

/var/log/oscam.log { daily rotate 7 compress delaycompress notifempty missingok
}

This rotates logs daily, keeps 7 days of backups, and compresses old logs. OScam won't fill your disk.

Advanced: Multiple Readers & Load Balancing

Configuring Multiple Network Readers

Running three or more readers on H9S is possible but requires careful setup. Each reader consumes connection slots and memory. On limited hardware, more readers doesn't always mean better performance—diminishing returns kick in fast.

Here's a three-reader setup:

[reader]
label = primary
protocol = cccam
device = ip1,port1
username = user1
password = pass1
group = 1
priority = 1
timeout = 5
caid = 0100,0500
[reader]
label = secondary
protocol = cccam
device = ip2,port2
username = user2
password = pass2
group = 2
priority = 2
timeout = 8
caid = 0100,1700
[reader]
label = fallback
protocol = cccam
device = ip3,port3
username = user3
password = pass3
group = 3
priority = 3
timeout = 10
caid = 0500,1700

Each reader handles different CAIDs and has escalating timeouts. Primary (priority 1) is tried first. If it fails, secondary (priority 2) takes over. Fallback (priority 3) is a last resort—useful but slow.

Assign SIDs to specific readers to distribute load. If primary has HBO SIDs and secondary has Sky SIDs, OScam doesn't ask primary for Sky keys. This reduces cross-reader traffic and speeds up responses.

Priority and Fallback Settings

Priority controls which reader OScam asks first. Lower numbers = higher priority. For a given SID, OScam tries priority 1 first. If that times out, it tries priority 2, then 3.

Timeout is crucial here. If your primary reader consistently responds in 100ms, set timeout to 1-2 seconds. OScam will quickly determine it's not responding and try the next reader. Too long (10 seconds) and users experience lag while OScam waits.

For oscam zgemma h9s specifically, the priority mechanism is stable and works well. The challenge is matching timeout values to real network conditions. Start conservative: primary timeout = 3 seconds, secondary = 6 seconds, fallback = 10 seconds. Then monitor logs and adjust based on actual response times.

Add this to primary reader if it tends to be slow:

ignore_bad_cw = 1

This tells OScam to ignore occasionally bad keys from that reader. Helps when a reader has intermittent quality issues—OScam accepts most keys but filters obvious corruption.

SID Load Balancing Strategies

Two approaches: exclusive and shared SIDs.

Exclusive: Each SID is owned by one reader. In oscam.server, assign sids per reader. Primary handles SIDs 0001-0100, secondary handles 0101-0200. OScam never asks primary for a SID owned by secondary. This is the most efficient on H9S because it eliminates cross-reader queries.

Shared: Multiple readers can provide the same SID. OScam tries them in priority order. If primary fails, it asks secondary. This is more resilient if readers are flaky, but it costs more traffic and CPU. Avoid this on H9S unless readers are frequently unavailable.

For a balanced H9S setup with two readers, go exclusive:

[reader]
label = primary
sids = 0001,0002,0003,...,1000
[reader]
label = secondary
sids = 1001,1002,...,2000

Every SID is covered. OScam asks exactly one reader per request. Fast and lean.

Handling Reader Timeouts and Failover

When a reader times out repeatedly, OScam eventually marks it offline. During that window, failover to the next reader. The transition isn't instant—there's a timeout delay—but it works.

To test failover, simulate a reader outage:

iptables -A OUTPUT -d remote_ip -j DROP

This blocks traffic to the reader. OScam detects timeout, tries the backup reader, and channels should continue playing (with brief lag). Once you see failover working, undo the rule:

iptables -D OUTPUT -d remote_ip -j DROP

If failover doesn't work, check logs for fallback reader errors. Maybe it's not configured with the same SID. Add missing SIDs to the fallback reader block and restart OScam.

For production stability on H9S, keep timeouts reasonable (5-10 seconds) so failover happens before users notice. Overly short timeouts cause false positives—good readers get skipped due to network jitter.

Monitoring Reader Health

Check which readers are active via the web interface (port 8888 if enabled) or by scanning logs:

grep "reader" /var/log/oscam.log | grep -i "online\|offline" | tail -20

For continuous health monitoring, track response times:

grep "ECM from" /var/log/oscam.log | tail -100 | awk '{print $NF}' | sort -n

This shows ECM response times for the last 100 requests. If most are under 300ms, readers are healthy. If many exceed 1000ms, readers are overloaded or distant.

On H9S, automate this check with a cron job that restarts OScam if a reader hasn't updated in 10 minutes. Over-automation can cause instability, so use sparingly. A nightly restart is safer than minute-by-minute health checks.

FAQ Section