AbrahaM

wcale, czyli boxtype ma być "none" w webif pmt_mode 1 lub 6

Proszę bardzo. Przy okazji potwierdziłeś istnienie błędu, który wykryłem wcześniej. Zajmiemy się tym.

niech zgadnę, ustawiasz przy pomocy kreatora tryb 1080@50p? podczas następnej próby instalacji wybierz dowolny inny tryb, a następnie już po normalnym uruchomieniu odbiornika przestaw na właściwy.

Zacznij od próby użycia innego pendrive.

"go for it"

my tu gadu-gadu, a wygląda, że wyszedł świeży babol w OW/openpli/e2. Bo mam silne przekonanie, że "wcześniej" widziałem prawidłowo raportowany BER przez OW.

hm, z tego co obserwowałem, to nie każda skórka prawidłowo wyświetla ber, natomiast raczej prawidłowy ber powinien być widoczny na open-webifie, oczywiście jeśli jest doinstalowana wtyczka do enigmy.

po dopisaniu paru parametrów można próbować diagnozować czy to aby nie problem z softem. ale na Twoim miejscu zacząłbym od otwarcia obudowy i dokładnej wizualnej kontroli wyglądu kondensatorów.

być może w środku nocy ktoś zaczyna coś transmitować. jakieś LTE czy coś. co by tłumaczyło, czemu to się pojawia tylko wtedy...

oczywiście NIE, prawdopodobnie programowanie się nie powiedzie, [pomijając to, że ma prawo normalnie trwać długo - długo tj. 30 do 90 minut] prawdopodobnie winny jest uszkodzony pendrive, lub źle współpracujący z odbiornikiem.

Wtedy, tak samo jak i teraz: pech. Nie każde brutalne wyłączenie będzie ubijać uboot, ale takie ryzyko w takim wypadku istnieje. Możliwe wyjścia z sytuacji (w zależności od rodzaju dekodera, z zasilaczem wbudowanym lub zewnętrznym), byle UPS lub zasilacz buforowy.

W zależności od tego, jak było ESI/UHD przerabiane, od około 30 minut - do prawie 90 minut.

wymagane załadowanie/zainstalowanie kernel-modules-cpufreq-gos i enigma2-plugin-graterlia-manager by to łatwo przestawiać z pilota, w odpowiedniej sekcji,

o to to, z tego co pamiętam swoje testy na stadku swoich testowych uhd, to górna "zazwyczaj bezpieczna" wartość podkręcania uhd wynosi 650 MHz

być może problem leży w oscam, obsłudze dvbapi, przestaw jednorazowo logowanie oscama w inne miejsce niż /ram/costam.log, po czym wklej zawartość logu od momentu zmiany kanału na rai.

OSCam r11245-1 multipatch_v6.2.7e UWAGI: Kompilacja zawiera patche: statuslabel_v3.12 (własny patch, zmodyfikowany pod zmianę w 10538), defaultstweak_v1.57 (własny patch pod wersje 10634+, modyfikujący wartości domyślne istotnych dla Graterlia OS parametrów), patch cccam-ignoregoodbad (bazujący na zmianie 10633) oraz patch no_ccache, umożliwiający włączenie/wyłączenie funkcji channelchache oraz patch maxservices, zwiększający liczbę możliwych do dodania w ramach serwisu sidów (z poprawką uwzględniającą obecny limit sid po protokole cccam). W związku z tym, iż sporo użytkowników używa nie zaktualizowane wersje oscam oraz "oryginalnego" cccam, z poważnymi błędami w obsłudze kanałów które mają być (lub nie być) obsługiwane, nasze kompilacje najpierw posiadały aktywną zmianę 10634, zaś aktualnie kompilowane są z patchem cccam-ignoregoodbad dostosowanym do aktualnego kodu, będącym funkcjonalnie odpowiednikiem zmiany 10633). Patch wprowadza w czytniku cccam, w sekcji parametrów dotyczących tylko tego protokołu pole Ignore good/bad, które domyślnie ma wartość 1, co oznacza że oscam "ma w nosie" listę obsługiwanych i nie obsługiwanych kanałów. Jeśli użytkownik wie, że oscam/cccam po drugiej stronie działa w sposób prawidłowy, to powinien tą opcję wyłączyć. Ta wersja w części przypadków może eliminować problem z nagrywaniem plików TS o zerowej długości, gdy użytkownik używa własnej karty i ma cały czas włączone łapanie uprawnień. Do całkowitego usunięcia tego problemu jest konieczna aktualizacja oprogramowania do stanu z 08 grudnia 2015. Ponadto wyeliminowany został problem z "szatkowaniem" nagrań z powodu nie respektowania wpisów w oscam.dvbapi od momentu rozpoczęcia nagrywania. Scalono wiadomość: [time]1489424028[/time] OSCam r11272-1 multipatch_v6.2.8e UWAGI: Kompilacja zawiera patche: statuslabel_v3.12 (własny patch, zmodyfikowany pod zmianę w 10538), defaultstweak_v1.57 (własny patch pod wersje 10634+, modyfikujący wartości domyślne istotnych dla Graterlia OS parametrów), patch cccam-ignoregoodbad (bazujący na zmianie 10633) patch disable_enable_ccache-v4, umożliwiający włączenie/wyłączenie funkcji channelchache, patch maxservices, zwiększający liczbę możliwych do dodania w ramach serwisu sidów (z poprawką uwzględniającą obecny limit sid po protokole cccam) a także patch ecmtimeoutlimit, dodający do czytników możliwość ich resetu po określonej przez użytkownika liczbie timeoutów. W związku z tym, iż sporo użytkowników używa nie zaktualizowane wersje oscam oraz "oryginalnego" cccam, z poważnymi błędami w obsłudze kanałów które mają być (lub nie być) obsługiwane, nasze kompilacje najpierw posiadały aktywną zmianę 10634, zaś aktualnie kompilowane są z patchem cccam-ignoregoodbad dostosowanym do aktualnego kodu, będącym funkcjonalnie odpowiednikiem zmiany 10633). Patch wprowadza w czytniku cccam, w sekcji parametrów dotyczących tylko tego protokołu pole Ignore good/bad. Brak zaznaczenia, to standardowa praca CCCAM (wartość domyślna), zaznaczenie oznacza że OSCam "ma w nosie" listę obsługiwanych i nie obsługiwanych kanałów przekazywanych przez CCCAM. Jeśli użytkownik wie, że OSCam/CCCAM po drugiej stronie działa w sposób nieprawidłowy, to powinien tą opcję włączyć. Ta wersja w części przypadków może eliminować problem z nagrywaniem plików TS o zerowej długości, gdy użytkownik używa własnej karty i ma cały czas włączone łapanie uprawnień. Do całkowitego usunięcia tego problemu jest konieczna aktualizacja oprogramowania do stanu z co najmniej 08 grudnia 2015. Ponadto wyeliminowany został problem z "szatkowaniem" nagrań z powodu nie respektowania wpisów w oscam.dvbapi od momentu rozpoczęcia nagrywania. oscam-r11245-1.doc.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-allond.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-libusbd.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-libusbd-nodebug.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-libusbd-nodebug-nowebif.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-nolibusb-phoenix.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-nolibusb-phoenix-nodebug.zip oscam-r11245-1-sh4-multipatch_v6.2.7e-nolibusb-phoenix-nodebug-nowebif.zip oscam-r11272-1.doc.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-allond.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-libusbd.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-libusbd-nodebug.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-libusbd-nodebug-nowebif.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-nolibusb-phoenix.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-nolibusb-phoenix-nodebug.zip oscam-r11272-1-sh4-multipatch_v6.2.8e-nolibusb-phoenix-nodebug-nowebif.zip

