Najlepszy serwer CCcam: Jak ocenić i wybrać mądrze

Znalezienie najlepszego serwera cccam to nie o wyborze najtańszego planu lub zaufaniu kopii promocyjnej dostawcy — chodzi o znajomość sygnałów technicznych, na które należy zwrócić uwagę, zanim wydasz jakiekolwiek pieniądze. Widziałem, jak ludzie spalają trzy lub cztery dostawców w ciągu miesiąca, ponieważ nie mieli ram do oceny tego, co faktycznie otrzymywali. Ten przewodnik to naprawia. Omówimy progi opóźnień, liczbę przeskoków, zgodność wersji protokołu, konfigurację pliku konfiguracyjnego i jak złapać złego dostawcę, zanim zmarnują Twój czas.

Jeśli już wiesz, czym jest CCcam i masz odbiornik z systemem Enigma2 lub softcam taki jak OScam, ten przewodnik został napisany dla Ciebie. Pomijamy podstawy i przechodzimy bezpośrednio do kryteriów technicznych, które faktycznie oddzielają solidny serwer od przepełnionego bałaganu.

Co faktycznie sprawia, że serwer CCcam jest „dobry" — kryteria techniczne

Większość ludzi ocenia serwery na podstawie ceny i rekomendacji na forum. To straszna metoda. Rzeczywiste wskaźniki są mierzalne: opóźnienie ping, liczba przeskoków, obsługa wersji protokołu, rzeczywisty czas dostępności (nie czas dostępności pulpitu) i obsługa jednoczesnych połączeń. Przejdźmy przez każdy z nich.

Ping i opóźnienie: jakie liczby faktycznie mają znaczenie

Poniżej 80ms czasu okrężnego do serwera to generalnie miejsce, gdzie chcesz być, aby zapewnić niezawodne deszyfrowanie ECM. Między 80–150ms zaczniesz zauważać sporadyczne zawieszenia, szczególnie na kanałach sportowych z szybkimi czasami cyklu ECM (niektóre szyfrują co 10 sekund). Powyżej 150ms, ryzykujesz.

Sam ping to jednak nie cała historia. Serwer siedzi przy 40ms średnio z okazjonalnymi skokami 300ms gorszy niż ten siedzi stabilnie na 70ms. Użyj czegoś takiego jak ping -c 100 hostname i spójrz na wartości maksymalne i odchylenie standardowe, a nie tylko średnią. Jitter zabija deszyfrowanie bardziej niezawodnie niż płaskie wysokie opóźnienie.

Liczba przeskoków karty i dlaczego niższe jest lepsze

Liczba przeskoków to ile etapów przekaźnika istnieje między Tobą a fizyczną kartą inteligentną. Zero przeskoków oznacza kartę bezpośrednią — serwer, z którym się łączysz, ma kartę fizycznie włożoną. Jeden przeskok jest akceptowalny. Dwa przeskoki mogą zadziałać, ale zauważysz to na zajętych kanałach.

Trzy lub więcej przeskoków to miejsce, gdzie robi się źle. Każde przekaźnienie dodaje opóźnienie i punkt awarii. Na szybkim cyklu ECM, takim jak Sky Sports lub podobny zaszyfrowany kanał na żywo, łańcuch 3-hopowy może popchać Twój czas odpowiedzi ECM poza deadline deszyfrowania, powodując zawieszenie, nawet jeśli karta technicznie odpowiedziała. Ekran informacyjny CCcam na Twoim odbiorнiku pokazuje liczbę przeskoków na kartę — zawsze to sprawdzaj.

Czas dostępności serwera i jak go niezależnie weryfikować

Nigdy nie ufaj pulpitowi czasu dostępności dostawcy. Są one albo самogłoszone, albo mierzą tylko frontend. To, co chcesz wiedzieć, to czy port faktycznie akceptuje połączenia 24/7, szczególnie podczas godzin szczytu wieczornego.

Skonfiguruj swoją własną kontrolę. Prosty cron job uruchamiany co 5 minut działa dobrze:

