Mecool KI Pro Sharing Setup 2026: OScam& Przewodnik CCcam

Jeśli szukałeś przewodnika po konfiguracji udostępniania kart Mecool KI Pro 2026, który rzeczywiście wymienia chipset zamiast wklejać ogólne...udostępnianie kart przewodnik po konfiguracji 2026, który rzeczywiście wymienia chipset zamiast wklejać ogólne polecenia Enigma2, już wiesz, jak to frustrujące. Większość dostępnych materiałów została napisana dla Dreamboxa lub Vu+ i po prostu nie pasuje do układu Amlogic S905D tego urządzenia oraz demodulatora Availink AVL6862. Ten przewodnik jest napisany specjalnie dla sprzętu KI Pro i obejmuje części, które rzeczywiście się psują: wybór oprogramowania, dokładne ścieżki konfiguracji, łańcuch dvbapi i dlaczego twoja linia zgłasza połączenie, podczas gdy ekran pozostaje czarny.

Uruchamiałem OScam na kilku z tych urządzeń w ciągu ostatniego roku, zarówno na CoreELEC, jak i na uproszczonym obrazie Armbian, a tryby awarii powtarzają się nieustannie w wątkach na forach. Więc to mniej "oto samouczek", a bardziej "oto co naprawdę idzie źle i jak to sprawdzić."

Mecool KI Pro Kontrola Rzeczywistości Sprzętu i Oprogramowania (2026)

Zacznij tutaj, ponieważ pominięcie tego marnuje najwięcej czasu. KI Pro łączy układ Amlogic S905D SoC z demodulatorem Availink AVL6862 dla tunera DVB-S2/T2/C. AVL6862 nigdy nie miał płynnego wsparcia w głównym nurcie Linuksa — potrzebuje sterownika bloba bliskiego dostawcy, a nie ogólnego stosu dvb-core, który otrzymasz na urządzeniu x86 lub Raspberry Pi z tunerem USB. Ten pojedynczy fakt jest przyczyną połowy postów "mój tuner się nie pojawia", które znajdziesz.

Standardowy Android na KI Pro to martwy koniec dla tego. Nie ma gniazda dvbapi, nie ma niezawodnego miejsca do uruchomienia binarnego softcamu, a Android DVB HAL nie udostępnia /dev/dvb w sposób, w jaki potrzebuje przestrzeń użytkownika Linuksa. Jeśli chcesz działającego Mecool KI Proudostępnianie kart konfiguracja 2026, musisz przejść na inny system — koniec kropka.

Amlogic S905D + tuner Availink AVL6862: co rzeczywiście wspiera

AVL6862 wykonuje demodulację sprzętową i dekodowanie FEC dla DVB-S/S2 oraz DVB-T/T2/C, ale przekazuje surowe dane TS przez jeden frontend. To zdolny chip, ale to jeden fizyczny tuner za tym interfejsem combo — nie dwa niezależne tunery w jednym urządzeniu, co nieustannie myli ludzi (więcej o tym poniżej).

Standardowy Android vs CoreELEC vs Armbian: która ścieżka wspiera softcam

CoreELEC to ścieżka najmniejszego oporu. Zawiera (lub może być zbudowany z) moduł jądra AVL6862, daje ci tvheadend jako backend telewizyjny i ma instalowalny dodatek OScam. Armbian to trudniejsza, ale bardziej elastyczna droga — otrzymujesz pełną przestrzeń użytkownika Debiana, sam kompilujesz lub pobierasz moduły DVB, a OScam uruchamiasz jako standardową usługę systemd. Standardowy Android: nie warto. Żadne z podejść nie jest "lepsze" w abstrakcji; CoreELEC pozwala szybciej uruchomić, Armbian daje więcej kontroli, jeśli już czujesz się komfortowo z zarządzaniem pakietami Linuksa.

Moduły sterowników DVB: dvb-core, avl6862, r848 i jak potwierdzić, że zostały załadowane