Absolutnie niemożliwe, by to "się zrobiło samo", albo ktoś zrobił Tobie złośliwy kawał, albo złapałeś wirusa, który zainfekował odbiornik, parę takich przypadków raportowano nam na forum. O ile jeszcze z trudem można by przyjąć, że "coś się stało" w wypadku logowania się przez ssh, winscp i na webif odbiornika, o tyle fakt obecności hasła na webif oscama to wyklucza, bo jest ono definiowane w plikach oscama a nie systemowych, więc... stawiałbym na pierwszą opcję... Nie wiem, musisz poczekać, aż ktoś mądrzejszy ode mnie się wypowie...

coś mi się wydaje, że zainstalowaliście Panowie, GOS "Core", które jest "zrób to sam", czyli po uruchomieniu należy sobie zainstalować to, co chce się mieć w odbiorniku a powinniście (zakładając, że chcecie mieć "gotowy" system) GOS "Image", które jest mniej więcej odpowiednikiem poprzednich obrazów, bo więcej rzeczy jest "domyślnie" wgranych,

Szklana kula się stłukła. A logów z pracy oscama (domyślnie przy naszych konfigach w /ram/ w pliku oscam.log) nie ma, więc wróżby z diagnozą nie będzie.

Czyli wnioski są dość zbieżne Ty piszesz o około 4 (z możliwością na więcej) na antenie 110cm, a ja przewidywałem z biedą 4 na antenie 90cm.

rzuć sobie okiem na: od 5 minuty masz zrzuty z konfiguracji odbiornika, zwykłą anteną 90cm, to za bardzo nie nawojujesz, z tego co pamiętam do 4 pozycji orbitalnych by się dało, mocno kombinując i bez gwarancji rozsądnej jakości odbioru.

... który to Amiko A3 z amiko obsługiwanym przez GOS wspólną ma wyłącznie nazwę. Inne podzespoły w środku.

używać aktualnego systemu. po poprawkach w OSCAMie oraz w systemie nagrań o zerowej długości nie powinno być od około listopada zeszłego roku. restartować system po aktualizacjach, oczywiście dopiero po upewnieniu się o ich poprawności. zakładając nagrywanie "na sieć", mieć prawidłowo ustawione wpisy w pliku auto.network. możesz mieć (przykład z powietrza, z danymi służącymi tylko ilustracji, dla samby/cifs): # automatically generated by enigma 2 ADB5800SX -fstype=cifs,rw,user=root,pass=XXX ://192.168.100.106/movies a powinieneś mieć # automatically generated by enigma 2 ADB5800SX -fstype=cifs,rw,noatime,noserverino,iocharset=utf8,username=root,password=XXX ://192.168.100.106/movies dodatkowa edycja: by była jasność, chodzi o to, by w linii z definicją udziału sieciowego koniecznie było: noatime,noserverino,iocharset=utf8

złe ustawienia? bez logów można tylko zgadywać. proponuję zapoznać się z: http://forum.xunil.pl/index.php/topic,2119.0.html

może byś tak przeczytał opis zmian związanych z nową edycją? podpowiedź: od teraz soft dla ESI i UHD jest ujednolicony / wspólny.