```html
e>*/5 * * * * nc -zw3 hostname 12000 >> /var/log/cccam_uptime.log 2>&1

Zaloguj dane wyjściowe wraz ze znacznikami czasu i przejrzyj je po tygodniu. Zobaczysz wzorce — jeśli spadnie każdego wieczoru między 20:00 a 22:00, to oversold serwer, a nie "chwilowy problem", jak na pewno powie Ci wsparcie.

Obsługiwane wersje protokołu: Różnice CCcam 2.0, 2.1, 2.2, 2.3

CCcam przeszedł przez kilka wersji protokołu i negocjacja handshake'a ma znaczenie. Wersje 2.0 i 2.1 są starsze i mają ograniczenia dotyczące obsługi listy udziałów i zaszyfrowanej komunikacji. Wersja 2.2.x wprowadził lepsze filtrowanie udziałów. Wersja 2.3 dodała dodatkowe ulepszenia stabilności, ale nie jest powszechnie obsługiwana na starszych odbiornikach.

Problem: niektóre odbiorniki mają wersję protokołu zakodowaną w swoim oprogramowaniu sprzętowym i będą dyskretnie nie połączeć się, jeśli serwer wymusza minimalną wersję, która się nie zgadza. Nie ma żadnego komunikatu o błędzie — softcam po prostu nic nie zdekoduje. Jeśli korzystasz ze starszego sprzętu Dreambox lub niedrogiego odbiornika, potwierdź, którą wersję CCcam negocjuje Twoje oprogramowanie sprzętowe, zanim założysz, że serwer jest uszkodzony.

Limity jednoczesnych połączeń i ich wpływ

"Nieograniczone połączenia" to fikcja marketingowa. Każda karta backend ma limit fizyczny — jedna karta może zdekodować jeden ECM na raz. To, co "nieograniczone" naprawdę oznacza, to że dostawca nie ogranicza Twoje połączenia klientów na swoim frontendzie, ale backend będzie nadal kolejkować lub usuwać żądania pod obciążeniem.

Jeśli korzystasz z konfiguracji duального tunera i jednocześnie oglądasz dwa zaszyfrowane kanały, pojedyncza C-line z jednym gniazdem połączenia zakończy się niepowodzeniem. Potrzebujesz albo wielu C-lines, albo OScam skonfigurowany z sesją współbieżnych czytników. Więcej na ten temat w sekcji konfiguracji.

Czytanie i testowanie linii CCcam przed zapłatą

C-line to cały zestaw poświadczeń do połączenia z serwerem CCcam. Zrozumienie jego formatu pozwala natychmiast dostrzec problemy — zła porta, brakujące opcje lub nazwa hosta, która nie jest rozwiązywana.

Anatomia linii CCcam C-Line: Host, Port, Nazwa użytkownika, Hasło

Format jest prosty:

C: <hostname> <port> <username> <password> <options>

Rzeczywisty przykład struktury:

C: server.example.com 12000 myuser mypassword yes

Ostatnie pole (tak/nie) kontroluje, czy udostępniasz karty z powrotem serwerowi. W przypadku większości konfiguracji klienta powinno to być nie, chyba że jawnie konfigurasz wymianę udziałów. Wspólne porty to 12000, 12001, 15000, 16000 i 17000. Jeśli Twój dostawca usług internetowych blokuje wychodzące TCP na tych portach — co niektórzy robią — połączenie będzie wyglądać na martwe, nawet jeśli serwer jest w dobrej kondycji. Poproś dostawcę o alternatywny port lub sprawdź, czy obsługują port 443 lub 80 jako rezerwę.

Jak przetestować linię CCcam za pomocą bezpłatnego okresu próbnego

Każdy godny zaufania dostawca da Ci linię testową na 24–48 godzin. Odmów ```płacić z góry bez jednego — to samo odfiltrowuje ogromną część śmieciowych dostawców. Podczas testu nie sprawdzaj tylko o 3 rano, gdy obciążenie jest minimalne. Testuj w godzinach szczytu (19:00–22:00 czasu lokalnego) na kanałach z szybkimi cyklami ECM. To tam źli serwery się walą.

Sprawdź listę udziałów natychmiast po połączeniu. Jeśli lista udziałów ładuje się dłużej niż 30 sekund, to wolny serwer. Jeśli lista udziałów pokazuje karty z hop count 3+, to operacja resharing, a nie bezpośrednia karta.

Używanie OScam jako klienta CCcam do weryfikacji odpowiedzi serwera

WebIf OScam daje ci znacznie lepsze informacje diagnostyczne niż natywny plik binarny CCcam. Gdy skonfigurujesz czytnik OScam wskazujący na serwer CCcam (szczegóły w sekcji 3), możesz obserwować czasy odpowiedzi ECM na żądanie w czasie rzeczywistym na karcie Readers. Zobaczysz dokładnie, jak długo trwa każde żądanie odszyfrowania i czy jest serwowane z pamięci podręcznej czy z karty zdalnej.