Na działającym obrazie powinieneś zobaczyć dvb_core, sterownik frontend avl6862 oraz (w wariantach z hybrydowym tunerem) sterownik tunera r848 lub podobny. Sprawdź za pomocą:

lsmod | grep -E 'dvb|avl6862'

Jeśli nic nie wraca, twoja kompilacja jądra po prostu nie zawiera modułu — żaden plik konfiguracyjny na świecie tego nie naprawi. Potrzebujesz innej kompilacji CoreELEC lub jądra z wbudowanym sterownikiem AVL6862.

Sprawdzanie, czy twój tuner jest widoczny: dmesg | grep dvb, ls /dev/dvb/adapter0

Dwa polecenia, uruchom je w tej kolejności:

dmesg | grep -i dvb

Zdrowy wynik pokazuje frontend0, demux0 i dvr0. Bardzo prawdopodobnie NIE zobaczysz urządzenia ca0 — i to w porządku, nawet oczekiwane. To urządzenie nie ma sprzętowego gniazda CI/CA, więc deszyfrowanie odbywa się w oprogramowaniu za pośrednictwem warstwy dvbapi OScam, a nie przez sprzętowy interfejs CAM ca0. Jeśli całkowicie brakuje frontend0, przestań konfigurować softcam i najpierw napraw sytuację ze sterownikiem; nic poniżej nie będzie działać.

Dlaczego tuner combo KI Pro nie może jednocześnie odbierać S2 i T2

Jeden frontend oznacza jedno aktywne zablokowanie demodulatora w danym czasie. Nie możesz jednocześnie oglądać kanału satelitarnego i kanału naziemnego, a — to jest to, co generuje najwięcej zdezorientowanych zapytań wsparcia — nie możesz również zablokować dwóch różnych transponderów satelitarnych jednocześnie. Jeden transponder, koniec kropka, aż dostroisz.

Instalacja OScam lub CCcam na Mecool KI Pro

Gdy /dev/dvb/adapter0 pokazuje odpowiednie węzły, rzeczywisty procesudostępnianie kart konfiguracji 2026 staje się głównie ćwiczeniem w systemie plików i uprawnieniach. Oto konkretna struktura dla każdego systemu operacyjnego.

Wybór OScam vs CCcam na ARM/aarch64: co rzeczywiście kompiluje się i działa

OScam jest aktywnie utrzymywany, ma czyste cele kompilacji aarch64 i armv7 oraz zawiera naprawdę przydatny interfejs webowy do diagnozowania, co się dzieje na poziomie czytnika. CCcam to zamknięty binarny, historycznie zbudowany dla 32-bitowego ARM, z zasadniczo żadnym interfejsem do debugowania poza plikiem dziennika. Na urządzeniu, które będziesz musiał rozwiązywać problemy — a na pewno będziesz — OScam wygrywa łatwo. Może również komunikować się z protokołem CCcam jako klient, więc nie tracisz kompatybilności z źródłem protokołu CCcam, wybierając go.

Pobieranie binarnego OScam aarch64/armv7 i umieszczanie go w odpowiednim miejscu

S905D to chip 64-bitowy, ale wiele obrazów CoreELEC i lekkich obrazów Armbian nadal działa w przestrzeni użytkownika 32-bitowej. Zanim skopiujesz jakikolwiek plik binarny, sprawdź obie strony:

uname -m

Jeśli uname -m zgłasza armv7l, ale twój plik binarny to aarch64 (lub odwrotnie), otrzymasz "nie można wykonać pliku binarnego: błąd formatu wykonania" i żadne chmod-y tego nie naprawią. Dopasuj architekturę pliku binarnego do przestrzeni użytkownika, a nie do teoretycznej możliwości CPU.

Ścieżka CoreELEC: /storage/.config/oscam/ i jednostka systemd/autostart

Jeśli używasz dodatku OScam, pliki binarne znajdują się w /storage/.kodi/addons/service.softcam.oscam/bin/. Ręczne instalacje zazwyczaj trafiają do /storage/oscam/, z plikami konfiguracyjnymi w /storage/.config/oscam/. To przetrwa ponowne uruchomienia, ponieważ /storage utrzymuje się podczas aktualizacji CoreELEC — nie wrzucaj plików do /tmp, oczekując, że się utrzymają.

