dyskusje o kompilacjach OCcama 2013 & 2014

[tux]

1. dotyczy kart conax w czytniku nboxa,

osobiście nie używam slotu nboxa do trzymania w nim kart, ale przechodziłem męczarnie z pół roku temu żeby karta conax poprawnie funkcjonowała w czytniku mojego vu+ duo. Moje spostrzeżenia po ponad m-cu testów:

- Wersja oscama wtedy nie miała znaczenia

- Znaczenie miała karta która siedziała w slocie, na jednej karcie conax nigdy nie miałem problemu na drugiej notorycznie jak wy tutaj, o dziwo na tych samych ustawieniach czytnika.

Potwierdzasz moje spostrzeżenia jeszcze z czasów karty SECA z ofertą Cyfra+ Pre-Paid. Na wolnej karcie sypało się aż miło mimo, iż czytnik wykrywał ją niby poprawnie na 5MHz. Paradoks był ten, że karta była wolna i powinna mieć 3,75MHz (chyba, dokładnie teraz nie pamiętam). Nawet jak OSCam był ustawiony na 3,75MHz (uwaga jak powyżej) to było lepiej ale nie DOBRZE! Wtedy zrodziła się myśl - czytnik sobie, OSCam sobie. Z czasem zaczyna mi to się potwierdzać. Tu dochodzimy do innego problemu. Wszystko wskazuje na to, że czytnik w SH4 nie jest skalowany (przynajmniej w naszych tunerach) - działa na kilku z góry ustawionych częstotliwościach. Jeżeli ja dobrze przypuszczam to ustawienie OSCama ma wpływ na wybór częstotliwości najbliższej ustawieniu w OScamie. Jeżeli tak jest, to może dochodzić do paradoksu, w którym karta, która ma działać np. 3,75MHz odpalana jest na 5MHz. Jakaś ilość kart podoła temu a jakaś nie.

a. uruchomienie karty w czytniku phoenix po usb, wszystko jak ręką odjął.

To by powierdzało moją teorię - dlaczego? W phoenixie ustawiasz zworką jak ma działąć karta. Soft nie ma nic do rzeczy. Najwyżej przy złym ustawieniu parametrów będzie wpadać np. w 1,5 ECMa albo coś innego, ale karta będzie działać z tą prędkością to ustawiłeś zworką i JUŻ.

Dodatkowo sprawdziłem wczoraj jakie parametry domyślnie przyjmuje czytnik SCI w nboxie bo ostatnio się tym trochę bawiłem. Po resecie przez sterownik bez działania jakiegokolwiek oprogramowania (np. oscama). Wyszło że niezależnie od karty (seca, nagra) w nim siedzącej to jest domyślnie: (0, 4500000, 372, 9600, 8203, 0, 0, 0, 1, 5, 50, 1). Na jakie parametry zmienia to oscam tego nie wiem ale może warto by było skorzystać z domyślnych wartości sterownika i tak sparametryzować czytnik w configu oscam aby przybrał zbliżone wartości. Więc zakładam że Mhz:450, Cardmhz:450.

To częściowo potwierdza moją wcześniejszą teorię :)

Nie wiem jaka jest przyczyna problemu:

- czy leży ona w oscamie?

- czy leży w problematycznym łączu wifi?

- czy może ECM jest uszkodzony?

To mi przypomina problemy znane z wersjii AMINO. Czyżby nowe wersje OSCama miały coś wspólnego z tym "złym" kodem znanym z AMINO? Oczywiście nie złym dla wszystkich tylko złym dla SH4?

tymczasem w informacji w webif czytnik jest poprawnie spięty z serwerem CCcam (oscam 8641). Dopiero po 10 czy więcej sekundach oscam zauważa że jednak nie jest połączony czytnikiem z serwerem , więc łączy się ponownie do serwera i wszystko wraca do normy.

To by wskazywało na brak synchronizacji czasu pracy obu OScamów. Jesteś w stanie zaktualizować OSCam na serwerze?

Wiem, że lepiej jest leczyć przyczynę a nie skutek ale może w tym przypadku przyczyna leży gdzieś poza oscam-em i może dało by się wyleczyć tymczasowo skutek. Np. w taki sposób aby jeżeli problem wystąpił na czytniku zdalnym (w tym przypadku cccam) i DVBAPI sygnalizuje że niema czytników pasujących to oscam wymusi renegocjację połączenia czytnika? A może wystarczy ustawić timeouty w czytniku na 0sekund ?

Tak to działa u mnie. Odpinasz kabel od netu i masz stopklatkę. Wpinasz kabel od netu - nie mija sekunda i działa.

