AbrahaM

Log został przekazany bezpośrednio do deva odpowiedzialnego za dvbapi. Czekamy na efekty.

Wracamy do punktu wyjścia, już 25 stycznia o tym pisałem. Po tej serii testów to wygląda na uszkodzony i/lub źle zregenerowany/przerobiony odbiornik.

Streszczając: 1) oscam na linux (jakikolwiek linux*) nie ma żadnego wpływu na obraz, gdyż ewentualny wpływ może mieć wyłącznie kod dotyczący dvbapi, obecny na sh4, 2) wygląda, że oscam na sh4 (raczej) nie miał nic wspólnego z problemami na TVNach, aczkolwiek zamierzamy to jeszcze dalej badać w wolnej chwili**. * pomijając ewidentne grube błędy, nie wykryte, ** aktualnie parę spraw ma wyższy priorytet, nie da się wszystkiego naraz robić.

Testowałem pewne zmiany (i ich wycofanie z kompilacji) dotyczące dvbapi, których wprowadzenie w kod zbiegło się z problemami na TVNach i przez to wydawało się, że mają wpływ na TVNy. Niestety nie udało się tego potwierdzić. Niezależnie od wycofania lub nie poprawek (dwóch naraz i po jednej), problemy nadal potrafiły występować na TVNach.

Obstawiam, że źle typujesz. Moja znajomość rynku rtv sugeruje mi, iż konwerter to klasyczny produkt klasy niewiele lepszej od "noname", typowy średniak sprzed paru lat, i że w tym wypadku to nie jest problem z zbyt silnym sygnałem / przesterowaniem, ale mogę się mylić. Połowicznie zgoda, czyli zgadzam się diagnozą dot. BSKA/BSLA/BXZB, tylko mam nieodparte wrażenie, że to nie problem instalacji pod te złe modele... Aczkolwiek zgoda, że powinno to zostać też wykluczone.

matzg: bym się pod tym podpisał, gdyby nie to: 2850ST ma nieco lepszą głowicę (i elektronikę) niż 5800BSLA, więc zakładając że podpina 2850ST do tego samego kabla (tzn. dokładnie z tego samego wyjścia z konwertera, bo inne / drugie wyjście może być wadliwe) to problem może dotyczyć odbiornika. Po wykluczeniu błędnych ustawień odbiornika dotyczących głowicy (co można sprawdzić porównując ustawienia na obu) pozostaje niezbyt miła ewentualność w postaci wadliwie przeprowadzonej przeróbki.

Właśnie dostałeś ostrzeżenie za dwukrotne nie czytanie forum i "IRAQ"/FAQ o oscamie. Te informacje są dostępne na forum. Choćby tutaj.

Nie wpływa, gdyż wartości powyżej 2000 przełączają wewnętrzne czytniki w tryb PLL. Zwróć uwagę na to, co sam wklejałeś: "PLL Reader".

Nie do końca. Przy wymuszeniu trybu pracy taktowania PLL cardmhz jest automatycznie zniżane do 3.42MHz jako najbliższego do tego, o które prosiliśmy. Już raz pisałem: stan obsługi czytników wbudowanych w SH4 jest erhm dziwny. Mam silną nadzieje/przekonanie, że to się za jakiś czas zmieni, ale najpierw developerzy muszą przewalczyć zmiany w webif, "clockfix"/"timepatch", plus trochę doraźnych zmian/poprawek...

To dość ciekawe, bo u mnie efekty specjalne ustąpiły.

to nie to, logi idealnie czyste, żadnych NOK/TOUT, odbiór oparty wyłącznie o kartę w lokalnym czytniku. dalsze testy w toku.

Nie miałem potrzeb by to testować, więc pisałem o tym co wynikało z dokumentacji i/lub innych źródeł które znałem. Logicznie rzecz biorąc, Twoja uwaga jest słuszna, w wypadku odbiorników można by sprawdzać obecność czytnika R0. Co rozwiązuje kwestie Twojego pytania, od którego się ten wątek zaczął.

Mama mia. W wątku o czym tu dyskutujemy? o sprawdzaniu czy coś się dekoduje, cytuję za innym guru oscamowym (Jej@n) W pliku (lcd, dopisek mój) otrzymujemy sporo informacji takich jak: - pełne dane o wersji OSCam'a - uptime - dane z tabelki "Totals" w zakładce USERS - informacje o czytnikach i userach przykładowe dane (także cytuję za Jej@n) Version: 1.20-unstable_svn Revision: 8829 up: 10:34:08 totals: 2728/0/6/0/1/0 uptime: 38048 Typ| Label | Idle | w | s | b | e | St ---+------------+--------------+---+---+---+---+---- R0 | alfa | 00:00:38 | 0| 0| 0| 0| OK R1 | beta | 00:00:13 | 0| 0| 0| 0| OK P0 | dcw | 10:34:08 | 0| 0| 0| 0| CON P1 | chi | 00:00:00 | 0| 0| 0| 0| CON P2 | phi | 02:28:35 | 0| 0| 0| 0| CON P3 | delta | 00:00:01 | 2/213 cards | CON P4 | kappa | 00:00:53 | 1/ 1 card | CON P5 | sigma | 00:00:18 | 5/ 29 cards | CON P6 | ex301 | 00:00:38 | 0| 0| 0| 0| CON P7 | ex302 | 00:00:00 | 0| 0| 0| 0| CON P8 | ex303 | 00:00:13 | 0| 0| 0| 0| CON P9 | ex304 | 00:00:00 | 0| 0| 0| 0| CON ---+------------+--------------+---+---+---+--++---- Typ| Label | Channel | Time ---+------------+-----------------------------+----- U0 | nbox | nc+ :Polsat HD | 227 U1 | dm500 | nc+ :Filmbox Action | 393 ---+------------+-----------------------------+----- Te dane można wykorzystać w skrypcie, choćby do sprawdzania czy odbiornik coś dekoduje, wtedy "będzie widać" że użytkownikowi dvbapi przyrasta ilość zapytań o ECM.