Szukaj czasów odpowiedzi ECM konsekwentnie poniżej 500 ms. Powyżej 800 ms to problematyczne. Powyżej 1500 ms a zobaczysz zamrażanie się na wszystkim oprócz kanałów o powolnym ECM.

Dekodowanie ekranu informacji serwera CCcam na Twoim odbiorнiku

Na Enigma2 z uruchomionym CCcam wbudowana strona informacyjna (dostępna przez menu softcam lub wtyczkę taką jak CCcam Info) pokazuje połączone serwery, ich status, liczbę kart i listę CAID będącą w użytkowaniu. Każdy wpis pokazuje odległość hop. Karta pokazująca hop: 0 to bezpośrednia. Cokolwiek pokazujące hop: 2 lub wyższe zasługuje na bliższe przyjrzenie się.

Pole "clients" pokazuje, ilu innych użytkowników jest jednocześnie połączonych do tego samego serwera. Bardzo wysoka liczba klientów w stosunku do liczby kart to najwyraźniejszy wskaźnik serwera przeciążonego.

Co lista udziałów i hop count mówią Ci w czasie rzeczywistym

Lista udziałów to Twój na żywo widok tego, co serwer może faktycznie odszyfrować. Wymienia CAIDs (Identyfikatory Warunkowego Systemu Dostępu) i identyfikatory dostawcy. Jeśli próbujesz oglądać kanał używający Nagravision (CAID 1800x) i ten CAID nie znajduje się na liście udziałów, serwer po prostu nie może go odszyfrować — bez względu na to, jak dobre jest połączenie.

Porównaj listę udziałów z CAID-ami, które używają Twoje kanały docelowe. Listy CAID-ów możesz znaleźć w bazie danych kanałów Enigma2 lub sprawdzając wpisy lamedb. Jeśli istnieje niedopasowanie, potrzebujesz innego dostawcy z właściwymi kartami, a nie tweaka konfiguracyjnego.

Głębokie zapatrywanie się na konfigurację: prawidłowa konfiguracja klienta CCcam

Zła konfiguracja powoduje więcej "problemów z serwerem" niż rzeczywiste problemy z serwerem. Widziałem połączenia CCcam pracujące obwiniane dostawców, gdy rzeczywisty problem było złą ścieżką konfiguracji lub filtrem CAID blokującym prawidłowe udziały.

Lokalizacja pliku CCcam.cfg i podstawowa konfiguracja klienta

Na obrazach Enigma2 standardowa ścieżka to /etc/CCcam.cfg. Na niektórych obrazach (OpenPLi w szczególności) kończy się na /var/etc/CCcam.cfg. Sprawdź oba jeśli nie jesteś pewny, który obraz używa.

Minimalna działająca konfiguracja klienta wygląda

jak to:

C: server.example.com 12000 myuser mypassword no
SERIAL: /dev/sci0
DVBAPI DEVICE: /dev/dvb/adapter0/demux0
DVBAPI VERSION: 3

Linia SERIAL wskazuje na twój lokalny czytnik karty inteligentnej, jeśli go posiadasz. Jeśli używasz czystego serwera zdalnego bez karty lokalnej, możesz ją pominąć. Ścieżka DVBAPI DEVICE musi być zgodna z twoim rzeczywistym adapterem DVB — na urządzeniach z wieloma tunerami możesz mieć adapter0, adapter1 itp.

Kluczowe dyrektywy klienta: NEWCAMD LISTEN PORT, SERIAL, DVBAPI

Jeśli uruchamiasz CCcam jako mini-serwer na swoim urządzeniu, aby zasilać inne urządzenia w sieci lokalnej, ustawisz również NEWCAMD LISTEN PORT: 28910 (lub podobnie). Do czystego użytku klienta pomiń to. Dyrektywa DVBAPI VERSION powinna być zgodna z tym, co obsługuje DVB API twojego jądra — wersja 3 działa na większości nowoczesnych obrazów, wersja 6 na nowszych jądrach.

Konfiguracja OScam oscam.server dla trybu czytnika CCcam

To jest miejsce, gdzie OScam świeci w stosunku do czystego trybu klienta CCcam. W /etc/oscam/oscam.server blok czytnika CCcam wygląda tak:

