AbrahaM

odpowiedź żartobliwą, ale trafną udzielił pppp Używacie drodzy forumowicze oprogramowania, które z założenia jest przeznaczone "dla entuzjastów", nawet image "łatwe i przyjazne" do odbiornika wymagają pewnego minimum wiedzy i zaangażowania, bez którego ani rusz. Wybierając Graterlie, wybraliście system (bo tu już o image w klasycznym znaczeniu pisać nie można), mniej "przyjazny", lecz od fundamentów do komina przemyślany, bez zbędnych dodatków. To, co możemy zrobić, to pomóc wam dostarczając informacji jak skorzystać prawidłowo z funkcji wymagających większego wysiłku, na razie powstało "IRAQ" z odpowiedziami na najbardziej podstawowe sprawy związane z obsługą oscama (nie jego konfiguracją), zaś FAQ dotyczące konfiguracji jest w przygotowaniu, będzie sukcesywnie rozbudowane. Prawdopodobnie w RC3 (lub RC4) pojawią się przykładowe zestawy konfiguracji dla polskich platform, które użytkownik będzie mógł w najgorszym razie sobie przekopiować (celowo piszę: w najgorszym razie, bo zdecydowanie chcielibyśmy, by użytkownik wiedział co robi i dlaczego to robi) oraz jedna konfiguracja, rozruchowa / uniwersalna, która powinna "jakoś" pracować z każdą możliwą kartą. Z akcentem na "jakoś", bo by oscam pracował efektywnie, powinien być ustawiany do konkretnych warunków. Podstawowe zestawy konfigów da się opracować jedynie dla sytuacji, gdy odbiornik posługuje się jedną kartą. Każdy inny konfig wymaga indywidualnego ustawienia do istniejących warunków. Co więcej, w wypadku oscama nie ma czegoś takiego jak jeden jedyny jedynie słuszny konfig. Ten sam efekt (poprawnie lub... rewelacyjnie działający oscam) można zazwyczaj uzyskać na co najmniej dwa sposoby. Niestety też na co najmniej dwa lub więcej sposobów można go zepsuć, tak że nie będzie działał w ogóle, lub będzie działał znacznie gorzej niż powinien.

jednakowoż mam przekonanie, że jedziesz na: http://forum.xunil.pl/index.php?topic=997.msg12031#msg12031

@bestisz82 przyczyn problemu może być najmniej parę, tyle że trzeba po kolei zacząć je wykluczać. jak na razie widzę jeden wspólny element kłopotów, każdy z boxów ma tą samą skórkę. przestaw skórki na boxach (najlepiej na standardową) i testuj. nie twierdzę że to jest przyczyna, ale od tego bym zaczął testy.

na forum "wisi" 9121 (zwykłe i z timepatch) z aktywnym conax_pairingecmrotation (to uaktywniono oficjalnie w 9125), posiadaczy kart conax proszę o testy. @Mickey: prośba (pomoc pozostałych forumowiczów też jest mile widziana, jeśli mają możliwość/czas): Zanotuj timingi/latencje na 300/300 na obecnej binarce, a potem wrzuć którąś z conax_pairingecmrotation i wypróbuj ponownie: mhz = 2400 cardmhz = 368 i wcześniej "ostatnio źle działające", czyli: mhz = 500 cardmhz = 357 oraz mhz = 368 cardmhz = 368