Ścieżka Armbian/Debian: /usr/local/bin/oscam i /usr/local/etc/

Obowiązuje tradycyjna konwencja Linuxa: binarka w /usr/local/bin/oscam, katalog konfiguracyjny w /usr/local/etc/. W tym katalogu znajdują się oscam.conf, oscam.server, oscam.user i oscam.dvbapi, które wypełnimy w następnej sekcji.

Ustawianie uprawnień do plików: chmod 755 na binarce, 600 na plikach konfiguracyjnych

chmod 755 /usr/local/bin/oscam

Twoje pliki konfiguracyjne zawierają nazwę użytkownika i hasło w postaci tekstu jawnego dla twojej linii udostępniania. 600 oznacza, że tylko właściciel może je odczytać — nie ma powodu, aby pliki z danymi uwierzytelniającymi były dostępne dla wszystkich na urządzeniu, które może mieć inne usługi uruchomione.

Uruchamianie OScam ręcznie i przeglądanie logu startowego przed uruchomieniem jako demon

Najpierw uruchom go w trybie foreground, zawsze:

./oscam -c /usr/local/etc

Obserwuj wyjście startowe pod kątem linii połączenia czytnika i wszelkich błędów analizy w twoim konfigu. Gdy będziesz pewny, że jest czysto, uruchom go w tle z -b:

./oscam -b -c /usr/local/etc

Pomijanie kroku foreground to sposób, w jaki ludzie kończą wpatrując się w webif, który się nie ładuje, nie mając pojęcia dlaczego — odpowiedź prawie zawsze była w logu startowym, którego nigdy nie sprawdzili.

Włączanie interfejsu webowego na porcie 8888 i ograniczenie go tylko do LAN

W oscam.conf pod [webif] ustaw httpport=8888 i ogranicz dostęp:

[webif]

Nigdy nie wystawiaj 8888 do internetu. Nie ma powodu, aby twój webif był dostępny poza twoim LAN, a pozostawienie go otwartym to po prostu rozdawanie strony logowania każdemu, kto skanuje w poszukiwaniu takiej.

Działające pliki konfiguracyjne: oscam.conf, oscam.server, oscam.user i oscam.dvbapi

To jest część, która faktycznie decyduje, czy twoja konfiguracja udostępniania karty Mecool KI Pro 2026 działa, czy zamraża się na zawsze. Wszystkie wartości poniżej są miejscami zastępczymi — zamień host.example.net i dane uwierzytelniające na swoje własne.

oscam.conf: bloki [global], [dvbapi] i [webif] wyjaśnione linia po linii

[global]

pmt_mode to ten, który ludzie bezmyślnie kopiują z postów na forum, nie rozumiejąc. pmt_mode=0 używa pliku CA PMT, który OScam pisze i odczytuje sam — rzadko potrzebne tutaj. pmt_mode=4 mówi OScam, aby pominął pisanie plików PMT i zamiast tego uzyskał dane PMT bezpośrednio przez gniazdo dvbapi, co jest powszechne w integracjach z tvheadend. pmt_mode=6 łączy podejście oparte na gnieździe z dodatkowymi aktualizacjami PMT wywoływanymi przez czytnik i jest tym, co większość stosów CoreELEC/Amlogic kończy używać, ponieważ dobrze współpracuje z obsługą klienta CA tvheadend. Jeśli kanały się uruchamiają, ale nigdy nie dekodują, pmt_mode to pierwsza rzecz, którą warto spróbować zmienić między 4 a 6.

oscam.server: dodawanie czytnika protokołu CCcam (host cccam, port, użytkownik, hasło)

[reader]

cccversion, cccmaxhops i cccwantemu: co każdy z nich naprawdę zmienia