[reader]
label = remote_cccam
protocol = cccam
device = server.example.com:12000
user = myuser
password = mypassword
cccversion = 2.2.1
minimizecards = 1
reconnecttimeout = 30
cccmaxhops = 2

Pole cccversion powinno być zgodne lub niższe niż to, co obsługuje serwer zdalny. Ustawienie minimizecards = 1 zmniejsza przeładowanie listy udostępniania. Filtr cccmaxhops = 2 mówi OScam, aby ignorować karty z liczbą przeskoków powyżej 2 — dobry filtr bezpieczeństwa, który uniemożliwia przypadkowe użycie słabych kart ponownie udostępnianych.

reconnecttimeout = 30 to sekundy, zanim OScam ponowi próbę przerwanych połączeń. Utrzymuj to między 20–60; zbyt nisko powoduje zalanie połączeń, zbyt wysoko pozostawia cię na martwym połączeniu.

Konfiguracja OScam oscam.dvbapi i oscam.user do lokalnego deszyfrowania

W /etc/oscam/oscam.dvbapi:

[dvbapi]
enabled = 1
au = 1
pmt_mode = 0
listen_port = 9000
boxtype = dreambox

A w /etc/oscam/oscam.user, lokalny klient, który łączy OScam z API DVB, wymaga prawidłowych filtrów CAID. To jest miejsce, gdzie ukrywają się większość częściowych awarii kanałów:

[account]
user = localuser
password = localpass
au = 1
caid = 0604,0919,1800,0100

Jeśli caid jest ustawiony zbyt restrykcyjnie, OScam będzie w ciągu deszyfrować żądania ECM dla kodów CAID spoza listy. Jeśli masz deszyfrowanie na niektórych kanałach, ale nie na innych, sprawdź najpierw ten filtr. Ustawienie caid = (puste) pozwala wszystkim kodom CAID przejść do testowania.

Rozwiązywanie problemów: ECM nie znaleziony, Softcam nie deszyfruje, Zamrożenie przy zmianie

Zamrożenie przy zmianie kanału to prawie zawsze problem z przekroczeniem czasu ECM, a nie brakująca karta. Kanał wysyła ECM, twój softcam przekazuje go na serwer zdalny, a odpowied

ograniczy się zbytnio. Dekoder przekracza limit czasu i wyświetla zawieszenie. Sprawdź dzienniki OScam pod kątem czasów odpowiedzi ECM na tym kanale.

"ECM not found" zwykle oznacza, że CAID lub ID dostawcy nie znajduje się na liście udostępniania, filtr CAID w oscam.user go blokuje, lub serwer zdalny jest przeciążony i porzucił żądanie. Spróbuj przełączyć kanały i wrócić — jeśli deszyfruje się przy drugiej próbie, to problem obciążenia po stronie serwera.

Jeśli softcam w ogóle nic nie deszyfruje po nowej konfiguracji, sprawdź, czy proces CCcam lub OScam faktycznie został prawidłowo zrestartowany. W Enigma2: init 4 && init 3 wymusza pełny restart softcama. Następnie sprawdź /tmp/CCcam.log lub dziennik OScam w pliku /var/log/oscam/oscam.log pod kątem błędów połączenia.

Czerwone flagi i czego unikać przy wyborze dostawcy CCcam

To jest sekcja, która zaoszczędzi ci najwięcej pieniędzy. Główne grzechy dostawców CCcam są dobrze znane w społeczności, ale rzadko wyjaśniane technicznie.

Sprzedaż nadmierna: zbyt wielu użytkowników na jednej karcie

Fizyczna karta inteligentna przetwarza jedno ECM naraz. Nie ma sposobu, aby to obejść — to ograniczenie sprzętu. Jeśli dostawca sprzedaje 50 połączeń wspieranym przez jedną kartę, ci 50 użytkowników stoi w kolejce do żądań ECM. Poza szczytem, gdy tylko 5 z nich ogląda, działa doskonale. O 21:00 w nocy meczowej wszystkie 50 jednocześnie obciąża kartę i otrzymujesz błędy "not subscribed" lub nieudane deszyfrowanie.

Charakterystyczne oznaki: serwer, który działa bezbładnie podczas testu w południe i całkowicie się rozpada w piątkowy wieczór. To sprzedaż nadmierna, a nie "problem sieciowy".

Ponowne udostępnianie bez ujawnienia: ukryty problem hopów