Jakby to napisać, postaram się to zrobić zwięźle. 1) Nie twierdzę, że ktoś wcześniej z dev'ami nie miał problemów, gdyż nie jestem ani tymi dev'ami ani kontaktującymi się z nimi osobami. Ale równocześnie musze napisać, że z mojej perspektywy współpraca z dev'teamem jest mniej więcej (mogłoby być nieco lepiej, ale nie jest źle) kulturalna i skuteczna. O czym już raz pisałem. 2) praca oscama, w tym wydajność, zależy nie tylko od samego kodu, ale i od ustawień. Przy czym ten sam konfig który był dobry dla wersji abcd może być niepoprawny lub nieefektywny dla bbcc. Wielokrotnie pisałem (ba, nawet dość intensywnie w tym wątku się "kłócąc"), że przenoszenie konfigu z wersji do wersji bez analizy co devy zmieniały między nimi może prowadzić do niemiłych niespodzianek. Przenoszenie konfigów jeszcze może "przechodzić" w prostych konfigach, dla odbiorników, a i to nie zawsze. Wcale nie kwestionuje, że stary oscam + stary konfig, chodzi lepiej, niż nowy oscam + stary konfig. Ba, byłbym dość mocno zdziwiony, gdyby tak nie było. Dowodów na to nie potrzebuje. Ma to związek, z tym, że w wypadku innych wersji wpływ mogą mieć na pracę: a) inne wartości/ustawienia domyślne przyjmowane przez oscam gdy użytkownik nie zadeklarował w konfigu wprost jakiegoś parametru, lecz zaakceptował ustawienie domyślne stosowane gdy nie jest wpisana żadna konkretna wartość, b) zmianę zachowania określonych opcji, dokładnie z takim przypadkiem mamy z wszystkimi wersjami powyżej 9092 (wcześniej w historii rozowoju oscama też trochę zmian tego rodzaju było), gdyż w 9092 wszedł patch b. mocno modyfikujący obsługę ecm, cache, cacheex, cw_check, i z tego powodu co bardziej zaawansowane konfigi powinny zostać przeanalizowane od nowa i niewykluczone, że od nowa ustawione. Dzięki tej zmianie obciążenie CPU na silnych maszynach (4rdzenie, wysokie taktowanie), z większą ilością wymian cache (dane z forum devów), spadło z ok 80% do ok 15%... No ale bywa, że przez to stare konfigi nadają się do kosza, wymagają ustawienia od nowa.

patche z linii "v12" rozwalają ponownie czytniki na sh4 :( czekamy na następną wersję, być może nawet +- 2 dni... wygenerowane 9121 czyste, z timepatchv11 z aktywnym conax_pairingecmrotation

Nie jestem w stanie gwarantować, że jakieś wymiany PW/PM nie było, ale jeśli nie widzę śladu ticketów/zgłoszeń dotyczących tej sprawy, to mam pełne podstawy uznać, że sprawa nie była zgłoszona. Jakoś khimtiki potrafił prawidłowo wypełnić zgłoszenie, naprowadzić devów na problem z przeskokami zegara, dzięki czemu właśnie trwa poprawianie mechanizmów czasowych w oscamie, w czym forumowicze od nas biorą udział (dziękujemy), testując kolejne wersje patcha. Jakoś sam zgłosiłem parę błędów które zostały skorygowane, parę drobniejszych sam naprawiłem, zostały naniesione na kod. Da się? Da się! Jak ktoś do theparasola (czy kogokolwiek innego) startował z takim podejściem jak u nas widzę, to się nie dziwię, że gość się wkurzył i sprawę olał, choć nie powinien. 1) przed chwilą skompilowałem na debianie x64 build 9121 + timepatchv12, który obsługuje phoenixa, latencje mam na tym niższą niż wcześniej na zwykłej 9071 + monotonic, o wcześniej używanej 8903 nie wspominając, oscamy testowałem praktycznie od 6xxx, i dość precyzyjnie pamiętam rarpotowane przez oscam (osobna sprawa, że to co oscamy podają należy jak na razie traktować jako wskazania mocno orientacyjne) wyniki poszczególnych binarek. Spowolnień w obsłudze ECM nie odnotowałem, a nawet wprost przeciwnie. Skórka wyliczająca "czasy" (a więc już odbiornik, nie oscam, te dane są wiarygodniejsze), wskazuje na znaczące przyśpieszenie oscamów. Więc w takiej sytuacji twierdzenie o 2x większej wydajności starego kodu czytników traktuję jako mit w stylu "bo jak ja byłem młody to"... 2) natomiast potwierdzam, że są problemy z obsługą kart są w wewnętrznych czytnikach odbiorników, szczególnie mocno to dotyczy sytuacji gdy w czytniku siedzi karta w systemie conax. I przy obecnym stanie obsługi conax trzeba poświęcić wydajność/latencje na rzecz stabilności. To jest jedna ze spraw, o które będziemy wiercić dziurę w brzuchu, ale po opracowaniu patcha czasowego, uważamy, że bez podstawy w postaci sprawnie działających mechanizmów czasowych nie ma co się brać za inne sprawy. 3) realnie latencja z punktu widzenia użytkownika boxa nie ma większego znaczenia, jedyne na co wpływa, to niestety tempo przełączania kanałów, poza tym, nikomu nie będzie "gorzej" odbiornik chodził przez to, byleby chodził stabilnie. Przyznaję częściowo rację. Z dwoma zastrzeżeniami: 1) Sytuacja, kiedy coś jest systemowo źle zrobione, plus na to aplikujemy poprawkę, która jest niezgodna z wszelkimi możliwymi zasadami, a to wszystko jakimś cudem działa, nie jest sytuacją prawidłową. Bo jeśli ktokolwiek kiedykolwiek z tym będzie chciał coś zrobić, to będzie się to spektakularnie sypać. Dokładnie do takiego stanu został doprowadzony kod, co teraz jest prostowane, i stąd są tak kuriozalne sytuacje jak opisałem wcześniej. Niestety przy okazji takich sprzątań wylatują fixy które by się (m.in. nam) przydały, i o które niestety trzeba będzie upomnieć się, by zostały zrobione na nowo. 2) Zapewne o tym wiesz, tylko to pomijasz, że projekty informatyczne (wszelkie, nie tylko oscam), osiągnęły taki stopień komplikacji, że analiza wszelkich możliwych zależności, wyłapanie wszystkich błędów na sucho jest najzwyczajniej niemożliwe, i/lub niewykonywalne przy ograniczonych zasobach. Te zdanie świadczy o deve które nie ma pojęcia co zmieniają . Na "pałe" usuwają część kodu. To się w głowie nie mieści co napisałeś. To znaczy o znajomości oscama przez osoby które próbują go " poprawić " Nic samo nie znika. Nie, to świadczy o poziomie zabagnienia kodu i skali wyzwania, z jakim się obecny team mierzy. Nie ma dnia, bym nie oglądał tego, co leci jako zmiana, czy patch, i uwierz mi, momentami można się załamać, jak trywialne/grube błędy potrafił zostawić w kodzie poprzedni team. Z tuxem dość regularnie komentujemy konkretne zmiany, stosując określenia uznawane za nieparlamentarne na kod który był wcześniej. Owszem, mam zastrzeżenia do sposób wprowadzenia zmian, czy do paru zmian konkretnych, ale uważam, że sprawy najprawdopodobniej toczą się w kierunku zbliżonym do właściwego. W wolnej chwili na PW dostaniesz linki do opisu błędu plus historię prób jego wyeliminowania, wygląda że problem rozwiązano. Aktualnie kompiluje v12fixed