cccversion ustawia, którą wersję protokołu CCcam OScam prezentuje podczas handshake — niezgodności tutaj mogą spowodować, że źródło cicho odrzuci połączenie, nawet z poprawnymi danymi uwierzytelniającymi. cccmaxhops ogranicza, ile przekazywanych skoków OScam zaakceptuje ECM; zmniejsz to do 1 lub 2, jeśli chcesz odrzucić głęboko przekazywane karty (które mają tendencję do gorszych czasów ECM). cccwantemu=1 mówi OScam, aby również akceptował emulowane/miękkie CAID z tego czytnika, jeśli źródło je dostarcza — pozostaw to na 0, chyba że twoje źródło wyraźnie mówi, że dostarcza emu.

oscam.user: tworzenie lokalnego użytkownika, z którym twoje urządzenie się uwierzytelnia

[account]

To jest konto, jako które twój własny klient dvbapi (tvheadend, przez lokalne gniazdo) się uwierzytelnia — to nie są twoje dane uwierzytelniające do udostępniania upstream, to tylko lokalna pętla zwrotna.

oscam.dvbapi: boxtype, au i linie filtru P: / I:

[dvbapi]

Linie P: i I: pozwalają ci ograniczyć, które PID/CAID są przekazywane, co jest przydatne, gdy wszystko działa i chcesz usunąć szum z logu, ale całkowicie je pomiń, gdy dopiero zaczynasz dekodować.

Alternatywa dla CCcam.cfg: format linii C: i jego dokładna kolejność pól

Jeśli używasz CCcam zamiast tego (lub OScam skonfigurowanego do odczytu CCcam.cfg dla definicji czytnika), format linii jest sztywny:

C: host.example.net 12000 NAZWA_UŻYTKOWNIKA HASŁO

Oddzielone spacjami, w tej dokładnej kolejności, bez białych znaków na końcu. Jeśli edytujesz ten plik w Notatniku na Windows i przesyłasz go, prawdopodobnie wprowadzisz zakończenia linii CRLF — plik wygląda identycznie dla twoich oczu, ale parser się dusi lub cicho ignoruje linię. Edytuj go w czymś, co zapisuje zakończenia linii Unix, lub uruchomdos2unix CCcam.cfg po jego przesłaniu.

Numery portów, które faktycznie będziesz używać: porty udostępniania w zakresie 12000, 8888 webif

Twoje źródło przypisze dowolny port, którego używa — 12000 to konwencjonalny przykład, ale nie standard, traktuj to jako miejsce zastępcze. 8888 to domyślny port webif OScam. Żaden z nich nie wymaga konfiguracji routera dla ustawienia klienta; to dotyczy tylko, jeśli uruchamiasz stronę serwera.

Łączenie klienta udostępniania z tunerem (łańcuch DVBAPI)

Zrozumienie tego łańcucha to to, co zamienia "to nie działa" w "oto dokładnie, gdzie jest zepsute." Przepływ: frontend AVL6862 blokuje transponder, demux ujawnia PID ECM zaszyfrowanego strumienia, tvheadend (lub warstwa dvbapi bezpośrednio) przekazuje PMT do OScam przez /tmp/camd.socket, OScam przesyła ECM do skonfigurowanego czytnika, karta czytnika oblicza słowo kontrolne i odsyła je, a dopiero wtedy następuje dekodowanie programowe — na CPU S905D, a nie w dedykowanym sprzęcie.

Jak dvbapi faktycznie komunikuje się z demuxem: /tmp/camd.socket i przekaz PMT

Gniazdo w /tmp/camd.socket jest punktem przekazania między Twoim backendem TV a OScam. Jeśli to gniazdo nie istnieje lub OScam na nim nie nasłuchuje, dane PMT nigdy nie docierają do OScam i otrzymasz strumienie, które odtwarzają, ale nigdy nie dekodują, bez żadnej aktywności w logach OScam — ponieważ OScam nawet nie widziało żądania.

Tvheadend + OScam na CoreELEC: konfiguracja klienta capmt vs dvbapi

