AbrahaM

prrr, wróć, myślałem że piszesz o esi/uhd. mój błąd.

Niech zgadnę, masz wpięty kabel antenowy tylko do głowicy B? to jest znany błąd w FastSearch, on na twardo dobija się do głowicy A by złapać "z nieba" listy kanałów.

Czyli nie masz zapisywanych logów, zmień zgodnie ze wskazówkami i będziesz miał logowanie do pliku. co najmniej to samo (w livelog może być mniej) co widzisz w livelog będzie zapisane w logu w pliku.

to znaczy, że 1) albo robiłeś restart odbiornika i logi zostały usunięte 2) masz logowanie ustawione inaczej niż konfiguracji wzorcowej niż u nas, 3) albo masz ustawione disablelog = 1 jak, to już nie wiem, musisz sprawdzić w oscam.conf co jest wpisane w linii logfile = /cośtam i tam szukać logów, pod warunkiem, że logowanie nie było wyłączone, patrz punkt 3. i ze względu na żywotność NAND/NOR radzę jednak ustawić to na logfile = /ram/oscam.log

Nie obraź się, ale sam sobie jesteś winny. W dodatku mędrkujesz. A sam nawet nie podałeś w jasny sposób czy problem dotyczy karty 0B01 czy 0100, zaś deklarowanie obu CAID dla fizycznego czytnika jest błędem. oscam.dvbapi na odbiorniku jest konieczne (z odpowiednim wpisem 1 na końcu), by oscam próbował dla danego kanału (w tym wypadku TVP1 HD zalecanego do aktywacji i reaktywacji) konsekwentnie korzystać z karty (by było możliwe posłanie na nią EMM), bez tego będzie kończył aktywność po paru NOK. Gdybyś miał prawidłowo ustawiony oscam, to by nie było problemu ani z aktualizowaniem uprawnień na bieżąco ani z (re)aktywacją. Owszem, możesz wsadzić kartę do dowolnego prostego odbiornika i w nim zrobić (re)aktywacje.

Poniżej zamieszczamy TEORETYCZNĄ konfiguracje dla CP w oparciu o karty 1803 / NAGRA, jest to konfig wykorzystujący do ostatniego przecinka możliwości OSCama, z zastosowaniem filtrowania ECM po długości, po nagłówkach ECM oraz ze zdefiniowaniem w oscam.dvbapi wszystkich niezbędnych parametrów, a nie jak się (błędnie) przyjęło, tylko CAID. Filtrowanie ECM po długości i po nagłówkach w tym konfigu jest mocno zalecane, gdyż te parametry są od bardzo dawna niezmienne. Zastosowano blokadę EMM klas: unknown, global. oscam.conf [global] disablelog = 1 logfile = /ram/oscam.log clientmaxidle = 300 nice = 10 maxlogsize = 512 lb_auto_betatunnel = 0 ecmfmt = c:p:s:d:i:l|h [dvbapi] enabled = 1 au = 1 pmt_mode = 6 user = dvbapi [webif] httpport = 8888 httprefresh = 0 httppollrefresh = 7 httpshowuserinfo = 1 httpshowcacheexinfo = 1 httpshowecminfo = 1 httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255,10.0.0.0-10.255.255.255 hideclient_to = 60 oscam.user [account] user = dvbapi pwd = dvbapi au = 1 group = 1 oscam.server [reader] label = sci0 description = czytnik wbudowany protocol = internal device = /dev/sci0 caid = 1803 ident = 1803:000000,007101 ecmwhitelist = 1803:92 ecmheaderwhitelist = 1803:80308F078D,81308F078D detect = cd group = 1 emmcache = 1,3,31 blockemm-unknown = 1 [reader] label = sci1 emmcache = 1,3,31 description = czytnik wbudowany dodatkowy (np w przerobionych 5800 BSLA/BSKA, czy w Spark 7162) enable = 0 protocol = internal device = /dev/sci1 detect = cd group = 1 blockemm-unknown = 1 [reader] label = phoenix description = czytnik zewnetrzny phoenix na usb emmcache = 1,3,31 enable = 0 protocol = mouse device = /dev/ttyUSB0 detect = none group = 1 blockemm-unknown = 1 wpisy do standardowej pracy: oscam.dvbapi P:1803:000000:::0000 I:0 wpisy na okoliczność reaktywacji karty na kanale TV6: oscam.dvbapi P:1803:000000:290E::0000 1 # TV6 P:1803:000000:::0000 I:0 W załączeniu pliki konfiguracyjne 1:1 zgodne z omawianym konfigiem, z oscam.dvbapi w wariancie pod reaktywację. 13.01.2016: aktualizacja konfiguracji poprzez usunięcie: blockemm-g = 1, aktualizację opisu czytnika sci1, aktualizacja plików. konfiguracja_1803.zip

