AbrahaM

a to, to co? https://forum.xunil.pl/index.php/topic,2766.msg46678.html#msg46678 oscam-r11272-1-sh4-...... oscam-r11350-1-mipselvu-...................... hm, ciekawe, wyparowały sh4, wgrane ponownie oscam-r11350-1-sh4-multipatch_v6.2.10e-allond.zip

a to, to co? https://forum.xunil.pl/index.php/topic,2766.msg46678.html#msg46678

Użyj którejś 11350 "z forum" i daj znać jaki jest wynik.

mickey[/member] Teoretycznie to jest możliwe Tzn. że na git już zmiana jest, natomiast skompilowane binarki są starsze i jej nie zawierają. Ale to by trzeba było zweryfikować.

a oscam zainstalowany jest? co zwraca opkg list-installed | grep oscam jeśli nic, to opkg install oscam-webif-gos

jeśli ma chodzić absolutnie stabilnie, bez zawieszeń, tak, na zewnątrz phoenix, w wewnętrznym można tylko lepiej lub gorzej reagować na zawieszenie.

bez zmian, karty conax jak pracowały prawidłowo w czytnikach zewnętrznych, tak pracują nadal, miewały humory w czytnikach wbudowanych w odbiorniki, tak mają nadal, zalecenia dotyczące konfiguracji są bez zmian, zalecane wersje OSCam 11272 lub 11350, za wyjątkiem osób które nieopatrznie nabyły odbiornik z modchipem, wtedy jest to 10551.

dograć, podpowiedź, hasło: frontpanel

OSCam r11350-1 multipatch_v6.2.10e 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-r11350-1.doc.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd-nodebug.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd-nodebug-nowebif.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-nolibusb-phoenix.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-nolibusb-phoenix-nodebug.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-nolibusb-phoenix-nodebug-nowebif.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-allon.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd-nodebug.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd-nodebug-nowebif.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-nolibusb-phoenix.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-nolibusb-phoenix-nodebug.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-nolibusb-phoenix-nodebug-nowebif.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd-nodebug.zip oscam-r11350-1-mipselvu-multipatch_v6.2.10e-libusbd-nodebug-nowebif.zip oscam-r11350-1-sh4-multipatch_v6.2.10e-nolibusb-phoenix.zip oscam-r11350-1-sh4-multipatch_v6.2.10e-nolibusb-phoenix-nodebug.zip oscam-r11350-1-sh4-multipatch_v6.2.10e-nolibusb-phoenix-nodebug-nowebif.zip