W tvheadend dodaj klienta CA w sekcji Konfiguracja → Wejścia DVB → CA, wybierając typ CAPMT/DVBAPI, wskazując na 127.0.0.1 na porcie odpowiadającym Twojemu oscam.dvbapi listen_port, jeśli ustawiłeś go explicite (wiele konfiguracji pozostawia go na domyślnej ścieżce gniazda). Nie konfiguruj więcej niż jednego klienta CA wskazującego na ten sam demux — zobacz sekcję rozwiązywania problemów, dlaczego to powoduje konflikty.

Klient CA Kodi/tvheadend: wskazując go na 127.0.0.1 i odpowiedni port

127.0.0.1, ponieważ OScam i tvheadend działają na tym samym urządzeniu w prawie każdej konfiguracji KI Pro. Jeśli jakoś rozdzieliłeś je na dwa urządzenia, użyj adresu IP LAN, ale to nietypowa konfiguracja dla tego sprzętu i dodaje punkt awarii bez rzeczywistej korzyści.

Weryfikacja dekodowania: zakładka Czytnicy OScam, czas ECM i kolumna CW

Zaloguj się do http://127.0.0.1:8888, przejdź do zakładki Czytnicy. Chcesz zobaczyć status swojego czytnika jako połączony z niezerowym, sensownym czasem "ostatniego ECM". Widok aktywnych klientów na zakładce Status pokazuje słowa kontrolne (CW) dostarczane podczas oglądania kanału — to jest Twoja prawda, bardziej wiarygodna niż poleganie tylko na znaczniku "połączony".

Czytanie istotnych linii logu: znaleziono, nie znaleziono, przekroczenie czasu, trafienie w pamięci podręcznej

"znaleziono" oznacza, że słowo kontrolne wróciło i dekodowanie powinno działać. "nie znaleziono" oznacza, że czytnik nie obsługuje tego CAID/dostawcy — problem z konfiguracją lub subskrypcją, nie z siecią. "przekroczenie czasu" oznacza, że czytnik nie odpowiada wystarczająco szybko — problem z siecią/opóźnieniem. "trafienie w pamięci podręcznej" jest w porządku, oznacza, że OScam już miało CW z poprzedniego żądania. Naucz się rozróżniać te przypadki w /tmp/oscam.log, ponieważ wskazują na zupełnie różne rozwiązania.

Rozwiązywanie problemów: Zawieszanie, Czarny ekran i 'Linia połączona, ale brak obrazu'

Czytnik pokazuje POŁĄCZONY, ale każdy kanał jest czarny: niezgodność caid/dostawca

Połączenie tylko dowodzi, że TCP i logowanie się powiodły — nic o dostępie do treści. Sprawdź CAID kanału w szczegółach usługi tvheadend (lub informacji o strumieniu Kodi), a następnie porównaj go z CAID-ami, które Twój czytnik faktycznie zgłasza w zakładce Czytnicy OScam. Jeśli się nie pokrywają, żadne dostosowanie konfiguracji tego nie naprawi — Twoje źródło po prostu nie ma dostępu do szyfrowania tego kanału.

Kanały zacinają się co kilka sekund: przekroczenie czasu ECM, liczba skoków lub obciążenie CPU

Najpierw sprawdź kolumnę czasu ECM w webif. Zdrowy zdalny czytnik odpowiada w znacznie poniżej 500 ms konsekwentnie. Jeśli widzisz czasy zbliżające się do lub przekraczające sekundę na strumieniu 25-30 fps, zobaczysz widoczne zacięcia — dekoder głoduje, czekając na następne słowo kontrolne. Następnie sprawdź cccmaxhops w tym czytniku; wysoka liczba skoków oznacza, że Twoje żądanie ECM odbija się przez wiele serwerów pośredniczących, zanim zostanie odpowiedziane, co zwiększa opóźnienie przy każdym skoku. Uruchom równieżtop podczas odtwarzania — oprogramowanie dekodujące mux H.264 1080i jest naprawdę intensywne dla CPU na S905D, a jeśli coś innego obciąża CPU, dekodowanie również głoduje.

Niektóre kanały działają, kanały HD nie: pokrycie caid vs Twoja linia

