AbrahaM

dziękuję za test tytułem wyjaśnienia: przy okazji przebudowy / optymalizacji jednego z mechanizmów oscama odpowiedzialnego za "wstrajanie się" / łapanie kanałów, okazało się, że na części transponderów (tu podziękowania dla @Tata61) informacja o tym jakie kanały (oraz z jakimi CAID/PROVID itd.) są nadawane na transponderze jest wysyłana niezgodnie ze standardami. Konieczne było opracowanie poprawki na taką okoliczność...

czyli inny błąd, niż sądziłem, co do którego myślałem że już poprawili, zgłoszenie poszło. developer już nad tym siedzi, ale wygląda,że błąd jest z gatunku "grubszych". teoretycznie poprawiony, za parę minut (lub 30+) będzie w repo 11134, proszę o testy.

ależ wodzu, cóż wódz? http://pclab.pl/news66919.html http://www.dobreprogramy.pl/Nadchodzi-kumulacja-listopadowa-aktualizacja-Windowsa-10,News,68124.html http://betanews.com/2015/11/12/how-to-download-windows-10-with-the-november-update-and-create-your-own-installation-media/ aczkolwiek: "Windows 10 w kompilacji 10586, jako aktualizacja, już teraz jest udostępniany poprzez usługę Windows Update. Warto mieć na uwadze to, że dystrybucja aktualizacji odbywa się falami, tak więc jeśli u kogoś jej na liście Windows Update nie widać, to wystarczy uzbroić się w cierpliwość." polska wersja narzędzia do robienia pendrive/iso https://www.microsoft.com/pl-pl/software-download/windows10

zaraz poleci zgłoszenie, a na razie zalecam zostać na 11107

sprawdźcie obecne, teoretycznie błąd został wyłapany. linia "oscams" ma to do siebie, że może czasami wybuchać

aha, teraz jest mowa o czwartku / "tym tygodniu"

Z tego co pamiętam, nie da.

opóźniona o około tydzień, ma być 10 października.

według zaleceń GraterliaOS:~# opkg remove wget No packages removed. Collected errors: * print_dependents_warning: Package wget is depended upon by packages: * print_dependents_warning: enigma2-plugin-iptvplayer-src * print_dependents_warning: enigma2-plugin-iptvplayer-full * print_dependents_warning: These might cease to work if package wget is removed. * print_dependents_warning: Force removal of this package with --force-depends. * print_dependents_warning: Force removal of this package and its dependents * print_dependents_warning: with --force-removal-of-dependent-packages. sorry winnetu: ten sam adres czyli http://nbox.xunil.pl/index.php/Graterlia_OS_%E2%86%92_Historia_aktualizacji UWAGA - IPTVPlayer jest nie wspierany przez nas. Nie gwarantujemy jego działania! albo opkg remove enigma2-plugin-iptvplayer-full (ta wtyczka stała się niekompatybilna z Graterlia po 23cim) albo opkg remove wget --force-depends (ale wtedy prawdopodobnie w/w wtyczka przestanie działać) tytułem wyjaśnienia, w pewnych okolicznościach mogło się zdarzyć, że aktualizacja z 23 przeszła mimo pominięcia zaleceń dot. wget (choć mnie to bardzo dziwi, bo nie powinna), ale kolejne aktualizacje już żadną miarą nie mogą przejść. Poza tym, mam jednak wrażenie, że chyba Tobie ona w całości nie przeszła...

i będziesz miał na tych plikach (zwłaszcza oscam.dvbapi z generatora) zwiększone opóźnienie przełączania kanałów, o czym ostrzegam w odpowiednim dziale naszego forum, ale rób jak chcesz, wolnoć Tomku w swoim domu...

przeczytaj: http://forum.xunil.pl/index.php?topic=2566.msg35439#msg35439 i wypróbuj poradę stamtąd.

ale karta działa poprawnie - wykrywa ja i łączy się z siecią jak napisałem w UP po skrętce również zrywa mi oscama i ssh problem tkwi w czym innym po zmianie kanału i odczekaniu kilku sekund oscam załapuje, idą pakiety i nagle zaczyna działać też ssh po putty oraz ftp. Po paru minutach oglądania wszystko znowu się zawiesza i przestaje działać. ma ktoś instalkę poprzedniej wersji oscam ? podmieniłbym dla testów bo sądzę że ta nowa coś mi sieje zamęt. [*]wątpię by to była wina oscama. [*]różne rzeczy się mogą dziać, ale aktualny oscam nie powinien spowodować "pożerania" mocy obliczeniowej cpu w stopniu który by uniemożliwiał korzystanie z odbiornika. No chyba, że użytkownik ostro przekombinował w konfiguracji oscama z własnymi genialnymi ustawieniami, zmieniając parametr nice na zbyt wysoki co w połączeniu z innymi błędami niekiedy taki efekt może dać. [*]nie wykluczam, że to wina konfiguracji oscama, ostatnio na forum mieliśmy przykład jak to błędna konfiguracja robi efekty specjalne. Po wyeliminowaniu błędów w konfiguracji "nowy zły oscam" nagle zaczął wzorowo działać.