To się ostatnio zdarza także na TVN 24HD, które wcześniej było od problemów w zasadzie prawie całkiem wolne. Prócz tych efektów pojawia się też klasyczne "klatkowanie" jak na TVN HD gdy wgrany był player2.ko bez fixa od józka. Duża prośba o podawanie dokładnej wersji o jakiej piszecie, bo mamy testowe revert9320, revert9319, revert9320,9320 i czystą/oficjalną wersję.

wszystkie? jako, że mam problemy mimo wycofania 9319 i 9320, to kompiluje do testów 9349 z wycofaną poprawką 9311 nie kompiluje, właśnie testuje 9317, które wygląda na dobre - czyli problem pojawił się pomiędzy 9317 a 9333.

9346 z wycofanymi zmianami z 9319 i 9320 zachowuje się źle :(

odkopuje. na podstawie pliku LCD generowanego przez oscam, można wywnioskować czy coś się dekoduje. Po więcej (jak to ustawiać) odsyłam do: http://www.streamboard.tv/wiki/OSCam/en/Config/oscam.conf#enablelcd - po testach zobaczysz co oscam tam umieszcza :)

Dlatego, że pamiętam z "timeline" próby usuwania problemu gdy program zmieniał się z niekodowanego na kodowany. Nie znajdę tego wśród paruset zmian które "ostatnio" widziałem, ale mam przekonanie graniczące z pewnością, że developerzy oscama z tym problemem już parę razy walczyli. Jak nie chcesz, to nie loguj i będziesz miał problem nadal :P tak, to przynajmniej są jakieś szanse na usunięcie błędu. Nie ma gwarancji, że się uda, ale szanse są.

tego to najstarsi górale nie wiedzą. w związku z tym proszę: 1. przestawić zapis logów oscama na adb5800 na hdd, z racji tego, że przy debugowaniu zapisywane są duże ilości danych, 2. przestawić maksymalny rozmiar loga na np. 24576 (to jest 24mb), 3. ściągnąć oscama najnowszego (developerzy tego wymagają) i na nim kontynuować testy, są szanse że nowa wersja tego błędu nie ma, 4. ma być to wersja z "debug" 5. włączyć na webif debugowanie na poziomach 1 i 128

zaraz do testów zrobione zostaną kolejne 3 wersje bez zmian / wycofywania kodu z 9320 i 9319 z wycofaną (tylko) zmianą z 9320 z wycofaną (tylko) zmianą 9319 obecna wersja ma wycofane 9319 i 9320 bardzo proszę o testy, to jest dość ważna sprawa, bo być może problem z "TVNami HD" i paroma innymi kanałami nie jest wywołany przez player2.ko (aczkolwiek jego modyfikacja doraźnie go "obchodzi", wywołując inne komplikacje), tylko przez problem w kodzie oscama, w kodzie obsługującym dvbapi. Niestety konieczne jest przetestowanie wszystkich czterech odmian gdyż nie wiemy czy: 1. błąd jest w 9320 2. błąd jest w 9319 3. błąd wynika z obu zmian, 4. błędu tam nie było, był wywołany czym innym, co zmienili po drodze do 9346

na obu odmianach 9333, czystej i z wycofaną 9319? w takim razie proszę o test 9310 (jeśli dobrze typuje, powinna być jeszcze ok) 9320 (jeśli dobrze typuje, powinna być już zła) 9346 z wycofanymi zmianami z 9319 i 9320

PROŚBA O TESTY: DOTYCZY WERSJI 9333 i 9333 revert9319. Prawdopodobnie wersja oficjalna/standardowa 9333 zawiera błąd wywołany zmianą 9319, wywołującą problemy z odbiorem programów grupy TVN w HD. Duża prośba o testy na tych kanałach (w szczególności na: TVN24 HD, TVN HD, TVN Style HD, raczej w tej kolejności) wersji 9333 i 9333 revert9319 z wycofaną zmianą podejrzewaną o sprawianie problemów. aha, obie wersje są z błędem uniemożliwiającym restart przez webif, dopiero co to wyszło. Problem został już zgłoszony.

tytułem wyjaśnień dot. rekomendowanych wersji: 9072 monotonic v2 jest nadal polecaną wersją i nie było innej rekomendowanej, poza wcześniejszymi 9071 i 8705. 9092 monotonic v2 faktycznie istniała, ale nie przeszła wszystkich testów i w związku z tym nie "wisi" w odpowiednim dziale forum, jeśli przejdzie b. intensywne testy wśród naszych testerów, to zostanie "podwieszona" i pójdzie jako aktualizacja. Jak na razie wszystko jest po staremu.

bardzo proszę o szybki test wrzuconych wersji 9307 i 9308 przy czym na razie do "normalnych" testów sugeruje ograniczenie się do 9300

Mniej więcej. Oprócz nie wgrania webif, "pomyrdały" mi się opcje kompilacji między różnymi typami binarek, z patchem clockfix i bez, co skutkowało nie działaniem czytników. Nowo wgrane 9297 jest już ok, podobnie jak 9300.