Co to [reader] label = cyfr protocol = mouse device = /dev/ttyUSB0 caid = 0100,0B01 #ecmwhitelist = 0100@000068:64;0B01:6C,76,88 detect = cd group = 1 emmcache = 1,3,2 blockemm-unknown = 1 lb_weight = 200 Ma być? definiujesz ALBO 0100 ALBO 0B01, żadne definiowanie obu naraz. W oscam.dvbapi dopisana jedynka po priorytecie, do tego sprawdzona zgodność grup. To musi działać.

rozumiem że masz problem z serwerem w ramach domowego multiroomu na własnym sprzęcie, innego nawet nie mogę rozważać, niestety najprawdopodobniej problem jest po stronie serwera, logi domyślnie są zapisywane w /ram/oscam.log co oznacza, że wraz z restartem boxa je stracisz, ale dzięki temu nie będzie "zajeżdżany" NAND/NOR.

Pierwsze co bym sprawdził, to coś, czego pewnie byś się nie spodziewał, czyli czy aby sygnał nie jest za silny. Wepnij w odbiornik tak półmetrowy kawałek kabla antenowego, jeśli czymś takim będziesz miał normalny odbiór, to będzie to znaczyć, że w instalacji masz zbyt silny sygnał, co z kolei powoduje przesterowanie głowicy i problemy z odbiorem.

@tux Połowicznie Tobie przyznam rację. Problem o którym pisze robert_cz nie powinien mieć w ogóle miejsca, przy prawidłowo zaprojektowanym sprzęcie sieciowym i przy prawidłowo wykonanej instalacji. Jednak niestety ilość nieprawidłowo działającego sprzętu i/lub sieci jest na tyle duża, że ewentualne zmiany zasługują co najmniej na dyskusję i ich rozważanie Mamy (w zasadzie Ty masz, jako główny decydent, osoba kierująca rozwojem GOS) dylemat filozoficzno-praktyczny. Czy GOS ma działać w 100% zgodnie ze standardami, "spodziewać się" że reszta sieci też tak działa (niestety wiemy, że nie działa), czy też działać w nieomal 100% środowisk, ale przy "nagięciu zasad", by bezproblemową pracę uzyskać. Biorąc pod uwagę to, że nie każdy jest w stanie doprowadzić sieć do właściwego stanu, to jednak jestem za tym, by w uzasadnionych i bardzo nielicznych przypadkach "nagiąć zasady", by "żyło się lepiej" :)

Jedno z możliwych wyjaśnień tego, co się mogło stać: http://niebezpiecznik.pl/post/opis-grupy-atakujacej-ssh/ W związku z powyższym mocno zalecam, by osoby wystawiające odbiorniki "na świat" zrezygnowały z haseł które wydają im się że są bezpieczne i wygenerowały coś solidnego. Choćby przy pomocy http://www.dobrehaslo.pl/ sam tą stronę stosuje, wybierając "preset" dla paranoików, wyłączając znaki specjalne, a także zmieniając "małe litery" oraz "cyfry" na "małe litery i cyfry bez i,l,o,0,1". I oczywiście paranoicznie zmieniam jeszcze u siebie wygenerowany ciąg, przestawiając fragmenty tego co strona wypluła. Odpukać żaden z odbiorników, na których zastosowałem tego kalibru hasła nie został zainfekowany, a administruje nimi przez net już przeszło pół roku. Osobna sprawa, że każdy z nich inny zestaw dodatków niż @robert_cz.

też tak mi się wydaje, i zastanawia mnie jaki był wektor ataku, mógłbyś napisać, jakie dodatkowe wtyczki miałeś zainstalowane, może będzie się dało porównać z poprzednim takim przypadkiem, też zgłoszonym na forum, o ile Twój poprzednik o tym napisał.

Czasami też pomaga "tylko" przełączanie źródła hdmi w telewizorze. Średnio raz na miesiąc mój TV dostaje jakiś "śmieć" po HDMI, wskutek czego nie ma ani obrazu ani dźwięku, dekoder oczywiście działa w najlepsze. Przełączenie wejścia hdmi na inne i powrót na wejście na którym jest dekoder rozwiązuje problem na około miesiąc, do następnego takiego zdarzenia.