SD i HD symultany tego samego kanału często znajdują się na różnych transponderach z różnymi CAID-ami. Twoja linia może mieć dostęp do szyfrowania sygnału SD, ale nie do szyfrowania sygnału HD — sprawdź oba CAID-y niezależnie, zamiast zakładać, że "kanał" to jeden punkt dostępu.

Zapora i NAT: wychodzący TCP na porcie udostępniania, brak potrzeby na przychodzący

Jako klient potrzebujesz tylko wychodzącego TCP do portu swojego źródła. Jeśli przewodnik mówi, aby przekierować przychodzący port na swoim routerze w tym celu, opisują uruchamianie serwera, a nie łączenie się z nim — całkowicie zignoruj ten krok w konfiguracji klienta.

Dryf czasu: dlaczego niesynchronizowany zegar psuje handshake i jak to naprawić za pomocą NTP

Wiele urządzeń, takich jak KI Pro, nie ma baterii RTC, więc po przerwie w zasilaniu zegar resetuje się i dryfuje, aż coś go zsynchronizuje. Zegar różniący się o więcej niż kilka minut psuje handshake CCcam/OScam w wielu konfiguracjach źródła. Sprawdź za pomocą:

data

Upewnij się, że synchronizacja NTP jest włączona (CoreELEC i Armbian obsługują to od razu) zamiast polegać na tym, że zegar przetrwa poprawnie ponowne uruchomienie.

Przegrzewanie S905D: throttling termiczny jako niedodiagnozowana przyczyna zacięć

Jeśli dekodowanie działa dobrze przez 30-40 minut, a potem zaczyna się zaciąć, to nie jest Twoja linia udostępniania — to throttling termiczny. KI Pro zamknięty w zamkniętej szafce telewizyjnej bez przepływu powietrza będzie ograniczać S905D pod stałym obciążeniem dekodowania + dekodowania. Sprawdźcat /sys/class/thermal/thermal_zone0/temp zanim założysz, że to problem z siecią.

MTU i Wi-Fi: dlaczego przejście na przewodowy Ethernet naprawia połowę wszystkich zgłoszeń o zacięciach

Pakiety ECM są małe, ale wrażliwe na opóźnienia — połączenie Wi-Fi z słabym sygnałem może odtwarzać wideo dobrze (buforowane, tolerancyjne na jitter), a jednocześnie przerywać rzeczywistą wymianę ECM (niebuforowane, potrzebuje szybkiej rundy). Jeśli rozwiązujesz problem z zacięciami i jesteś na Wi-Fi, podłącz Ethernet, zanim dotkniesz jakiejkolwiek wartości konfiguracyjnej. Rozwiązuje to dużą część sporadycznych zgłoszeń o zacięciach na tym konkretnym urządzeniu, bezwarunkowo to polecam.

Wybieranie źródła udostępniania bez ryzyka

Nie będę wymieniać ani wskazywać na żadną konkretną usługę — nie o to chodzi w tym artykule, a szczerze mówiąc, rekomendacja z nazwiskiem szybko stanie się nieaktualna. Oto jak ocenić jedno technicznie.

Kryteria techniczne do oceny: czas działania, czas odpowiedzi ECM, pokrycie CAID

Po połączeniu obserwuj kolumnę czasu ECM w swoim webif OScam przez pełne 24 godziny, a nie tylko przez pierwsze pięć minut. Źródło, które wydaje się szybkie przy pierwszym połączeniu, ale pogarsza się w godzinach szczytu wieczornym, mówi Ci coś o tym, jak jest nadmiernie obciążone. Sprawdź pokrycie CAID/dostawcy w odniesieniu do konkretnych transponderów, które faktycznie oglądasz — roszczenia o pokrycie nic nie znaczą, jeśli nie obejmują muxów w Twoim regionie.

Lokalna vs zdalna karta: budżet opóźnienia i dlaczego geografia ma znaczenie

Każde żądanie ECM to podróż w obie strony. Źródło na innym kontynencie dodaje rzeczywiste opóźnienie tranzytowe do każdego pojedynczego żądania, oprócz czasu odpowiedzi samego źródła. Jeśli dążysz do czasów ECM poniżej 500 ms, geografia jest częścią budżetu, niezależnie od tego, czy ktoś Ci to mówi, czy nie.