Niektórzy dostawcy nie posiadają żadnych kart. Kupują linię od innego dostawcy i odsprzedają ją, dodając w procesie hop. Sprzedawca może sam odsprzedawać ponownie udostępnioną linię. Gdy się łączysz, jesteś 3–4 hopy od fizycznej karty i zastanawiasz się, dlaczego twoje deszyfrowanie jest zawodne.

Rozwiązaniem jest proste: sprawdź liczbę hopów na liście udostępniania bezpośrednio po podłączeniu. Jeśli dostawca twierdzi, że ma "karty bezpośrednie", ale widzisz liczbę hopów 2 lub 3, zostałeś wprowadzony w błąd. Rozłącz się i przejdź dalej.

Brak polityki linii testowej i dlaczego to ma znaczenie

Odmowa udostępnienia linii testowej to czerwona flaga, koniec. Dostawca pewny swojej infrastruktury da ci 24–48 godzin na walidację usługi. Model "zapłać najpierw, testuj potem" istnieje specjalnie, aby przechwycić płatność zanim odkryjesz problemy. Nie angażuj się w to.

Podejrzane zakresy portów i niestandardowe konfiguracje

Standardowe porty CCcam to 12000, 12001, 15000, 16000 i 17000. Widzenie portu takiego jak 32891 lub 54000 nie jest automatycznie dyskwalifikujące, ale połącz to z dynamiczną nazwą hosta IP i brakiem linii testowej, a masz infrastrukturę, która wygląda na improwizowaną. Niestabilne lub NAT-intensywne konfiguracje często używają dziwnych portów, ponieważ działają na domowym połączeniu za routerem —

nie dedykowany sprzęt serwera.

Zwróć także uwagę na dostawców używających adresów IPv6 w linii C, gdy stos DNS odbiornika rozwiązuje tylko IPv4. Połączenie dycho nie powiodło się bez użytecznego błędu. Jeśli podejrzewasz to, spróbuj wymusić rozdzielczość IPv4 na nazwie hosta ręcznie, zanim założysz, że serwer jest wyłączony.

Roszczenia dotyczące czasu pracy w stosunku do rzeczywistości: jak monitorować samodzielnie

Uruchom własne monitorowanie. Zadanie cron netcat wspomnianych wcześniej działa dobrze. Dla czegoś bardziej ustrukturyzowanego skrypt Pythona, który próbuje nawiązać połączenie gniazda TCP co 5 minut i rejestruje powodzenie/niepowodzenie z sygnaturą czasową, daje ci czysty zapis:

import socket, datetime
try: s = socket.create_connection(("hostname", 12000), timeout=5) print(f"{datetime.datetime.now()} - UP") s.close()
except: print(f"{datetime.datetime.now()} - DOWN")

Uruchom to za pośrednictwem cron i przesyłaj wyjście do pliku dziennika. Po tygodniu będziesz mieć rzeczywiste dane dotyczące czasu pracy, a nie samodzielnie zgłaszane przez dostawcę 99,9%.

Serwer CCcam vs OScam: Który stos protokołów powinieneś uruchamiać?

Wiele osób szukających najlepszego serwera cccam w rzeczywistości walczy z problemem, który rozwiązałaby lepsza lokalna konfiguracja softcam. Serwer ma znaczenie, ale tak samo jak się z nim łączysz.

Ograniczenia protokołu CCcam w nowoczesnych konfiguracjach

Czysty tryb klienta CCcam na odbiornika nie ma logiki fallbacku. Jeśli udział nie powiedzie się, deszyfrowanie nie powiedzie się. Nie ma mechanizmu ponawiania próby, nie ma równoważenia obciążenia na wielu serwerach i nie ma buforowania ECM. To połączenie i nadzieja. W przypadku konfiguracji z jednym tunerem obserwującą jeden kanał naraz z dobrym serwerem działa. Dla czegoś bardziej złożonego, szybko pokazuje swoje ograniczenia.

Dodatkowo rejestrowanie CCcam jest minimalne. Kiedy coś pójdzie nie tak, otrzymujesz bardzo mało informacji diagnostycznych poza „nie znaleziono karty". To sprawia, że rozwiązywanie problemów jest wolne i frustrujące.

OScam jako lepssze rozwiązanie po stronie serwera