Nawet zły ECM nie jest straszny.

Jest tylko jedno ale - od wersji 9141 (niezależnie od tego czy z paczem czy nie) potrafi skutecznie UBIĆ Enigma2. Pingwin tupta, albo pilot zamrożony i stopklatka podczas gdy do tunera po SSH można się zalogować i zrestartować E2. Odnoszę wrażenie, że skoro działa na DM czy VU+ to wszyscy uznają, że jest OK. Nie biorą pod uwagę STi gdzie są inne warunki pracy. Mam tylko nadzieje, że to chwilow (jak ostatnio) i naprawią to jak najszybciej bo zawieszenie się OSCama to jedno a wywrócenie Enigma2 to drugie.

---

 

Zestaw działający OK u mnie to:

Serwer: OSCAM 1.20-unstable_svn build r9059

Klient: build r9123 (sh4-linux-qboxhd-timepatchv12fixed3-micro-cccam-dvbapi)

Tutaj Klient jest wersją najwyższą działającą OK. Powyżej mam efekt specjalny w postaci UBICIA Enigma2.

 

 

Zwstaw co nie chce działać:

Serwer: OSCAM 1.20-unstable_svn build r9059

Klient: build r9143 (sh4-linux-qboxhd-timepatchv20rc12-micro-cccam-dvbapi)

Klient: build r9144 (sh4-linux-qboxhd-timepatchv22ecm-micro-cccam-dvbapi)

[AbrahaM]

@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

 

[kiso]

też mogę posprawdzać wasze kompilacje tylko napiszcie na co mam zwrócić uwagę. serwer oscama mam na routerze a esi-88 działa jako klient.

dodam, że posiadam 1 kartę seca.

 

 

 

Poprawiono pisownię

[rok666]

Problemy są tylko z conaxem, seca śmiga bez kłopotów.

[Gość domell2]

Ja zauważyłem znowu timeotuy od wersji, od której znowu jest w konfiguracji dostępny "loadbalncer". Nie wiem czy ma on jakikolwiek z tym związek ale o ile dobrze pamiętam to właśnie od tego momentu. Może coś dodatkowo było zmieniane ale to już wiedzą osoby, które w tym "grzebią"

U siebie mam na serwerze i kliencie preferlocalcards = 2 , a na kliencie inactivity i reconnect timeout na 30 s

[Gość zember]

tux@

 

 

To by wskazywało na brak synchronizacji czasu pracy obu OScamów. Jesteś w stanie zaktualizować OSCam na serwerze?

....................

Zestaw działający OK u mnie to:

Serwer: OSCAM 1.20-unstable_svn build r9059

Klient: build r9123 (sh4-linux-qboxhd-timepatchv12fixed3-micro-cccam-dvbapi)

Tutaj Klient jest wersją najwyższą działającą OK. Powyżej mam efekt specjalny w postaci UBICIA Enigma2.

 

 

Oczywiście jestem w stanie zaktualizować oscam na serwerze tylko wiesz mam wersje 8641 która działa non stop przez ostatni m-c (tj. od ostatniego restartu dekodera) i ani razu się nie zawiesiła ani wyłączyła. Jak to mówią jak coś działa to nie ruszaj. Dla testu w razie braku innego rozwiązania oczywiście podmienię na nowszą np. 9059.

 

Co do samego czytnika sci to generalnie miałem wtedy wrażenie że właśnie transmisja była przekłamywana tak jakby był zły baudrate/bitrate czyli do karty wysyłany jest prawidłowy ecm ale z powodu złych ustawień czytnika karta dostaje głupoty. Nie pamiętam już jak była ta zła odpowiedź karty na tego dobrego/złego ecm-a ale po niej można by potwierdzić tę teorię.

 

AbrahaM@

 

2. podaj wartości jakie masz

w oscam.reader definicji czytnika dla

inactivitytimeout 
reconnecttimeout

 

w oscam.conf dla

preferlocalcards

 

 

w oscam.reader definicji czytnika dla

inactivitytimeout             = 1
reconnecttimeout              = 4

 

z tym że log który podałem wcześniej jest logiem z przed zmiany tych ustawień na powyższe. to w nawiązaniu do tego posta http://forum.xunil.pl/index.php?topic=720.msg11885#msg11885

Pierwotnie były tu wyższe wartości coś ala 15, 30. Po zmianie tych wartości problem nadal się pojawia ale nie udało mi się tym razem złapać loga podczas przerwy w działaniu. To że problem występuje nadal potwierdzam ponieważ widziałem w logu na webif identyczne komunikaty z tym że przerwa teraz jest krótsza.

