AbrahaM

cudnie, problem na oficjalnym (patcha na webif nie liczę) kodzie / trunku, których nie ma po patchu. to może być mój błąd, to był mój błąd, wywalam tamtą wersję, 9297 gotowe wisi, ale bez patchy na webif, zaraz wgram ponownie właściwe. co do readonly, nie, wyleciało mi to z głowy, skończyłem dłubanie i własne testy parę minut przed drugą w nocy :( dziś się za to wezmę. zaraz wygeneruje 9297 czyste (względnie: qdwf+slim) i z timepatchem (qdwf+slim+clockfix_9296) 9300 w odmianach jak wyżej

Dobrze wiedzieć. Z ważnych informacji Właśnie się pichci: 9276, 9276 z timepatchem, 9280, 9280 z timepatchem, od 9277 w oficjalny kod wprowadzono zmiany które bez timepatcha są neutralne, ale bez nich on nie działa... zapraszam do testów.

Z tym nie ma co polemizować, mądre słowa, ale niestety poniższe (celowo zacytowane osobno) domaga się reakcji. Niestety w tej kwestii nie masz racji, tylko ci się tak wydaje, a uzasadnienie znajdziesz we wcześniejszych postach tuxa i moich, choćby --> tutaj.

W timepatch jak sama nazwa wskazuje, zmienia się dużo spraw zw. z obsługą czasu, zależności czasowych. jeśli wiem o przypadkach, gdzie na PC czasami dwie sekundy nie starcza, to tym bardziej na odbiorniku to się może zdarzyć.

Pierwsze zaraz spróbuję odtworzyć u siebie, jeśli też wystąpi, zgłaszam. I tak w naszej 9256 mamy dwie poprawki na webif, których w trunk nie ma. Drugie, wydłuż sleep. Na różnych maszynach potrzebna jest różna wartość, ja ostatnio skłaniam się do sleep 3 jak bezpieczna wartość.

1) dziękuję, zgłoszenie zrobione, ten sam błąd potwierdza inny tester, 2) jak najbardziej to może być "zasługa" WiFi.

Niestety to zbieg okoliczności. Zapraszam do testu wersji 9172 tpreloadedv14tryfixtimeoutanotherapproach lub 9172 tpreloadedv14tryfixtimeout, ale z akcentem na ten pierwszy (ten drugi jest już wstępnie przetestowany). Dopiero w tych dwóch wersjach ten problem (najprawdopodobniej) został na dobre usunięty.

Cytując pewnego kabareciarza: "jesteś w mylnym błędzie". Timepatch powstał by rozwiązać problem z timeoutami spowodowanymi przez enigme2 synchronizującą czas odbiornika w oparciu o dane z transpondera. Jako że ten czas bardzo często potrafi się znacznie różnić, to przestawianie czasu w trakcie pracy oscama skutkowało niemiłymi efektami ubocznymi, jednym z nich były TOUT przy zmianie kanałów. W trakcie prac nad timepatchem okazało się, że kod obsługujący mechanizmy czasu w oscamie był... delikatnie pisząc daleki od tego, co być powinno, zmiany wpłynęły pozytywnie na wszystko, z przetwarzaniem ecm czy mechanizmami sieciowymi włącznie. Timepatch zastosowany na serwerze często poprawia (bardzo znacząco zmniejsza, pod pewnymi warunkami) ilość NOK i prawie do zera eliminuje TOUT. Niestety z naszych testów (i raportów forumowiczów) wynika też, że odbiorniki z zastosowanym timepatch gorzej współpracują z oscamami bez patcha i gorzej tolerują problemy z siecią. Jako, że to jest trudne do otworzenia w warunkach testowych, to dopracowanie tej kwestii pewnie zajmie trochę czasu, znając życie odbędzie w ramach serii poprawek optymalizujących, po tym jak patch wejdzie w kod. PS: za niedługo wrzucę 9172 oraz 9172 tpreloadedv13 i tpreloadedv14 różniące się przestawionym jednym parametrem w kodzie, proszę uprzejmie o testy "v14".

@5alive oscam.dvbapi i oscam.whitelist ustawione prawidłowo?