OSCam r11350-1 multipatch_v6.2.10e UWAGI: Kompilacja zawiera patche: statuslabel_v3.12 (własny patch, zmodyfikowany pod zmianę w 10538), defaultstweak_v1.58 (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 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ć. oscam-r11350-1.doc.zip oscam-r11350-1-mips-ar71xx-openwrt-aa-multipatch_v6.2.10e-terminal.zip oscam-r11350-1-mips-ar71xx-openwrt-bb-multipatch_v6.2.10-terminal.zip oscam-r11350-1-mips-ar71xx-openwrt-cc-multipatch_v6.2.10e-terminal.zip oscam-r11350-1-mipsel-ramips-mt7620-openwrt-cc-multipatch_v6.2.10-terminal.zip oscam-r11350-1-arm_cortex-mvebu-openwrt-cc-multipatch_v6.2.10e-terminal.zip oscam-r11350-1-arm_brcm-ddwrt-multipatch_v6.2.10e-terminal.zip

Przypuszczalnie by odtwarzać nagrania inne niż nagrane na odbiorniku potrzebujesz wgrać któryś z poniższych z zestawów wtyczek dla Gstreamer'a gst-plugins-bad-gos - 1.10.1-4 - Plugins bad free for GStreamer gst-plugins-good-gos - 1.10.1-4 - Plugins good for GStreamer gst-plugins-ugly-gos - 1.10.1-4 - Plugins ugly for GStreamer Teoretycznie możesz wgrać je wszystkie "na wszelki wypadek" / "zapas", albo wgrywać po jednym i sprawdzać który zestaw był Tobie potrzebny.

Ja tu widzę potencjalnie dwie sprawy, jakość kondensatorów to jedno, jakoś projektu/konstrukcji odbiornika to drugie. Nawet najlepsze kondensatory Ci nic nie pomogą, jeśli projekt (obciążenia, chłodzenie) jest niepoprawny, a to jest możliwe. Do tej pory mam "rezerwowy" zasilacz do komputera, który ma już ponad 5 lat i jedyne co z nim musiałem robić, to wymienić zajechany na śmierć (przestał się kręcić) wentylator. Kondensatory w nim to Chemi-Con'y przewidziane do pracy z temperaturami do 105° C...

tak, już o tym pisałem, spark (albo przynajmniej ten spark mój) ma konfiguracje głowic następującą: głowica A: DVB-T/DVB-C głowica B: DVB-S2 głowica C: DVB-S2 FastSearch 1.5 zobaczył głowicę B i chyba żadnej pozostałej, tj. nie mogłem przełączyć na inną, chyba że źle to robiłem, co też jest możliwe. BTW: nowe VU+ mają na tyle dużo mocy obliczeniowej, że mogą radzić sobie z wieloma strumieniami, a co istotne można do nich dołączyć głowice DVB na USB, więc zmuszenie FS do obsługi dowolnej głowicy z dowolnej ilości byłoby mocno przydatne...

Taa. I problem z tym wbiciem na sztywno A jest, bo taki spark na A ma głowicę DVB-T/DVB-C. Co do komunikatów, zaraz zrobię Ci zrzuty z ekranu i podczepię do tego wpisu. Podpięte. Komunikat z wyniku skanowania też jest po polsku.

tequila[/member] Bo pomijając fakt, że FastSearch korzysta na twardo z głowicy A (przez co na niektórych tunerach nie zadziała wcale), to działa prawidłowo... TomTelos[/member] Potwierdzam działanie FastSearch na UHD88, oczywiście z głowicy A. Po dorobieniu automatycznej detekcji głowic lub ręcznego wyboru głowicy wtyczka będzie "prawie" całkiem OK. Prawie, bo część komunikatów jest "na twardo" napisana po polsku. Przełącz się na język angielski i zobaczysz niespodziankę...

Krótko: masz iptvplayer, masz problem. Nie wdając się w szczegóły: nie zmodyfikowany iptvplayer rozwala GOS, zaś modyfikacja iptvplayer z mocy zapisów licencyjnych iptvplayer'a nie jest dozwolona, więc nie możemy go poprawić by GOS nie rozwalał. Można przypuszczać, że przyczyną Twoich problemów z odbiornikiem jest iptvplayer.

aprf. moje niedopatrznie. wydawało mi się, że napisałeś, że nie zajmiesz, podwójna negacja mnie zmyliła.

Sugeruje jednak przemyślenie tej kwestii. Z moich obserwacji wynika, że procentowo całkiem spora ilość użytkowników (ta, która wie, że może z tego korzystać, że może odpowiednią paczkę dosintalować), z CEC korzysta. Nie każdy musi chcieć kupować pilota za (najtaniej, wg CENEO) 200 zł, żeby móc wygodnie razem z satelitą wyłączyć telewizor...

Tylko w zestawie bukietów od myszka20 bukiet NC+ "nie trzyma" układu i numeracji operatora. Dla sporej ilości osób jest jeśli nawet nie konieczne, to co najmniej mocno mile widziane...

Pozwolę sobie na bycie adwokatem diabła. 1. To że u Ciebie działa ten kabel, to nie znaczy że u niego będzie. 2. CT63 10 lat temu przestał być używany przez Sky i został zastąpiony przez WF65 (a CT 100 przez WF100), jeśli ktoś sprzedaje CT63, to można mieć obawy że albo jest to podróbka albo wiekowy leżak magazynowy. Źródło: https://en.wikipedia.org/wiki/Coaxial_cable 3. Zgodnie ta stroną http://www.satcure.co.uk/tech/cable.htm ten kabel (czytać CT63/WF65) jest kablem, który jest dobry, bo jest tani. Interpretacja moja. 4. Dokopałem się do (niepełnej!!) specyfikacji: http://www.satcure.co.uk/tech/cablespecs.htm 5. Z danych z punktu 4 wynika że najbliżej do triset'ow kablowi WF125 pod względem tłumienności, cała reszta jest nieco gorsza, zaś CT63, WF65 SĄ TRAGICZNE (caps zamierzony), tłumienie dla pasma 2000MHz 48.6 to wynik prawie dwukrotnie gorszy od WF125/trisetów. Przy czym zwracam uwagę że dokładnej informacji o ekranowaniu nie ma, jest tylko informacja że spełniają wymóg minimum 85dB tłumienia więc to na pewno klasa A, ale triset-113 ma wyniki między klasami A i A+, zaś triset profi to klasa AA+. 6. Cytat który potwierdza moje wnioski: "Thin shotgun cable is easier to install but also more lossy than regular sized cable. Sky's own install guidelines recommend this for runs no more than 10 metres", źródło: https://forums.overclockers.co.uk/showthread.php?t=18510627 Fakt, więcej niż 10 metrów nie będzie, ale i tak średnio 2x większa tłumienność przy łapaniu hotbirda może już być odczuwalna. 7. TVP1 i TVP2 w wersji SD chyba faktycznie zostały wyłączone.

jordi[/member] po kolei 0) W tej sytuacji zakup online z polski jest dobrym pomysłem. 1) Moim zdaniem warto, nie ze względu na tłumienność tylko na ekranowanie, które Triset Profi ma rewelacyjne. Masz większe szanse że "obcy" sygnał zakłócający przekaz satelitarny "nie wejdzie", przy tak krótkim odcinku różnica w cenie będzie nieistotna. Nie wiem(y) czy problem u Ciebie jest z powodu jakiejś usterki czy zakłóceń, to przynajmniej zminimalizuje potencjalny wpływ zakłóceń. 2) Nie istnieją, musisz go wtedy kupić odpowiednio więcej, jeśli byś chciał quattro czy quad (+ ewentualne DVB-T(2)), to musiałbyś go kupić x4 lub x5. 3) Przy prawidłowo założonych złączkach istotnych różnic nie powinno być. natomiast złączki kompresyjne zabezpieczają Ciebie przed pogodą. Nic nie zaśniedzieje, nie zacznie się np. dostawać woda do kabla, itd. Moim zdaniem warto to w miarę możliwości (z)robić.