w oscam.conf dla

preferlocalcards - w oscamie kliencie niema tej linii w ogóle wiec jest ona domyślna. 

 

w oscamie serwerze mam:

preferlocalcards              = 1

 

Pozdrawiam,

[sunfizz]

Ja zauważyłem znowu timeotuy od wersji, od której znowu jest w konfiguracji dostępny "loadbalncer". Nie wiem czy ma on jakikolwiek z tym związek ale o ile dobrze pamiętam to właśnie od tego momentu. Może coś dodatkowo było zmieniane ale to już wiedzą osoby, które w tym "grzebią"

U siebie mam na serwerze i kliencie preferlocalcards = 2 , a na kliencie inactivity i reconnect timeout na 30 s

 

Kwestia czy LB masz aktywne, bo że ten moduł dodany w oscam to nie oznacza że jest aktywny.

Teraz dybiąc nad 'timeout', pokaż jakie masz wartości ustawione dla  clienttimeout.

[Gość domell2]

W kliencie jak i serwerze w "Global" mam

Client timeout - 5000 ms

Client max idle -  120 s

[sunfizz]

Czyli domyślne wartości.

W wolnej chwili możesz wkleić logi odczytane z momentu kiedy loguje timeouty.

[Gość gumkas77]

witam

chciałem tylko podziękować koledze AbrahaM@

za włączenie LB w w wersjach oscam , jest to jak się okazało b.przydatne :)

pozdro

[Gość domell2]

Czyli domyślne wartości.

W wolnej chwili możesz wkleić logi odczytane z momentu kiedy loguje timeouty.

 

Mam spróbować zlogować jako debug 128?

[AbrahaM]

Mam spróbować zlogować jako debug 128?

 

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

[Gość 5alive]

OSCam r9071 CLOCK_MONOTONIC_v2 sh4/qboxhd

 

 

Od czasu do czasu rozłącza się  po ext.cccam, żeby było zabawniej czasem nie chce się połączyć :) i potrafi się zawiesić jak zgubi połączenie.  Jest "error" potem już własnym życiem żyje ten oscam.

Pomaga killall, 10s przerwy  i działa dalej.

 

 

Inne wersje działają stabilnie i taki problem nie występuje, nawet 9071 samo nie daję takich błędów jak tak wersja v2 :)

 

 

 

 

 

[AbrahaM]

OSCam r9071 CLOCK_MONOTONIC_v2 sh4/qboxhd

 

dzięki za raport.

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

[Gość 5alive]

kanały z  zdublowanym sidem 0001 oraz 0002 jak i 1e.      dla 0100

 

 

"Stado"  nie oznacza osób kompetentnych, to że ktoś włączy 1 kanał na 15min i stwierdzi ze działa "super"... można sobie w buty włożyć.

 

 

[AbrahaM]

@5alive

oscam.dvbapi i oscam.whitelist ustawione prawidłowo?

[kiso]

OSCam r9071 CLOCK_MONOTONIC_v2 sh4/qboxhd

 

 

Od czasu do czasu rozłącza się  po ext.cccam, żeby było zabawniej czasem nie chce się połączyć :) i potrafi się zawiesić jak zgubi połączenie.  Jest "error" potem już własnym życiem żyje ten oscam.

Pomaga killall, 10s przerwy  i działa dalej.

 

 

Inne wersje działają stabilnie i taki problem nie występuje, nawet 9071 samo nie daję takich błędów jak tak wersja v2 :)

 

u mnie to samo, tylko ja zresetowałem dekoder i potem było ok.

[Gość 5alive]

Hmm...  znów się to zdarzyło. 

OSCam r9071 CLOCK_MONOTONIC_v2 sh4/qboxhd

 

 

Restart pomaga zazwyczaj. Może lokalny czytnik działa dobrze, ale remote reader po ext.cccam już nie bardzo. Zdarza się że po prostu się rozłączy i nie chce połączyć.

 

 

 

[tux]

Na serwerze Oscam z timepatch?

[kiso]

u mnie na serwerze jest bez timepatcha: oscam-svn9170-mips-tplink-webif-libusb-Distribution

 

[Gość 5alive]

Na serwerze Oscam z timepatch?

 

 

Zdaje się że timepatch powstał głownie z myślą o sh4 plaftormie, mogę się mylić.

 

 

 

[tux]

Tu akurat się mylisz.

[AbrahaM]