dzięki za raport. diabli... na całym stadzie ochotników ten błąd się nie pojawił :(

Dodam na szybko: Archiwum wersji zostało właśnie świeżo przeorganizowane. Pojawił się wątek z zalecanymi wersjami. Dla "konserwatystów" ;) zostało upichcone 8705 ntmd_newcamdlongecm i zamieszczone w wspominanym wątku. Tamże zostało właśnie zamieszczone 9071 w wersji która jest aktualnie używana w systemie. Mile widziana jest kooperacja w testach najnowszych wersji.

W tym wątku zamieszczane są/będą kompilacje sh4 oscam, które po długich testach uznaliśmy za (w większości wypadków) stabilne, przeznaczne dla odbiorników pracujących na systemie Graterlia. Jest to "czysta" kompilacja "sh4". OSCam w naszej kompilacji ma większość funkcji aktywnych, za wyjątkiem egzotycznych i/lub sporadycznie używanych protokołów, tj. camd3.3x, pandora, radegast, ghttp, scam i egzotycznych systemów kart (DRE Crypt, TONGFANG, Griffin, DGCrypt) oraz funkcji zbędnych w odbiorniku: cache_ex, anticascading, constantcw, monitor i CW Cycle Check. Zamieszczony niżej zestaw funkcji obsługiwanych przez nasze kompilacje jest/będzie stały. all/allon, w opkg dostępne jako oscam-full, zawiera wszystkie funkcje poza: IPv6 support: no libusb zawiera następujące funkcje: Web interface support: yes Touch interface support: yes SSL support: yes DVB API support: yes DVB API with AZBOX support: no DVB API with MCA support: no DVB API with COOLAPI support: no DVB API with STAPI support: no Anti-cascading support: no Irdeto guessing: yes Debug mode: yes Monitor: no Loadbalancing support: yes CW Cycle Check support: no LCD support: yes LED support: yes IPv6 support: no Cache exchange support: no camd 3.3x: no camd 3.5 UDP: yes camd 3.5 TCP: yes newcamd: yes CCcam: yes CCcam share: yes Pandora: no ghttp: no gbox: yes radegast: no scam: no serial: no constant CW: no Reader support: yes Nagra: yes Irdeto: yes Conax: yes Cryptoworks: yes Seca: yes Viaccess: yes NDS Videoguard: yes DRE Crypt: no - no EMM support! TONGFANG: no - no EMM support! Bulcrypt: yes Griffin: no - no EMM support! DGCrypt: no - no EMM support! cardreader_phoenix: yes cardreader_internal_azbox: no cardreader_internal_coolapi: no cardreader_internal_sci: yes cardreader_sc8in1: yes cardreader_mp35: yes cardreader_smargo: yes cardreader_pcsc: yes cardreader_smartreader: yes cardreader_db2com: no cardreader_stapi: no libusb-nodebug zawiera wszystkie funkcje powyższej wersji poza: Debug mode: no Funkcja debug potrzebna jest jedynie w wypadku konieczności diagnostyki ustawień i/lub zgłoszenia błędów do developerów oscama. W normalnych warunkach nie jest do niczego potrzebna, przyczynia się do spowolnienia pracy oscama. libusb-nodebug-nowebif zawiera wszystkie funkcje powyższej wersji poza: Web interface support: no Touch interface support: no Jak wyżej, webif jest miłym dodatkiem pozwalającym na wygodną kontrolę pracy oscam, lecz w normalnych warunkach nie jest do niczego potrzebny, także przyczynia się do spowolnienia pracy oscama, ponadto potencjalnie może przyczyniać się do niestabilnej pracy ze względu na ryzyko obecności błędów w kodzie webif. Dla osób nie korzystających z zewnętrznych czytników przewidziana jest lżejsza kompilacja, pozbawiona obsługi libusb i wszystkich zewnętrznych czytników: (nolibusb-phoenix, w opkg dostępne jako oscam-webif), o funkcjach jak wcześniejsza, poza następującymi różnicami: cardreader_phoenix: yes cardreader_internal_azbox: no cardreader_internal_coolapi: no cardreader_internal_sci: yes cardreader_sc8in1: no cardreader_mp35: no cardreader_smargo: no cardreader_pcsc: no cardreader_smartreader: no cardreader_db2com: no cardreader_stapi: no cardreader_stinger: no nousb-nodebug zawiera wszystkie funkcje powyższej wersji poza: Debug mode: no nousb-nodebug-nowebif, w opkg dostępne jako oscam, zawiera wszystkie funkcje powyższej wersji poza: Web interface support: no Touch interface support: no Jest ona standardową i rekomendowaną kompilacją do codziennego użytku w odbiornikach. Proszę o nie pisanie w tym wątku, uwagi/pytania proszę zamieszczać w tym wątku . Ze względu na przeraźliwie dużą ilość poprawek, zmian, optymalizacji nie udzielamy pomocy użytkownikom, którzy zdecydują się na używanie wersji OSCam'a starszych niż r11197. Aktualnie rekomendujemy używanie wersji r11197 sh4. Wkrótce ze względu na poważną aktualizację większości komponentów Graterlia OS użycie OSCam'a starszego niż r10980 będzie niemożliwe. Podstawowe informacje dotyczące "obsługi" od strony technicznej oscama znajdują się w IRAQ. Wersja uznana za stabilną oznaczana jest na zielono. Wersja zawierająca lub mogąca zawierać błąd występujący w bardzo egzotycznych warunkach, raczej nie dotyczących polskich realiów oznaczana jest na żółto. Nieprzetestowana wersja zawierająca istotne zmiany mogące mieć wpływ na stabilność jest oznaczona na czerwono. Po pomyślnych testach oznaczenie/kolor będzie zmieniane. Doniesienia o wcześniej nie wychwyconych problemach będą skutkować ponowną zmianą koloru.