a ja się dołączę z ciekawym info, jest sobie: Kingston Data Traveler Workspace http://www.kingston.com/pl/usb/bootable, cytuję: "Ta pamięć USB 3.0 jest wyposażona w technologię kontrolera SSD, dzięki czemu oferuje wysoką wydajność i małe opóźnienia. Jest fabrycznie skonfigurowana jako dysk stały, więc umożliwia rozruch za pośrednictwem portu USB 3.0 lub USB 2.0 dowolnego sprzętu, który ma certyfikat zgodności z systemem operacyjnym Windows 7, 8, 8.1 lub Windows 10." Jest prawdopodobne, że inne systemy też by były w stanie z niej skorzystać, to raz, a dwa rozwiązuje to kwestię pracy Windows z nośnika USB. uprzedzam: dostępność marna, cena mordercza, około 350 zł za model 32GB.

Nie żebym się czepiał, ale gdybyś wrzucił cały log, lub większy fragment, to w paręnaście sekund by ktoś przyuważył tą pętlę restartów enigmy z logu oscama i rozwiązanie miałbyś wcześniej. Dobrze, że @mickey zwęszył co się dzieje.

bez obrazy, ale takim FRAGMENTEM logu, bez informacji o wersji oscama, to sobie możesz ścianę co najwyżej wytapetować.

No oczywiście że się cyrki zaczynają, jak wsadzisz w splitter/Clone. Jak Twoim zdaniem działa spliter? Pozwala na zapytanie jednej przez ileś urządzeń o ECMy. Splitter+odbiornik najprawdopodobniej przekraczają limit zapytań na jednostkę czasu, a jeśli tak, to nic z tym nie zrobisz. Jest jeszcze jedna możliwość, że "tylko" odbiornik ma kłopoty z dogadaniem się z splitterem, wtedy wyłączenie "autospeed" i ręczne eksperymentalne ustawianie parametrów mhz oraz cardmhz pomoże. Aczkolwiek nie ukrywam, że jestem pesymistycznie nastawiony.

Karty NC+ z CAID 0100 obsługują (już od jakiegoś czasu) równocześnie maksymalnie dwa zapytania naraz. Prawdopodobnie zapytań jest więcej, stąd przycinki. Nic z tym się nie da zrobić.

Nawet to nie kwestia innej interpretacji konfigów, tylko tego: "Problem z niestabilnością* czytnika po aktualizacji OSCama (wersji powyżej 101xx, dotyczy głównie, o ile nie wyłącznie kart NC+ w conax) Przez b. długi okres czasu kod obsługujący czytniki wbudowane w odbiorniki był częściowo wadliwy. Skutkowało to tym, że czytnik był "jakoś" ustawiany (na dobrą sprawę nie wiadomo nawet jak), ale na pewno nie na tych parametrach, które zadeklarował użytkownik. W nowych wersjach OSCama zostało to naprawione. Niestety jednym ze skutków tej zmiany jest to, że ustawienia dla kart (zwłaszcza kiepskich) które były wcześniej dobre, stały się ustawieniami wadliwymi. Drogą prób i błędów należy znaleźć ustawienia, które będą prawidłowe. Bez tego możliwa jest sytuacja, że czytnik będzie się zawieszał / odpowiadał "not found" w skrajnych wypadkach nawet po parunastu minutach pracy." proszę bardzo.

po pierwsze: inactivitytimeout = 30 w w fizycznym czytniku to błąd. po drugie: wyłączenie autospeed i ustawienie ręcznie taktowania karty to gdzie jest? proszę mi tu nie pisać, że o tym nie ma informacji, jest zarówno tutaj, na dole pierwszego wpisu jak i tutaj, na samej górze. po trzecie: jeśli masz tylko kartę conax, to oscam.dvbapi powinno wyglądać przynajmniej tak: P:0B01:000000:::0000 # N I: 0 jeśli masz więcej, to powinno być tam tylko to, co masz, nic "na zapas".

ależ proszę bardzo :) Twój konfig był ostro przekombinowany. Im więcej ustawień odbiega od "standardu" tym większe prawdopodobieństwo, że coś będzie się z czymś gryźć, gdyż część opcji/parametrów w oscamie jest wzajemnie zależna. Teoretycznie powinienem dokładnie ustalić która opcja "bruździła", ale na to po prostu prozaicznie pisząc nie za bardzo miałem/mam czas.

krótkie pytanie, mógłbyś przejść na próbę inny protokół? skądinąd (czytać: od developerów) wiem, że z newcamd/mgcamd są problemy. poza tym, w ramach sprzątania sugeruję wywalić: [global] clienttimeout = 20 bindwait = 20 netprio = 1 waitforcards = 0 [cache] max_time = 500 i wykomentować lb_nbest_readers = 2 lb_nfb_readers = 3 lb_reopen_seconds = 50 lb_retrylimit = 1500