Zdaje się że timepatch powstał głownie z myślą o sh4 plaftormie, mogę się mylić.

 

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".

[Gość 5alive]

Cały czas mowa o kliencie dvbapi + wewnętrzny czytnik.

 

na platformie mips = 0 problemów z oscamem bez patcha, starsze jak i najnowsze wersje.

 

na platformie mips = xx  timeouty z oscam +patchem.  (solo oraz solo2, dm800se)

 

 

plaftorma sh4 = 0 problemow na 87xx oscamie co zalecie + 0 problemów z oscamem 9092 + patch

 

plaftorma sh4 = xx timeouty z oscamami nowszymi bez patcha

 

 

Liczby same mówią za siebie. Może powstał  "patch"  w innym celu, ale aktualnie tak sprawa wygląda. 

[tux]

W takim razie wyjaśnij mi dlaczego po zmianie oscama na wersję z time patch na terminalu (i686) oraz na odbiornikach (SH4 + Mips):

• NOOK spadł do ilości tak małej, że wpada w błąd statystyczny?
  
• Czasy ECM spadły?
  
• Prawie do zera wyeliminowany problem z AC3 (desynchronizacja - pisałem wiele razy)?
  

Tutaj UWAGA - nie na każdej wersji było OK! Bywały takie wersje, że nie dawało się tego używać. Ale to, że wyjdzie wersja zła o numerze X nie oznacza, że mam to wszystko wywalić w diabła, wrócić na stare i do końca świata używać tej jednej.

 

 

Moim zdaniem liczby liczbami, ale póki jest to POPRAWKA, a nie coś, co jest uznane za składnik główny OSCama, można tylko testować i zgłaszać, że u mnie to czy tamto.

Póki nie będzie więcej osób, którzy przetestują, to czy tamto rozwiązanie, będzie jak jest. Ja też wiele razy pisałem oraz logowałem co potrzeba i podsyłałem @AbramaM, by poszło dalej. Ale nie zakładałem, że coś jest BLE, bo liczby.

Przypomina mi to podejście @bloto22 (kod ma działać, a nie wyglądać) oraz typowo Windowsowe - działa, to po co coś robić.

 

 

Ujmę to jeszcze inaczej - po to można skompilować każdą wersję OSCama, by móc korzystać z każdej. Jednak uważam, że nie powinno się patrzeć przez pryzmat kilku odbiorników na krzyż. Sam Linux od początku istnienia był inny. Nikt nie patrzył na to, że stare może być niekompatybilne z nowym, skoro nowe wprowadza rewolucję. Tak jest do dzisiaj. Z jednej strony to koszmar (np. biblioteki), z drugiej rozwój w zastraszającym tempie.

 

 

 

 

na platformie mips = 0 problemów z oscamem bez patcha, starsze jak i najnowsze wersje.

na platformie mips = xx  timeouty z oscam +patchem.  (solo oraz solo2, dm800se)

Jeżeli na powyższe masz górę logów, to jak najprędzej z nimi do develi OScama! Oni mają osobiście DM i nie widzą problemu u siebie. Także albo go nie ma, albo nie występuje u nich i nie wiedzą, że jest. Zapewniam - nie pominą dokumentacji, którą podeślesz!

 

Edit: Poprawiono błędy.

[rok666]

NOK na serwerze eliminuje się poprzez odpowiednie wpisy w oscam.whitelist, natomiast patch związany z synchronizacją czasu wpływa na timeouty.

[tux]

Na NOOK też ma wpływ. Wystarczy, że zapytania i odpowiedzi będą przesunięte w czasie. Przed paczem średnia to 7% po paczu góra 1,5%.

 

 

Oczywiście - nie twierdzę, że to ma miejsce zawsze. Jednak po wielu latach używania rozwiązań OpenSource nauczyłem się inaczej myśleć. Otóż nie wszystko, co wydaje się logiczne, musi być logiczne. Zależy jak podejdziesz do zagadnienia i jak je przeanalizujesz. Coś logicznego z jednego punktu widzenia może być nielogiczne z drugiego. Ale czy to oznacza, że w każdych warunkach ma zastosowanie tylko jedno rozwiązanie?

 

 

Osobną sprawą jest to, iż odnoszę wrażenie jakby wiele osób nie miało pojęcia co "taktowało" OScama, a co "taktuje" z paczem i jakie to może mieć znaczenie. Przecież zegarek to zegarek.

 

Edit: Poprawiono błędy wynikające z pośpiechu.

[Gość zember]

Mały update po testach dot problemów z połączeniem oscama sh4 przez czytnik jako klient CCcam gdzie występowały problemy z ciemnością i komunikaty w stylu:

 

[DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding!

 

na kombinacji

serwer : OSCAM 1.20-unstable_svn build r8641 - mips

klient : oscam-r9159-qbohxhd-webifv16_tpreloadedv2fixed-nousb

nie zauważyłem problemu od 30.12.2013

dodatkowo po zmianie tej binarki podmieniłem w configu:

wartości:

inactivitytimeout = -1 - ale teraz patrze i chyba zmienił mi to automatycznie na 30
reconnecttimeout              = 1

dodatkowo spostrzegłem że nie częściej niż powiedzmy 30 ecmów jednen dłuższy czas oczekiwania na odpowiedz. Przykładowo średnie czasy to 300ms a co jakieś 30 odpowiedzi jest peek do 1500-3000ms

 

właśnie zaktualizowałem Graterlia przez opkg upgrade zmieniło parę rzeczy m. in. oscam na 9071

 

tuxish-Box:~# opkg list-upgradable
graterlia-scripts - 0.1.6 - 0.1.8
oscam - 1.20-r8917-2 (tutaj był oczywiscie 9159 ale opkg widzi wersje z poprzedniej aktualizacji)- 1.20-r9071-1
system-core - 2.0.0 - 2.0.1
enigma2-extpythonpack - 0.2.3 - 0.2.4
graterlia - 2.0.0-RC2 - 2.0.0-RC2.1

 

Zobaczymy czy problem z blackoutami powróci czy nie.

 

[AbrahaM]

Mały update po testach dot problemów z połączeniem oscama sh4 przez czytnik jako klient CCcam gdzie występowały problemy z ciemnością i komunikaty w stylu:

 

[DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding!

 

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.

[Gość zember]

wydaje się że na razie jest ok, na wersji oscam-r9172-qbohxhd-tpreloadedv14tryfixtimeoutanotherapproach-nousb chyba nie było przestoju w obrazie nie wiem bo akurat wyszedłem ale taki o to dziwno log zauważyłem

 

2014/01/05 16:28:37.035 51CBD8 c dvbapi (0100&000068/5C00/32DC/64:682Exxxxxxxxxxxxxxxxxx): found (340 ms) by nbox - Canal+ HD Polska
2014/01/05 16:28:52.002 51CBD8 c dvbapi (0100&000068/5C00/32DC/64:F57Fxxxxxxxxxxxxxxxxxx): found (-689 ms) by nbox - Canal+ HD Polska
2014/01/05 16:29:07.014 51CBD8 c dvbapi (0100&000068/5C00/32DC/64:4279xxxxxxxxxxxxxxxxxx): found (327 ms) by nbox - Canal+ HD Polska 

 

niestety ponownie to samo zastanawiam się czy jednak nie jest to wina łącza wifi :/

 

2014/01/05 17:22:03.933 51CBD8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding!
2014/01/05 17:22:04.237 51CBD8 c [DVBAPI] Demuxer #0 impossible to descramble PID #1 CAID 1813 PROVID 000068 ECMPID 0835 (NO MATCHING READER)
2014/01/05 17:22:04.541 51CBD8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 4 ecmpids!
2014/01/05 17:22:04.845 51CBD8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding!
2014/01/05 17:22:04.982 511510 p nbox [cccam] connecting to 192.168.4.10:12000
2014/01/05 17:22:05.149 51CBD8 c [DVBAPI] Demuxer #0 impossible to descramble PID #1 CAID 1813 PROVID 000068 ECMPID 0835 (NO MATCHING READER)
2014/01/05 17:22:05.453 51CBD8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 4 ecmpids!
2014/01/05 17:22:05.757 51CBD8 c [DVBAPI] Demuxer #0 trying to descramble PID #0 CAID 0100 PROVID 000068 ECMPID 0835 ANY CHID VPID 00A0
2014/01/05 17:22:06.425 51CBD8 c dvbapi (0100&000068/5C00/3779/64:B28728Exxxxxxxxxxxxxxxxxx): found (361 ms) by nbox - Canal+ Film HD Polska 

[AbrahaM]

wydaje się że na razie jest ok, na wersji oscam-r9172-qbohxhd-tpreloadedv14tryfixtimeoutanotherapproach-nousb chyba nie było przestoju w obrazie nie wiem bo akurat wyszedłem ale taki o to dziwno log zauważyłem

 

2014/01/05 16:28:37.035 51CBD8 c dvbapi (0100&000068/5C00/32DC/64:682Exxxxxxxxxxxxxxxxxx): found (340 ms) by nbox - Canal+ HD Polska
2014/01/05 16:28:52.002 51CBD8 c dvbapi (0100&000068/5C00/32DC/64:F57Fxxxxxxxxxxxxxxxxxx): found (-689 ms) by nbox - Canal+ HD Polska
2014/01/05 16:29:07.014 51CBD8 c dvbapi (0100&000068/5C00/32DC/64:4279xxxxxxxxxxxxxxxxxx): found (327 ms) by nbox - Canal+ HD Polska 

 

niestety ponownie to samo zastanawiam się czy jednak nie jest to wina łącza wifi :/

 

2014/01/05 17:22:03.933 51CBD8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding!
2014/01/05 17:22:04.237 51CBD8 c [DVBAPI] Demuxer #0 impossible to descramble PID #1 CAID 1813 PROVID 000068 ECMPID 0835 (NO MATCHING READER)
2014/01/05 17:22:04.541 51CBD8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 4 ecmpids!
2014/01/05 17:22:04.845 51CBD8 c [DVBAPI] Demuxer #0 no suitable readers found that can be used for decoding!
2014/01/05 17:22:04.982 511510 p nbox [cccam] connecting to 192.168.4.10:12000
2014/01/05 17:22:05.149 51CBD8 c [DVBAPI] Demuxer #0 impossible to descramble PID #1 CAID 1813 PROVID 000068 ECMPID 0835 (NO MATCHING READER)
2014/01/05 17:22:05.453 51CBD8 c [DVBAPI] Demuxer #0 (re)starting decodingrequests on all 4 ecmpids!
2014/01/05 17:22:05.757 51CBD8 c [DVBAPI] Demuxer #0 trying to descramble PID #0 CAID 0100 PROVID 000068 ECMPID 0835 ANY CHID VPID 00A0
2014/01/05 17:22:06.425 51CBD8 c dvbapi (0100&000068/5C00/3779/64:B28728Exxxxxxxxxxxxxxxxxx): found (361 ms) by nbox - Canal+ Film HD Polska 

 

1) dziękuję, zgłoszenie zrobione, ten sam błąd potwierdza inny tester,

2) jak najbardziej to może być "zasługa" WiFi.