9105 + v10 zostało usunięte z archiwum, bo faktycznie miało czytniki w sh4 praktycznie nie do użycia. 9121 + v11 wygenerowane, z kartonikiem seca działa w pełni prawidłowo, v10 nie odpalały. btw: przy próbie poprawienia timepatchv11 (na 64bitowych systemach zachowuje się nieco niewłaściwie webif, m.in. w zakładce users, sh4 to na szczęście nie dotyczy), prawdopodobnie wykryto przepełnienie bufora oryginalnie znajdujące się w webif.

@bloto22: Fundamentalnie się z Twoją oceną nie zgadzam. Nie widząc szczegółów możesz odnieść takie wrażenie, jakie dość malowniczo opisujesz wyżej. Problem z oscamem jest w tym, że poprzedni devteam uskuteczniał politykę nakładania niekończącej się liczby łat, łata łatała łatę, która łatała łatę, itd. W efekcie czego powstał wielki bałagan, który przez przypadek przez jakiś zakres wersji dla naszej platformy(sh4) w miarę nieźle działał. Do tego za oscamem ciągną się konsekwencje doraźnych fixów (zamieszanie z cardmhz, mhz zawdzięczamy praktycznie pierwszemu składowi dev-teamu, który w ten sposób obchodził kłopoty z czytnikami w starych dreamboxach). theparasol podjął się systemowego posprzątania tego bałaganu i wbrew pozorom, jest jednym z paru koderów, którzy wiedzą co robią, a nie jak inni, którzy poprawiają mały wycinek kodu, nie przewidując skutków dla całości. blueven przepisał praktycznie na nowo cały duży kawał kodu odpowiedzialnego za obsługę ECM i cache/cacheex (w 9093) theparasol zaś nieco wcześniej (w 9072) praktycznie usunął większość problemów z dvbapi na większości odbiorników. Niestety "przy okazji" tych zmian platforma sh4 chodzi gorzej (aczkolwiek nie można napisać że źle), ale na to też przyjdzie czas. Poziom bałaganu w kodzie, który przez te lata narósł jest trudny do wyobrażenia. Ilustracja sprzed +-paru dni: niedawno pojawił się błąd uniemożliwiający podłączenie do oscama przez cccam i newcamd. Podjęto ileś prób jego usunięcia, wykonując "celowane" zmiany w kodzie, a błąd "sam" znikł przy okazji wprowadzania innych zmian, absolutnie nie związanych z tą funkcją... Jedyne co mi się nie podoba, to wprowadzenie w podobnym czasie dwóch dużych zmian, w 9072 i w 9093. Przez to usuwanie ewentualnych błędów może być nieco utrudnione. Z polskiego podwórka: "wszyscy" narzekają na skutki zmian z 8940 (obsługa czytnika i zdjęcie doraźnego fixa dla conax), ale nikt nie ruszył .... się i nie raczył zasygnalizować problemów z conax do devow (sprawdziłem!). No chwila. To jak błąd ma być usunięty, jak go nikt nie zgłasza? I na koniec sprawy organizacyjne: Przypominam, że wyraźnie zostało zaznaczone, iż oscamy które są na forum zamieszczane, są dla testerów. one nie są do codziennego użytku. Przez przypadek mogą, ale wcale nie muszą pracować stabilnie. W szczególności do dotyczy wersji z patchami modyfikującymi obsługę czasu. Zostały udostępnione przez nas do testów, by przyśpieszyć (gdyż to priorytetowa sprawa, jako że oscam jest bardzo zależny od prawidłowego działania mechanizmów pomiaru czasu) rozwój patcha i wdrożenie finalnych modyfikacji w kod. Jesteśmy bardzo wdzięczni za testy, ale na litość... proszę się nie wylewać devom pomyj na głowę, za to że testowa wersja, w dodatku z nieoficjalnymi patchami źle działa. Ma do tego pełne prawo.