wszystko fajnie, tylko to nie ma najmniejszego związku z wersją oscama. masz albo źle ustawione priorytety w dvbapi albo źle ustawione czytniki. to że kiedyś "jakimś cudem" działało, mimo że nie powinno, to nie argument. lecimy dalej: preferlocalcards = 1 gdy nie masz ani jednego lokalnego czytnika jest błędem lb_nfb_readers = 3 nie może być większe niż liczba czytników z wpisanym fallback, masz 2, tu wpisane trzy użytkownik dvbapi w oscam.users, błąd na błędzie caid = 0100,0B00,0B01,1801,1803,1861 keepalive = 1 tego nie należy ustawiać na użytkowniku realizującym funkcję dvbapi. tak samo jak nie wolno się na niego logować z zewnątrz... w żadnym czytniku nie ma ustawionego inactivitytimeout, który powinien być wyższy niż najrzadziej idące zapytania o ECM, co dla kanałów xxx wynosi 25 sekud, czyli inactivitytimeout powinno wynosić przynajmniej (z zapasem) 30 inactivitytimeout = 30 do tego do wywalenia disableserverfilter = 1 nice = 10 no wprost genialnie, wyższy priorytet na oscama niż na procesy systemowe w tym... openpli/enigma2 jestem zdziwiony, że to w ogóle Tobie działało...

może masz pikony? one często sporo zajmują... może nieopatrznie zapisujesz logi oscama do NAND? może nieopatrznie zapisujesz EMMy które spadają na kartę do NAND?

No to miałeś szczęście, upiekło Ci się. Na przyszłość czytaj historię zmian. Zazwyczaj można system aktualizować normalnie, ale raz na jakiś czas zdarzają się aktualizację wymagające od użytkowników postępowania wg określonych procedur, bo inaczej może aktualizacja się nie powieść.

zacznę od końca: teraz to jest "po herbacie", jak miałeś szczęście, to nawet pomimo pominięcia przez Ciebie zaleceń, czyli: opkg update /etc/rc.d/init.d/gui stop opkg remove wget (o ile jest zainstalowany!) - UWAGA - nie wolno ponienąć tej czynności!!!! opkg upgrade opkg remove --autoremove libp11-kit (o ile jest zainstalowany) a konkretnie drugiego kroku / zatrzymania gui, aktualizacja mogła (ale nie musiała) przejść prawidłowo. zaś Twój problem z brakiem możliwości zalogowania się wynika z nie przeczytania wpisu z historii zmian: [ready] optymalizacja pakietów OpenSSH: ◦pakiet openssh (zawiera: ssh-keygen, ssh-keyscan); ◦pakiet openssh-server (zawiera: sftp-server, sshd-keygen, ssh-keysign, ssh-pkcs11-helper, sshd); ◦pakiet openssh-clients (zawiera: scp, sftp, slogin, ssh, ssh-add, ssh-agent); oraz informacji tuż pod nim, cytuję: Po tej aktualizacji, jeżeli było zainstalowane OpenSSH należy zainstalować openssh-server aby mieć możliwość połączenia z tunerem oraz (jeżeli potrzeba tej funkcjonalności) openssh-clients aby mieć możliwość łączenia się z poziomu boxa z innymi serwerami SSH. Aktualizacja dobiegła końca (nie wiadomo z jakim wynikiem, czy w całości) po openssh się nie wbijesz, bo nie masz openssh-server, telnet nie działa, bo openssh przy starcie systemu jeszcze działało. Nie masz możliwości zdalnie zrestartować odbiornika. Pozostaje albo (o ile zadziała) nacisnąć pięciokrotnie przycisk włącz/wyłącz na pilocie (obudowie też?) lub wyłączyć i włączyć odbiornik. Po restarcie (pod warunkiem że się nic nie "posypało") być może będziesz mógł zalogować się na odbiornik telnetem. Po zalogowaniu (o ile to będzie możliwie, a to wcale nie jest pewne) będziesz mógł kontynuować porządkowanie odbiornika. Dla pewności zalecam: opkg update opkg install -force-reinstall openssl opkg install -force-reinstall openssh opkg install openssh-server a potem opkg list-upgradable jeśli zobaczysz długą listę pakietów do aktualizacji, to będzie to znaczyć, że aktualizację należy ponowić, wtedy robisz: /etc/rc.d/init.d/gui stop opkg upgrade jeśli będzie raptem parę pakietów, to wystarczy samo: opkg upgrade jeśli nic nie będzie, to być może miałeś szczęście i odbiornik ma sprawny system. Jeśli nie będziesz w stanie zalogować się na odbiornik, cóż... będziesz musiał wgrywać system do odbiornika od nowa.