OScam obsługuje żądania ECM z konfigurowalnymi czytnikami fallback, cacheex (buforowanie odpowiedzi ECM) i priorytetem na czytnik. Jeśli twój podstawowy serwer CCcam nie odpowiada w skonfigurowanym limicie czasu, OScam automatycznie próbuje następnego czytnika. Możesz skonfigurować pięć różnych zdalnych serwerów CCcam jako czytniki fallback, a OScam zarządza całą rzeczą w sposób przejrzysty.

WebIf na http://localhost:8888 (port domyślny) daje ci czasy odpowiedzi ECM na żywo, status czytnika, listy udziałów i szczegółowe dzienniki. To jest zupełnie inne doświadczenie diagnostyczne w porównaniu ze stroną podstawowych informacji CCcam.

Uruchamianie OScam lokalnie podczas łączenia się ze zdalnym serwerem CCcam

To hybrydowa konfiguracja, którą uruchamiają doświadczeni użytkownicy. OScam zainstalowany na odbiornika obsługuje całe deszyfrowanie DVBAPI lokalnie. Łączy się ze zdalnym serwerem CCcam za pośrednictwem bloku czytnika protokołu CCcam w oscam.server. Oprogramowanie pośredniczące Enigma2 lub inne odbiornika komunikuje się z OScam za pośrednictwem portu nasłuchu DVBAPI (zwykle 9000), a OScam obsługuje wszystko inne.

Th

Zaletą jest to, że otrzymujesz warstwę zarządzania OScam na szczycie każdego serwera CCcam, do którego jesteś subskrybowany. Zła odpowiedź serwera? OScam ją rejestruje, przełącza się na inny czytnik, jeśli jest skonfigurowany, i nigdy nie zobaczysz zamieszania. Ta konfiguracja pozwala również połączyć zdalny serwer CCcam z lokalną kartą inteligentną w tej samej instancji OScam — będzie używać tego, który odpowie pierwszy.

Kiedy tryb klienta CCcam jest wciąż właściwym wyborem

Starsze odbiorniki, które nie mogą uruchomić OScam — niektóre budżetowe urządzenia set-top box, starsze modele Dreambox na starszym oprogramowaniu — są ograniczone do binarnego CCcam jako jedynej opcji. W takim przypadku prawidłowe skonfigurowanie najlepszego serwera cccam staje się bardziej ważne, ponieważ nie ma lokalnej warstwy oprogramowania, aby zrekompensować złe połączenie. Potrzebujesz serwera o niskim opóźnieniu, niskiej liczbie przeskoków i stabilnym czasem pracy bardziej niż kiedykolwiek.

Niektórzy użytkownicy również preferują tryb klienta CCcam dla prostoty — jeden binarny, jeden plik konfiguracyjny, gotowe. To jest ważny wybór dla konfiguracji z jednym tunerem i jednym serwerem, gdzie nie potrzebujesz dodatkowych obciążeń zarządzania OScam.

Mostkowanie protokołów: czytnik CCcam w OScam dla maksymalnej kompatybilności

OScam obsługuje wiele protokołów czytnika jednocześnie. Możesz uruchomić czytnik CCcam, czytnik Newcamd i czytnik CS378x w tej samej instancji OScam. Każdy łączy się z innym zdalnym serwerem przy użyciu jego natywnego protokołu, a OScam predstavia ujednoliconą pulę udostępniania dla lokalnego klienta DVBAPI.

Uważaj na jeden konkretny konflikt: jeśli włączysz tryb cacheex OScam podczas uruchamiania czytnika CCcam, możesz w końcu wysłać zduplikowane żądania ECM — OScam próbuje pamięci podręcznej, nie trafia, przekazuje do czytnika CCcam, a timing odpowiedzi zostaje zamieszany. To pojawia się jako przerywaną niestabilność, która wygląda jak problem serwera. Wyłącz cacheex na bloku czytnika, jeśli to widzisz: dodaj cacheex = 0 do konfiguracji czytnika i przetestuj ponownie.

Jeszcze jeden przypadek graniczny wart poznania: jeśli twój dostawca korzysta z dynamicznej nazwy hosta DNS, która zmienia IP okazjonalnie, a buforowanie TTL DNS twojego odbiornika jest zbyt długie, skończysz ze starym IP po przeniesieniu serwera dostawcy. OScam lepiej obsługuje reconnection niż binarny CCcam w tym scenariuszu, ponieważ ponownie rozwiązuje nazwę hosta przy każdej próbie reconnect. Binarny CCcam może utrzymać stary IP, dopóki nie uruchomisz go ręcznie.

---

```