By nie dopisał. Za to mod się z Tobą skontaktuje i pomęczymy razem devów, by to chodziło w aktualnym kodzie. To ma obowiązek chodzić na obecnej, zmuszanie się do pracy na starej nie jest wyjściem.

W ten sposób wiemy, że bez logowania paru na poziomach i posłania logów do autorów się nie obejdzie. Przy okazji, jak możesz (masz jak), to sprawdź jeszcze obie odmiany camd35 oraz cccam i gbox. Ten ostatni podobno dostał poprawki umożliwiające obsługę długich ecm. Co do problemu w lokalnym czytniku, cóż, jeśli w starej działa, to powinno się dać nową poprawić. Nawet mam pomysł do kogo imiennie z devów uderzać :)

... w dodatku bez patchów/dodatków, bez dopisków w nazwie.

Na dzieńdobry proponuję test najnowszej. Jeśli nie będzie działać, to będzie można przycisnąć autorów. Tyle, że będzie to wymagało kooperacji / logowania na odpowiednim poziomie na wersji debug.

Po nowym roku, podam na którym poziomie logowania, na 9164 + tpreloadedv8

Docelowo jednak myśl o ESI, zaś odpowiadając na Twoje pytania, użyję cytatów, forumowych informacji (by nie było, że sobie zasługi przypisuje): "Wiatrak zdecydowanie ma wydmuchiwać powietrze a nie wdmuchiwać" z nowego wentylatora podłączasz dwa: "Czarny minus, czerwony plus" jeden z polecanych wentylatorów: "NoiseBlocker Black Silent Fan XM1 40mm" o taki jak opisany tutaj.

@zember Dzięki za obszerny raport. Odpisze nie cytując, tylko nawiązując do konkretnych kwestii. 1. Problem z wariującymi kartami conax jest znany, Twoje obserwacje potwierdzają nasze(tuxa) wnioski dotyczące różnych rodzajów kart (wolna, szybka) i tego, który rodzaj jak chodzi. Jednak jest jeszcze jeden detal: od 8940 do 9125 w kodzie było wyłączone "conax ecmpairingrotation", co skutkowało szczególnie niestabilną pracą kart conax w czytnikach wewnętrznych. U testerów naszych, od 9126, karty które wcześniej sprawiały problemy chodzą ok, co nie oznacza, że uaktywniony kod "conax ecmpairingrotation" każdej karcie pomoże. 2. podaj wartości jakie masz w oscam.reader definicji czytnika dla inactivitytimeout reconnecttimeout w oscam.conf dla preferlocalcards