Choć czasy na tych ustawieniach są ok 1000-1100 ms u mnie na wolnej U jednego z naszych testerów automat zaskoczył i dobrał taktowanie 300, więc to jest kolejna przesłanka dla uznania 300/300 dla najnowszych buildów za działające.

jest wspólny mianownik, Twoja wartość, wartość z jeszcze innego wątku u konkurencji są z zakresu 200-300 MHz, więc wygląda że coś się przy taktowaniu wyżej spektakularnie sypie :( przy okazji przypominam: jeśli zapisy użytkownika mają działać, to w czytniku (dokumentacja/webif mogłaby być bardziej przejrzysta) ma być: autospeed = 0

@sunfizz To ma piernik, że obsługa czytników, w tym (a raczej przede wszystkim) wewnętrznych jest mocno zabagniona i nielogiczna, w zasadzie z powodu zaszłości historycznych, decyzji/błędów poczynionych przez poprzedni zestaw devów. Teraz trwa dyskusja czy i jak zachować jako taką zgodność wsteczną, ale wygląda na to, że docelowo czytniki będą obsługiwane w automatycznym trybie "autospeed" aczkolwiek będzie także możliwość wymuszenia taktowania takiego, jakie chce użytkownik. Skoro już jesteśmy przy konkretach, to ZTCP czytnik nboxa nie potrafi fizyczne pracować szybciej niż 600MHz, zaś ustawienie taktowania na "2400MHz" (cudzysłów celowy i zamierzony), nie wdając się w szczegóły, obchodzi pewne błędy w oscam w obsłudze kart conax.

@Tux to dobrze ujął. Nie bez powodu w wątkach z oscamami opisuję zmiany i/lub dopisuję komentarze we wpisach z załączonymi kompilacjami, choć czasami zdarza mi się czasem nie dość wyraźnie coś zaakcentować. Tytułem przypomnienia (wyrywkowo) w: 8940 przeryto kod obsługi czytników, stabilizowano to przez kolejne n+1 poprawek (i do teraz są przez te zmiany problemy z conax) 9072 wprowadzono poważne zmiany w funkcjonowaniu dvbapi 9093 wprowadzono bardzo grube zmiany w sposobie obsługi ECM, 9105 wygląda na dopiero jako tako ustabilizowane po zmianach z 9093 więc niestety uwaga: "ale ja zawsze używałem ustawienia_abc = xyz i ono jest dobre" jest błędne, to ustawienie było dobre do wersji abcd, ale od abdd może działać inaczej, działać źle, lub nie działać w ogóle. Dwa przykłady które przychodzą mi do głowy na szybko, oba z związane oscam.conf: reopenonzap przestał mieć znaczenie od 9072, od tej wersji oscam zachowuje się zawsze tak, jakby ten parametr był ustawiony na 1 clientmaxidle ustawiony na 0 w najnowszych buildach blokuje możliwość podłączenia się do oscama Bez analizy zmian kodu i/lub korzystania z forum devów zwykły użytkownik nie ma szans by ustalić przyczynę jakiś kłopotów czy zakres zmian. Jeśli sugerujemy testy na jakiś ustawieniach, to prosimy by traktować to poważnie, nie robimy tego bez powodu.

@bloto22: No właśnie niekoniecznie, to było ok dla starszych ale od 8903(?) zalecam jednak sprawdzić wpis, który podałem. U znajomego 368/368 na 8705 chodziło względnie dobrze, ale na tym samym konfigu 9071 chodziło tragicznie, zmieniłem mu na 2400 / 368 i problemy znikły jak ręką odjął. @domell2: dokładnie takie jak widać w wiadomości wyżej wariowanie nowych buildów na 368/368 dla Conax miałem na myśli. @zember: Tego typu problemów przy "czytniku programowym" nie powinieneś mieć, zakładając jego stabilną pracę. Mam nadzieję, że na v9 tego nie będzie. przy okazji, sprawdźcie v9, już wygenerowane wisi, takie są uroki testów, że od czasu do czasu (albo nawet seriami), coś nie działa...

Jeśli testujesz 9071, zastosuj pierwszy wpis z nowo tworzonego FAQ --> stąd z tego co się wczytywałem, podobno w nowszych ten trick przestaje działać...

zastąpiony wersją v8, proszę o testy, aczkolwiek też mogą być problemy, generuje się build v9, build v9 zamieszczony we właściwym miejscu

za paręnaście minut pojawi się ;) już jest w grudniowym wątku build 9105 z timepatch1v7, ochotników proszę o testy.