[Gość domell2]

Wersja 9172 oscam-r9172-qbohxhd-tpreloadedv15

Coś takiego wyrzuciło ale bez jakiś widocznych skutków ubocznych

 

2014/01/07 01:46:50.941 4DFF50 c nbox1 (0B01&000000/0000/0C23/6C:4A3FA88911484A0925BB82E11BA92681): found (867 ms) by n - Polsat HD
2014/01/07 01:47:04.480 4DC0C0 c dvbapi (0B01&000000/0000/2919/6C:18918B04FAF33585970916F3F292FC4C): found (896 ms) by n - SuperStacja
2014/01/07 01:47:04.550 4C8478 r n [conax] PairingECMRotation - ERROR
2014/01/07 01:47:05.952 4DFF50 c nbox1 (0B01&000000/0000/0C23/6C:9462DD7813045FEA239C17C3C1A82225): found (890 ms) by n - Polsat HD
2014/01/07 01:47:19.485 4DC0C0 c dvbapi (0B01&000000/0000/2919/6C:AE5D75EDD84E542B2CA961FB8AEB2682): found (906 ms) by n - SuperStacja
2014/01/07 01:47:20.942 4DFF50 c nbox1 (0B01&000000/0000/0C23/6C:C056EBC554E546A7E72ECEC77BD62E70): found (867 ms) by n - Polsat HD
2014/01/07 01:47:34.480 4DC0C0 c dvbapi (0B01&000000/0000/2919/6C:041B956625B1EC03BE518291AD4AB09B): found (894 ms) by n - SuperStacja 

[Gość future0]

na 9071 czasem się zawiesza, podczas oglądania stopklatka i pomaga tylko restart, zarówno na sh jak i z sci0 z karty N, na 8903 nie ma tego problemu

[tux]

opkg update && opkg upgrade

Napisz czy się coś zmieniło.

[rok666]

Tak bez loga to można sobie pisać, że się cuda na kiju dzieją. Już prawie 4 dni uptime i praca bez problemów, jeden klient dvbapi, jeden newcamd, jeden cccam.

[Gość future0]

opkg update && opkg upgrade

Napisz czy się coś zmieniło.

 

upgrade miałem zrobione, na końcu po zawieszeniu jest komunikat z "ANY CHID" i nic dalej się nie dzieje, pomaga tylko restart oscama, wracam więc do stabilnej 8903 i czekam na kolejną "zieloną" wersję oscama