Czerwone flagi: brak próby, brak linii testowej, brak opublikowanych szczegółów protokołu/portu

Źródło, które nie da Ci krótkiej linii testowej przed zobowiązaniem, lub nie powie Ci wprost, czy używają protokołu CCcam czy OScam i jakiego zakresu portów używają, nie daje Ci wystarczających informacji, aby faktycznie skonfigurować i zweryfikować cokolwiek. Ta nieprzejrzystość sama w sobie jest sygnałem.

Dlaczego roszczenia o 'nieograniczone połączenia' są technicznie nieprawdopodobne

Fizyczna karta inteligentna odpowiada na żądania ECM jedno po drugim. Każde źródło twierdzące, że ma naprawdę nieograniczone jednoczesne połączenia z ustalonej puli kart, opisuje coś, co nie zgadza się z tym, jak działa sprzęt — to, co naprawdę otrzymujesz, to kolejka, a kolejki objawiają się jako rosnące czasy ECM pod obciążeniem.

Zabezpieczanie własnej linii: unikalne dane uwierzytelniające, brak udostępniania danych uwierzytelniających

Użyj unikalnej nazwy użytkownika/hasła, które wydaje ci źródło, trzymaj oscam.user i oscam.server z uprawnieniami 600, jak opisano powyżej, i nie wklejaj swoich danych uwierzytelniających do publicznych postów na forum, gdy prosisz o pomoc — zamiast tego zrób zrzut ekranu interfejsu webowego z pustym polem hasła.

Co nie działa na Mecool KI Pro (oszczędź sobie weekendu)

Stockowe oprogramowanie Android + losowy plik APK softcam: dlaczego to jest ślepy zaułek

Te pliki APK to w dużej mierze porzucone oprogramowanie sprzed lat, stworzone w oparciu o interfejsy API Android DVB, które nie pasują do tego, jak HAL tej skrzynki faktycznie udostępnia tuner. Otwierają się, mogą nawet pokazywać interfejs użytkownika, ale nic nie robią. Nie marnuj wieczoru na tej ścieżce.

Oczekiwanie zachowania slotu CI/CA sprzętu: nie ma slotu CAM

KI Pro nie ma fizycznego slotu CI/CA. Jeśli przewodnik mówi, aby "włożyć moduł CAM", został napisany dla zupełnie innej skrzynki — jakiegoś sprzętu Enigma2 lub karty telewizyjnej PC z prawdziwym slotem CI. Deszyfrowanie tutaj jest w 100% programowe, przez dvbapi.

Uruchamianie OScam i CCcam jednocześnie na tym samym demuxie

Dwa softcamy walczące o to samo przekazanie PMT produkują dokładnie ten czarny ekran, losowe zacięcia, których próbujesz uniknąć. Wybierz jeden. Jeśli masz oba zainstalowane z wcześniejszych eksperymentów, wyłącz/zatrzymaj jeden całkowicie przed debugowaniem drugiego.

Stare samouczki Enigma2: ścieżki i typy skrzynek nie pasują do Amlogic

/etc/tuxbox/config, /usr/keys/, założenia boxtype=dreambox — nic z tego nie istnieje ani nie ma zastosowania w CoreELEC lub Armbian. Kopiowanie ścieżek Enigma2 hurtowo to jeden z najczęstszych marnotrawstw czasu w wątkach forum KI Pro, a można tego uniknąć, wiedząc, że skrzynka nie działa na Enigma2.

Streaming multi-pokojowy z jednego tunera: twardy limit jednego frontend

Jeden frontend, jeden transponder, koniec kropka. Możesz obsługiwać wiele pokoi z jednego KI Pro tylko wtedy, gdy każdy pokój ogląda kanał na tym samym transponderze w tym samym czasie. To jest limit sprzętowy, a nie coś, co jakiekolwiek ustawienie dvbapi zmieni.