Cóż, wcale się nie dziwię, że pilot wariuje. Zainstaluj (o ile tego nie zrobiłeś) sobie nano by wygodnie edytować pliki zrób nano /etc/sysctl.gos zmień wartości z 100 i 20 na odpowiednio 120 i 50 i zrób odbiornikowi restart, to są ustawienia które wg moich testów powinny działać dla większości pilotów, kosztem szybkości uzyskano lepszą stabilność/uniwersalność.

nie odpalisz GOS na vu cała rodzina vu bazuje na zupełnie innej architekturze procesora niż ta, którą obsługuje GOS.

Nie, nboxy BSLA/BSKA mają dość podłą głowice o niskiej czułości, stąd przy długim kablu o nieznanych parametrach i konwerterze także "po taniości" możliwe są problemy z odbiorem. Są spore szanse, że wymiana konwertera na Inverto Black Ultra by pomogła.

jaki kabel? czy są gniazdka po drodze lub inne elementy? konwerter jakiej firmy?

nakłada się parę spraw: 1. z oscamami nowszymi od 10572 w pewnych specyficznych warunkach są problemy, np. z obsługą EMM, których (raczej?) nie ma na 10572, 2. jako że wyniki naszych wewnętrznych testów dla aktualnych wersji wypadają tak sobie, to są one mocno nieregularnie kompilowane, co "n" wersji, gdy zmiany w kodzie są potencjalnie obiecujące, 3. chwilowo z powodów rodzinnych mam cholernie mocno ograniczone możliwości czasowe, dlatego kompilacje są wrzucane do repo oscams i na forum zdecydowanie rzadziej, gdy są podstawy do przypuszczeń, że warto przetestować je, kod jest w danej chwili obiecujący. "Nasze" 10572 jest najwyższe rekomendowane/stabilne, także chodzi o routery. Co do kodu aktualnego, muszę stwierdzić brak problemów, a to... wymaga czasu, długich testów....

Nieśmiało zwracam uwagę, że zarówno pod Barrier Breaker jak i pod wcześniejsze środowisko "my" też robimy kompilacje. I zwracam uwagę, że jeśli ktoś w takim routerze używa kart conax, to ma wyciek pamięci jak w banku do wersji oficjalnej 10578 lub 10572 u nas.

wygląda na zawieszony na amen czytnik, restart odbiornika powinien pomóc, jeśli nie, to w skrajnym przypadku może być konieczne "halt" z konsoli, wyłączenie odbiornika, włączenie. milcząco zakładam że karta nie była wyjmowana/wkładana i przez przypadek nie została włożona na odwrót, ale jeśli mnie pamięć nie myli, to taki przypadek by wygenerował inne komunikaty o błędach.

Prawdopodobnie wgrałeś sobie ręcznie w miejsce systemowego pliku oscam (standardowo zastępowanego podczas aktualizacji) inną wersje z webif pobraną z forum. Trzeba było albo zdecydować się na wgranie pliku oscam_user, (wtedy by system Tobie OSCam'a "nie ruszył"), albo odinstalować zwykłą wersję przez opkg i też przez opkg zainstalować oscam-webif, wtedy aktualizacje by aktualizowały wersję webif. Po więcej odsyłam ---> tutaj <--- .

agrh, są tam gdzie wskazano oscamowi, jeśli korzystasz z naszych rozruchowych lub przykładowych konfigów to: /ram/oscam.log i celowo tam, bo inna lokalizacja mogłaby się przyczyniać do "zajeżdżania" NAND/NOR. Lokalizacje logów określa się w oscam.conf przy pomocy parametru logfile, przykładowo: logfile = /ram/oscam.log powoduje zapis logów do /ram/oscam.log

Nie jesteśmy wróżki. W większości wypadków przyczynę kłopotów z OSCamem daje się ustalić przy pomocy analizy logów. Owszem, domowy multiroom z wykorzystaniem WiFi może kuleć. Cóż, logi, logi, i jeszcze raz logi... bez logów z OSCama gdy to się dzieje szansa na ustalenie przyczyny problemu jest marna. Edycja: właśnie sprawdziłem ostatnie paręnaście nagrań robionych "z palca", na swoim uhd, jedyna różnica, że nagrania są robione na dysku sieciowym, na udziale CIFS. Linia "test". Zero problemów.

Jako tako poprawnie ustawić antenę, o precyzyjnie nie ma mowy. Miernik za 30 zł ze wskaźnikiem, to jak napisano wyżej, najwyżej pozwala wstrzelić się mniej więcej we właściwego satelitę. Bez b. dokładnej regulacji, bez sprawdzenia BER, MER itd., to o dokładnym ustawieniu nie ma mowy...

Zgaduje, że rozwiązaniem może być ten ---> wpis <--- w FAQ.