[tux]

No jak zrobił upgrade jak ma 9071?

Inna sprawa - rozumiem, że poza wgraniem nowego OSCama poprawiłeś też konfigi zgodnie ze stroną OSCama?

Wszystkie wpisy są 100% zgodne z nową wersją?

[kusiu]

No jak zrobił upgrade jak ma 9071?

Inna sprawa - rozumiem, że poza wgraniem nowego OSCama poprawiłeś też konfigi zgodnie ze stroną OSCama?

Wszystkie wpisy są 100% zgodne z nową wersją?

 

 

Witam, podepnę się pod temat.. Gdzie na xunil jest podana konfiguracja oscama zgodnie z wersjami etc.

 

Znalazłem tylko by do nowych wersji dodać wpis autospeed                    = 0

[tux]

Gdzie na xunil jest podana

 

Chyba nigdzie bo tym zajmuje się dokumentacja OScama :)

[Gość future0]

ok, wyłączam autospeed i jutro napisze czy coś to dało

 

@edit

dalej to samo, na sh nawet po złapaniu 1 ecma zawiesza się obraz, a log nic nie da po stoi tak jakby się wyłączyło tuner, a przy sci0 to myslę że nie ma w tej wersji auto resetu karty i przy zawieszce staje

[tux]

Mam prośbę. Z uwagi na to, że zaobserwowałem znacząco inną pracę OSCama na 5800xx, 28xx i ESI, proszę o podawanie tunera na którym testujecie oraz dokładną nazwę OSCama z loga.

[mickey]

Taka ciekawostka: po wpisaniu httpreadonly=1 o oscam.conf znikają ikonki w webif ... Nawet nie wiem od jak dawna, jakoś mi to wcześniej nie przeszkadzało. A może to poprawne zachowanie jest?

 

PS: 9256 ... czasami (50/50) po restarcie skryptem nie wstaje ... może za długo się zamyka i sleep za krótki a może coś innego. FTP w użyciu, czyli tuner lekko obciążony...

[AbrahaM]

Taka ciekawostka: po wpisaniu httpreadonly=1 o oscam.conf znikają ikonki w webif ... Nawet nie wiem od jak dawna, jakoś mi to wcześniej nie przeszkadzało. A może to poprawne zachowanie jest?

 

PS: 9256 ... czasami (50/50) po restarcie skryptem nie wstaje ... może za długo się zamyka i sleep za krótki a może coś innego. FTP w użyciu, czyli tuner lekko obciążony...

 

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ść.

[mickey]

Przy sleep=3 na razie 100% ok ... co nie zmienia faktu, że to pierwsza wersja, która mi nie wstała ... a właściwie nie zginęła ... przy restarcie skryptem ze sleep=2. [esi-88]

[AbrahaM]

Przy sleep=3 na razie 100% ok ... co nie zmienia faktu, że to pierwsza wersja, która mi nie wstała ... a właściwie nie zginęła ... przy restarcie skryptem ze sleep=2. [esi-88]

 

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ć.

[Gość 5alive]

Tak bez loga to można sobie pisać, że się cuda na kiju dzieją. Już prawie 4 dni uptime i praca bez problemów, jeden klient dvbapi, jeden newcamd, jeden cccam.

 

 

 

U mnie dekoder 24/7  pozostaje włączony, chyba ze przypomni mi się o nim :D.

 

 

9071, słabo sobie radzi z różnymi caid, im więcej masz dostępne tym gorzej sobie radzi, i dziwne zachowania wynikają. :)

 

Powinna zostać poprawiona wersja z ostatnimi poprawkami dvbapi, które pozytywnie wpłyneły na działanie/odbieranie tv.

 

 

Jeżeli po zmianie oscama na wersje z timepatch fixem, ilość NOK spadła, tzn ŻE KONFIG którego używacie jest bardzo słaby... są w nim błedy.

Jeżeli TOUT spadły ( zawsze miałem 0-4 TOUT a normalnych wersjach, chyba że oscam był wadliwy).

 

Tak więc jeżeli występowały to zasługa "super konfiga", albo przekombinowania, osób które  pakują 6 oscamów i przez nie wszystko puszczają :)

 

Im konfiguracja prostsza, tym lepiej to działa. Zawsze tak było i zawsze tak będzie. :)

 

P

[AbrahaM]

U mnie dekoder 24/7  pozostaje włączony, chyba ze przypomni mi się o nim :D.

 

 