są MZ dwie opcje: "tylko lepiej" przejść na BZZB, lądujesz na około 4 lata nowszej konstrukcji, z lepszą głowicą (czulsza, unicable), nowszym i chłodniejszym dyskiem, ogólnie mniej grzejącą się, użytkowo takiej (wydajność) jak BSLA, "najlepiej", przejść na ESI-88, dużo wydajniejszy dekoder, lepszy LAN, jeszcze chłodniejszy, jeszcze lepsza głowica, tylko to rozwiązanie dwie wady: zazwyczaj brak (domyślnie) dysku, możliwość zamontowania tylko dysków 2.5 cala, znacznie droższych za tą samą pojemność co dyski 3.5 cala, aczkolwiek warto zauważyć że dyski 2.5 są zazwyczaj sporo cichsze od dysków 3.5 cala. Z tym, że nie warto BZZB kupować z powodu konieczności wymiany procesora i pamięci do przeróbki bym polemizował. To co się bardzo powszechnie stosuje, przy przerabianiu BSLA, z partyzantką / zworką jest dużo prostsze i tańsze (a zazwyczaj bardziej zyskowne dla tego kto przerabia), lecz niestety niesie z sobą negatywne skutki. Propozycja jano74 by odłączyć dysk (który jest dość starą i mocno grzejącą się konstrukcją), jest jakimś rozwiązaniem, jeśli możesz z dysku zrezygnować, jeśli nie, to konieczna będzie wymiana dysku na inny. Nie może to być jakiś, bo możesz wsadzić jeszcze większy "piekarnik", trzeba montować współczesne, energooszczędne dyski, z akcentem na dyski przeznaczone do pracy przystosowanej do zastosowań AV. dodam jeszcze, że sam w styczniu przechodzę ze stabilnego jak skała BSLA (wzorowo przerobionego) na Sagecoma (ESI).

Technicznie rzecz biorąc zestaw czynności słuszny. Tylko modowane BSLA będzie nadal modowanym BSLA. To już większy sens miałoby pozbycie się BSLA i nabycie przerobionego (lub do przeróbki) u dobrego fachowca BZZB. Trochę nowsza konstrukcja, z lepszą głowicą, z lepszym fabrycznie chłodzeniem, do tego chłodniejszy dysk, a z racji tego że odbiornik jest nowszy, to z przepracowaną mniejszą liczbą godzin.

Dziękuję za raporty. TOUTy nie powinny się pojawiać w ogóle. NOKi biorąc pod uwagę parametry (FEC / słaba korekcja) z jakimi jest nadawany sygnał naszych platform niestety mają prawo się pojawiać, ich pojawienie się w małej ilości (od paru setnych procenta do nawet paru dziesiątych procenta), nie świadczy o złej pracy oscama, zwłaszcza jeśli się nie stosuje filtrowania ECM po długości i/lub nagłówkach, gdyż wtedy błędne zapytanie jest kierowane na kartę. v20rc12 zostanie wrzucone ponownie, obecność problemu z cccam się nie potwierdziła, mogą być inne, ale nie akurat nie ten. v21fixed użyte na komputerach (raporty od innych testerów) chodzi wybitnie zacnie, na odbiornikach licho wie, w zasadzie powinno być lepiej, normalnie z racji ukończenia (teoretycznie) prac nad "nową" kontrolą wątków w oscamie, testy wykażą jak jest naprawdę.

owszem, takie są uroki testów :)

W związku z pytaniami o komunikaty generowane przez oscamy z "timepatch" takie jak: 2013/12/19 13:43:41 4C1490 h *** gonelastecm: 2098990, gonelogin: 104438 latestactivity: -1, 0 **** 2013/12/19 13:43:41 4C1490 h *** gonelastecm: 1000, gonelogin: 770088 latestactivity: -1, 0 **** informuję, że obecnie można je co najwyżej... polubić ;) to są informacje o wartości paru zmiennych, w określonym momencie, potrzebne do usuwania błędów w kodzie.

przetestuj 9126, od 9125 jest z powrotem w kodzie uaktywnione conax_pairingecmrotation.