AbrahaM

Od siebie dodam, że warto "poświęcić" dane EPG i przed aktualizacją ręcznie skasować epg.dat, który po dłuższym używaniu systemu może mieć spory rozmiar i przyczynić się do niepowodzenia aktualizacji. Niedawno taka sytuacja miała miejsce u znajomego.

Witaj, Hm, mocno ciekawe. Ten błąd w zasadzie został wyeliminowany do dnia jakiś rok temu. Zakładając, że masz zaktualizowany poprawnie system, to nie powinien mieć miejsca. Jeszcze rozumiem, gdyby problem dotyczył nagrywania "na udziale sieciowym" i odbiorników "spark 7162", owszem wiemy że błąd takiej sytuacji dotyczy. Po święcie przypomnij mi się w tym temacie, spróbujemy zrobić diagnostykę, może coś się uda ustalić. Pozdrawiam,

No i teraz mamy jasność. Aktualne binarki u nas zakładają w systemie obecność openssl (dostarczającego bibliotekę libssl) w wersji 1.0.x. Stare wersje OSCam, lub OSCam nie od nas, jak widać "wymagają" starej biblioteki libssl, której u nas nie ma.

Bez logów, w których powinna być przyczyna czemu nie łączy, to już nic nie wymyślę. Z tego co widzę, to powinno teraz już ruszyć.

reshare = -1 A drogi użytkownik się dziwi, że nie działa. No to teraz w ramach niesienia kaganka oświaty: http://www.streamboard.tv/wiki/OSCam/en/Config/oscam.conf#reshare <---- co tam widzimy? -1 = no resharing Poza tym, na kliencie nieużywane czytniki powinny być wyłączone lub usunięte, gdyż w niektórych sytuacjach (w zależności od paru parametrów) mogą przyczyniać się do kłopotów. Generalnie konfig wygląda dziwnie, na niepotrzebnie udziwniony, ale po poprawieniu tego co napisałem wyżej, powinien zacząć jako tako działać.

jeśli dobrze pamiętam, to openwebif od jakiegoś czasu wymaga hasła zawsze, nie wpuści użytkownika jeśli hasło nie jest ustawione, jeśli mam rację to ustawienie z konsoli hasła (poleceniem passwd) dla root rozwiąże problem, logować się na openwebif będziesz userem root i ustawionym hasłem.

Nie wiem czemu chce, ale mnie ten układ ze zrzutu z ekranu także się bardziej podoba. :) Bo tak.

Nie trzeba. Jeśli są problemy z wstawaniem po restarcie, to trzeba przyjrzeć się parametrom, czy są ustawione prawidłowo, czy taktowanie jest właściwe. W normalnych warunkach phoenix chodzi absolutnie bezproblemowo.

Nie mam VU+, ale opkg list zwraca w wynikach m.in. vuplus-checkvfd - 1.0 - Check vfd firmware vuplus-displayvfd - 1.0 - Vuplus-displayvfd obstawiam, że być może Tobie może być potrzebna druga z nich.

A odpowiednią wtyczkę obsługującą wyświetlacz wgrałeś? Keśli nie, to opkg list Twoim przyjacielem :)

osoby z tunerem z modchip proszę o przetestowanie czy r11377 (wrzucone na forum do wiadomego działu) będzie działać prawidłowo, czy też "jak zwykle" będzie problem z równoczesnym oglądaniem i nagrywaniem.

OSCam r11377-1 multipatch_v6.2.12e 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-r11377-1.doc.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-allond.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-libusbd.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-libusbd-nodebug.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-libusbd-nodebug-nowebif.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-nolibusb-phoenix.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-nolibusb-phoenix-nodebug.zip oscam-r11377-1-sh4-multipatch_v6.2.12e-nolibusb-phoenix-nodebug-nowebif.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-allond.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-libusbd.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-libusbd-nodebug.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-libusbd-nodebug-nowebif.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-nolibusb-phoenix.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-nolibusb-phoenix-nodebug.zip oscam-r11377-1-mipselvu-multipatch_v6.2.12e-nolibusb-phoenix-nodebug-nowebif.zip

"A po co"? dobrze skonfigurowany OSCam nie wymaga restartów.

Nazwą. W starym repozytorium paczka nazywała się enigma2-plugin-cec, w nowym enigma2-plugin-hdmicec.