9071, słabo sobie radzi z różnymi caid, im więcej masz dostępne tym gorzej sobie radzi, i dziwne zachowania wynikają. :)

 

Powinna zostać poprawiona wersja z ostatnimi poprawkami dvbapi, które pozytywnie wpłyneły na działanie/odbieranie tv.

 

Tak więc jeżeli występowały to zasługa "super konfiga", albo przekombinowania, osób które  pakują 6 oscamów i przez nie wszystko puszczają :)

 

Im konfiguracja prostsza, tym lepiej to działa. Zawsze tak było i zawsze tak będzie. :)

 

P

 

Z tym nie ma co polemizować, mądre słowa, ale niestety poniższe (celowo zacytowane osobno)

 

 

Jeżeli po zmianie oscama na wersje z timepatch fixem, ilość NOK spadła, tzn ŻE KONFIG którego używacie jest bardzo słaby... są w nim błedy.

Jeżeli TOUT spadły ( zawsze miałem 0-4 TOUT a normalnych wersjach, chyba że oscam był wadliwy).

 

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.

 

 

[kusiu]

Może ktoś podać config oscama do ostatniej stabilnej wersji Abrahama pod protokół cccam? :)

 

Raz na kilka godzin wywala mi:

 

2014/01/11 16:00:42   4D27F0 p S [cccam] disconnected: reason disconnect
2014/01/11 16:01:02   4D27F0 p S [cccam] connecting to xxx

 

czyli rozłącza oscama od servera na każdej z wersji, powyżej log brak połączenia przez 20 sek po 20 sek łączy ponownie (czas zawsze taki sam 20 sek. oczekiwania) ..

 

ustawienia oscama pod cccam

 

oscam.server:

[reader]
label                         = S
protocol                      = cccam
device                        = xxx
user                          = xxx
password                      = xxx
inactivitytimeout             = 1000
reconnecttimeout              = 1000
group                         = 1
cccversion                    = 2.0.11
ccckeepalive                  = 1

 

oscam.config

 

[global]
logfile                       = /root/oscam.log
clienttimeout                 = 7000
nice                          = -1
maxlogsize                    = 400

[cache]

[dvbapi]
enabled                       = 1
user                          = dvbapi

[webif]
httpcss                       = /etc/oscam/skyndas/site.css
httptpl                       = /etc/oscam/skyndas
httpport                      = 8888
httpallowed                   = 127.0.0.1,192.168.0.0-192.168.255.255,255.255.255.255

[mickey]

Ale to źle, że jak się rozłączy samo się łączy? Powodem rozłączenia może być chwilowy brak sieci. A łączy się jak połączenie wróci. Z tego co kojarzę, to starsze oscamy nie potrafiły się same połączyć. Komunikat jest więc w porządku i jest to tylko komunikat.

 

(czas zawsze taki sam 20 sek. oczekiwania)

 

A masz tuner podłączony do routera? Jak długo restartuje się router?

 

@AbrahaM: Problem z restartem miałem zarówno na obydwu udostępnionych wersjach, czyli na tej bez "timepatcha" też. Ale może kod timepatcha jest już częsciowo w kodzie głównym?

[Gość 5alive]

Może ktoś podać config oscama do ostatniej stabilnej wersji Abrahama pod protokół cccam? :)

 

Raz na kilka godzin wywala mi:

 

2014/01/11 16:00:42   4D27F0 p S [cccam] disconnected: reason disconnect
2014/01/11 16:01:02   4D27F0 p S [cccam] connecting to xxx

 

czyli rozłącza oscama od servera na każdej z wersji, powyżej log brak połączenia przez 20 sek po 20 sek łączy ponownie (czas zawsze taki sam 20 sek. oczekiwania) ..

 

ustawienia oscama pod cccam

 

oscam.server:

[reader]
label                         = S
protocol                      = cccam
device                        = xxx
user                          = xxx
password                      = xxx
inactivitytimeout             = 1000
reconnecttimeout              = 1000
group                         = 1
cccversion                    = 2.0.11
ccckeepalive                  = 1

 

oscam.config

 

[global]
logfile                       = /root/oscam.log
clienttimeout                 = 7000
nice                          = -1
maxlogsize                    = 400

[cache]

[dvbapi]
enabled                       = 1
user                          = dvbapi

[webif]
httpcss                       = /etc/oscam/skyndas/site.css
httptpl                       = /etc/oscam/skyndas
httpport                      = 8888
httpallowed                   = 127.0.0.1,192.168.0.0-192.168.255.255,255.255.255.255

 

 

9092 monotonic v2 + konfigi masz kilka stron wcześniej.