uwaga przyjęta, zamienię na "a co nie dotyczy ustawień", zamysł był taki, że mają być docelowo dwa poradniki, jeden dotyczący tego co dane ustawienie robi, z komentarzami, a drugi (ten o którym piszemy), dotyczący podstaw organizacyjnych

1) jak chcesz, to możesz wgrać nawet jeszcze starszy, ale nie polecamy, a już w szczególności nie polecamy odmian "amino" 2) http://forum.xunil.pl/index.php?topic=780.0 poczytaj instrukcje przy fragmencie "Komunikat: /etc/init.d/softcam.sh: line 95: /usr/bin/oscam: Permission denied lub podobny" na przyszłość proszę o wykazanie większej samodzielności w szukaniu dostępnych informacji

Panowie, to nie moja zasługa, tylko dwóch devów którzy wzięli się za sprzątanie i przebudowę kodu odpowiedzialnego ogólnie mówiąc za "czas". A jako że bardzo dużo mechanizmów oscama ma związek z czasem, to dowolne błędy i/lub błędne założenia skutkować mogą problemami. Ja tylko po parunastu dniach testów wrzuciłem binarkę zawierającą ten nieoficjalny/testowy patch, by poszerzyć testy o konfiguracje/kombinacje które dla nas są niedostępne. Niedługo będą kolejne binarki z nowszą wersją patcha, tylko trzeba trochę odczekać na poprawkę błędu który niedawno wykryłem w wstępnej wersji nowszego patcha.

być może się pomyliłem w trakcie zmieniania nazw plików z roboczych na finalne :-( wrzuciłem jeszcze raz, ma obowiązek webif być, sam 9092 bez usb, z webif używam ale nawet jeśli, to się jak pisałem przestaw sie na 9092, wisi w grudniowym wątku

dziękuję za raport. wrzuć 9092 clock monotonic, w 9089 przy okazji poprawiania obsługi czasu znaleziono błąd w kodzie sieciowym,

to jest niestety typowe dla zwykłej wersji. zarzuć do testów kompilacje "clock_monotonic" i napisz jakie są tego efekty.

Być może masz rację, ale po tym, jak spotkałem się z "paroma" modelami TV/Plazmy, gdzie oznaczenie modelu się różniło jedną literką na końcu i każdy z nich miał inny zestaw obsługiwanych trybów (w tym np. brak 1080p), to do specyfikacji / deklarowanych przez producentów parametrów podchodzę ehm nieco nieufnie.

dziękuję za raport. szkoda, że tak mało osób się udziela, zaraz wygeneruje 9084 i 9084 "monotonic clock", wygenerowane 9085 i 9085 "monotonic clock", zaraz będzie 9086, wygenerowane 9087 i 9087 "monotonic clock", przetestuj wersje "monotonic clock".