Pogodzę was Panowie. Czas wgrywania softu do NOR w UHD/ESI zależy od tego czy przy okazji przerabiania osoba przerabiająca użyła pamięci tego samego typu, czy innego zgodnego ale szybszego. Z tego co wiem, różnice w ilości potrzebnego czasu na wgranie mogą być nawet rzędu 1:3

Proszę bardzo.

za to jest sagegom88, i to jest wspólne dla esi i uhd

Panowie jordi[/member] i 314TeR[/member] oba posty są merytorycznie ok. Wzięliście się za analizowanie sprawy. Tylko zapominacie, że macie do czynienia z adb5800. Te odbiorniki (we wszystkich odmianach) mają taktowanie CPU na poziomie 266MHz, plus brak sprzętowego RTC. Do tego dochodzi specyficzna obsługa układu sieciowego (angażującego CPU) i taka sobie obsługa USB. Obstawiam, że ze względu na opisane wyżej ograniczenia o streamingu audycji "HD" lub wysokiej jakości SD o streamingu na ad5800 należy zapomieć. ESI 88 czy "sparki" mają prawie 2x wyżej taktowane CPU (450MHz plus sprzętowy RTC, co umożliwia ewentualne OC), lepszą sieciówkę i lepsze USB... Generalnie, jeśli są ku temu możliwości, to zachęcam do migracji z adb 5800 na inne odbiorniki wspierane przez GOS.

Przy czym mimo :) na końcu, to jest absolutnie poważne stwierdzenie. Żeby móc coś wspierać, potrzebne są egzemplarze testowe. Dodanie czy utrzymywanie wsparcia dla odbiorników bez odbiorników jest w zasadzie niemożliwe...

Zacznę od wyjaśnienia niezbędnego detalu: VU+ które zaczęliśmy próbować wspierać jest na procesorach z rodziny mips32el, VU+ solo4k jest na procesorach z rodziny ARM, W przewidywalnej w miarę bliskiej przyszłości szanse na wsparcie dla kolejnej architektury, gdzie wszystko trzeba robić od nowa podstaw są mocno marne. W dalszej niewiele lepsze, o czym więcej być może będzie mógł napisać tux[/member]

Z kronikarskiego obowiązku wyjaśnienie. To co spotkało reset[/member] to jest błąd w OSCam'ie, występujący gdy jest wkompilowana w OSCam obsługa protokołu ipv6, ale system ipv6 nie obsługuje. Błąd został opisany i zgłoszony: http://www.streamboard.tv/oscam/ticket/4582 Dziękuję reset[/member] za zwrócenie uwagi na ten błąd, który już kiedyś został przez nas wykryty, ale potraktowany jako "do zgłoszenia na później".

oscam.pem nie ma się nijak do Twojego problemu. Jest to opcjonalny plik, wykorzystywany wyłącznie gdy ktoś postanowi dodać znak + (plus) przed numerem portu webif, uzyskując dzięki temu bezpieczne połączenie po httpS do OSCam'a. Tak samo nie ma się to nijak do wersji OSCam. Musisz poszukać błędów w konfiguracji u siebie, albo w OSCam, albo we wtyczce. Prawidłowo skonfigurowany OSCam współpracuje z prawidłowo skonfigurowanymi wtyczkami: 1) acamd 2) flycccam 3) hadu co osobiście swego czasu zweryfikowałem.

Zgadłeś. Magicznego rozwiązania jak do tej pory nie wynaleziono. Co do tego, że u Ciebie tak samo chodziły 770,780,790 to tylko pogratulować. Mnie są znane przypadki (w tym jeden osobiście), że dany odbiornik po dłuższej pracy na złym uboot stawał się stopniowo coraz bardziej niestabilny. Wgranie w niego drogą eliminacji i długich testów właściwego uboot rozwiązało problemy. Oczywiście z wyłączeniem znanego i lubianego pixelowania na głowicy A.

Którego należy używać? To zależy z jakim najlepiej działa Twój tuner. Generalnie trzeba testować na każdym egzemplarzu osobno. Czym się różnią? Taktowaniem. No właśnie, a czego to jest taktowanie ? Bo chyba nie proca ? Pamięci. I niestety tu nie działa zasada bezpiecznego wspólnego najniższego mianownika, która działa w wypadku komputerów typu PC. uboot w wypadku ESI/UHD musi być trafiony w punkt.

czyli się diagnoza potwierdziła, wiem(y), co było nie tak i na przyszłość nie będzie nie tak.