albo mnie pamięć myli, albo opkg install graterlia-sat

U mnie dotyczyło to całości, ale znane są mi przypadki "wariowania" konwertera tylko z jednej polaryzacji lub w określonym paśmie (górnym lub dolnym). Jeśli się okaże, że jednak problem nawraca, to szukaj speca z cyfrowym miernikiem podającym parametry (BER, MER, itd.), wiedzącego co to złączki "kompresyjne". I módl się, żeby to nie były okresowe zakłócenia od transmisji w paśmie LTE. Oczywiście nieodmiennie polecam też brać pod rozwagę wymianę kabla (to że jest być może sprawny, to nie znaczy że jest dobry), o ile nie masz czegoś o parametrach co najmniej w klasie A. Nieodmiennie polecam triset 113 lub Triset Profi, gdyż to są kable z bardzo dobrą skutecznością ekranowania przed wpływem sygnałów zewnętrznych przy równocześnie dość niskiej tłumienności. I nie przesadź z konwerterem, jeśli będziesz go wymieniał. Przy 7 metrach kabla wsadzenie Inverto Black Ultra może skończyć się także problemami, ze względu na ... zbyt silny sygnał i przesterowanie głowic. Inverto Black Premium to maksimum co widziałbym u Ciebie.

Obstawiam winę instalacji. Pytanie tylko czy wiatr lekko przestawił antenę, czy konwerter postanowił działać, czy też np. gdzieś Ci się kabel przetarł i akurat teraz chodzi... Mnie się zdarzyła awaria dokładnie tego samego modelu konwertera co u Ciebie, generująca objawy "pojawiam się i znikam", czyli potrafił losowo parę godzin działać prawidłowo, potem przez losowy czas nie działać, znowu losowo działać i tak w kółko...

Nie zatrzyma / nie stracisz. Wielokrotnie praktykowane osobiście.