AbrahaM

Czyli sumując nasze wypowiedzi, polecane: konwertery "unicable": Sharp, rekomendacja tylko dla konwerterów "unicable" tej firmy konwertery "zwykłe": Inverto, dobrane adekwatnie do instalacji, rekomendacja tylko dla "zwykłych" (nie "unicable") konwerterów tej firmy

Inverto IDLB-QUDL41-UNI2L-1PP / IDLB-QUDL42-UNI2L-1PP (obie konstrukcje to "Black", Unicable 4x + Twin) też? testowałeś to?

Przy zwykłej instalacji (bez multiswitcha) QUAD. Sugeruje Inverto Red, albo Inverto Black Ultra, przy czym w wypadku tego drugiego należy liczyć się z koniecznością dokupienia tłumików sygnału, bo Black Ultra może przy tak krótkich kablach dawać zbyt silny sygnał. Jestem "fanem" tej marki ze względu na stabilność częstotliwości czy tłumienie sygnału na podobnej częstotliwości przy przeciwnej polaryzacji lepsze niż w wypadku innych konwerterów. One działają, zapominam że je mam. Natomiast o innych popularnych markach/modelach mógłbym całkiem grubą książkę z opisami kłopotów popełnić.

Pytanie: karta obustronnie ciemnoszara z kolorowymi małymi kwadratami przy krawędzi czy czarna od spodu i czarno-czerwono-szara na górze od strony styków? Na mój nos (zwłaszcza, że problemy były też za czasu użytkowania w spliterze) objawy wyglądają na nie do końca uszkodzoną kartę, tj. działającą "w ogóle", ale niestabilnie. Dziwnie przypuszczam, że to szara wersja. Sugeruje podreptać do punktu obsługi (po uprzednim sprawdzeniu w którym można to zrobić, nie każdy to może przeprowadzić) w celu wykonania (od ręki) wymiany...

1. do katalogu który zdefiniujesz w konfigu, w sekcji [webif] który definiujesz parametrem "httpscript" 2. tak, bashowe,

Tym bardziej nic z tym nie zrobi :)

Aby mieć pewność, że tak się dzieje tylko na jednym odbiorniku, to powinieneś mieć logi za ten sam czas logi z dreamboxa i nboxa. Tak czy inaczej, nic z tym nie zrobisz, ustawienia masz ok.

W takim razie "to by było na tyle", pozostałe przyczyny są od Ciebie niezależne i nie masz na nie wpływu.

Jakby to napisać. Po lekturze niektórych dziko absurdalnych, błędnych, niedokładnych zgłoszeń problemów na bugtrackerze developerów oscama przestałem przyjmować "oczywiste" założenia, wolę się upewniać co użytkowni robi. Co do rozmiaru binarki - cóż, to jest zależne od parametrów kompilacji. Jeśli wybrałeś dołączenie do kodu oscama bibliotek potrzebnych mu do pracy, to może być hm "słusznie duża". Binarka która zakłada obecność w systemie bibliotek będzie sporo mniejsza...

Doceniam jedynie słuszny zapał :) Jednak ja do tematu podchodzę uwzględniając szerszą perspektywę, gdyż na naszym systemie segmentation fault nie powinien się w ogóle zdarzyć, a opisywany objaw (pomijając egzotyczny problem z odbiornikiem) pasuje także do przypadku wgrania niewłaściwej binarki na niewłaściwy odbiornik, czyli binarki dla platformy SH4 na odbiornik pracujący w ramach innej platformy (np. mips w dreambox / vu).

Albo smartcl źle odczytuje dane z tego dysku, albo masz poważny problem i jesteś na najlepszej drodze do usmażenia dysku.

Najbardziej prawdopodobna możliwość to ustawione rozłączanie po zdefiniowanym czasie nieaktywnych użytkowników na serwerze w homesharingu (parametr clientmaxidle) ORAZ brak w definicji czytnika uaktywnionego keepalive dla cccam (parametr ccckeepalive).

podstawowe pytanie: na jaki odbiornik wgrywasz binarki, których próba uruchomienia skutkuje "Segmentation fault"? zapominasz, że tak się będzie dziać pod warunkiem, że w odbiorniku jest nasz system, w innym wypadku obsługi oscam_user nie ma.

Padło. Leży forum, leży bugtracker, leży svn upraszczając: svn = narzędzie do zautomatyzowanego ściągania kodu, narzucania poprawek itd., w tym kontekście server developerów oscama.

Oglądałeś kiedykolwiek logi? Wyłączony (w sensie w standby) odbiornik = brak wybranego kanału = brak pracy dvbapi = brak zadania dla oscam = brak dekodowania. Wyjątkowo sporadycznie zdarza się, że dekodowanie idzie (gdyż dvbapi jest aktywne) pomimo braku wyświetlania na, lecz to się zdarza wyłącznie po restarcie boxa będącego w trybie standby i w przy wgranej wtyczce autostandby. Ponadto zużycie CPU przez oscam (oscam, nie enigme2) jest wybitnie niskie. Bardzo upraszczając: Obciążenie CPU generuje głównie enigma2 i "wyświetlanie" obrazu, jak nie ma obrazu, to (prawie) nie ma obciążenia CPU. Z tego powodu nie ma przesłanek by nawet myśleć o wyłączaniu/włączaniu wraz z "wyłączeniem" i włączeniem odbiornika. Po prostu to nie ma najmniejszego sensu. Technicznie dałoby się to zrobić, tylko po co?

Może ktoś prowadzi, ale na pewno nie my. Lista wspieranych odbiorników przez G OS nie uległa zmianie.

Moim zdaniem to zbieg okoliczności i losowe problemy (źle ustawiony?) z serwerem który Ci obsługuje homesharing. Ja problemu (pojedyncze raz na parędziesiąt tysięcy zapytań niestety nadal się mogą zdarzać, niezależnie od wersji) z timeoutami na "naszym" 9300 nie widziałem, mimo że to moja podstawowa wersja, która pracuje nonstop całymi tygodniami...

Jest to jeden z powodów, który przyczynił się do wyboru tej wersji jako systemowej. Przy okazji dodatkowa informacja: patrząc na aktualnie powolne tempo testów timepatcha/clockfixa (wprowadzania kolejnych jego części w oficjalny kod oraz braku patcha na nowe wersje), wszystko wskazuje na to, że 9300 pozostanie na długo wersją systemową. Najwyżej 9300 będzie otrzymywało ręcznie dodawane kolejne poprawki, tak jak miało to miejsce dzisiaj. Coś masz nie tak u siebie, ewentualnie byłeś jedną z osób, które pobrały błędne nowe 9300 (zamieszczone około 14:55) zanim je podmieniłem na prawidłowe (zamieszczone około 18:11). Świeżo skompilowane 9300 qdwf-slim-scriptsfix-clockfix_9300-nolibusb-noextreaders pracuje u mnie od 3 godzin, wcześniej (po przerwaniu testów "aktualnych" wersji z zmianami głównie webif), starsza u mnie 5 dni działała, u innych testerów po 20-30 dni...

Jeśli rzeczywiście chcesz się zająć własnymi testami, to odezwij się na PW, aczkolwiek to jest utrudnianie sobie życia. Wgrane ponownie 9300 z najnowszym zestawem patchów, źle dobrałem opcje podczas kompilacji o godzinie 15tej...

w skrócie: trzeba sobie ustawić środowisko do kompilowania, odpowiednio dla odbiorników / linuxa, czytając odpowiednie info z FAQ/wiki oscama, trzeba skądś (np. z forum developerów oscama) mieć patche, trzeba zapoznać się z zasadami posługiwania się poleceniem patch trzeba sobie radzić z kompilacją... "nasze" 9300, już zamieszczone na forum, dziś dostało kolejny patch (z 9489), poprawiający obsługę skryptów.

Nie wdając się w szczegóły (i nie powtarzając tego samego w kółko), problem z timeoutami (w większości) powstaje na odbiornikach. Nasze 9300 patchowane to obchodzi. Plus widać (gdy odbiornik obsługuje multiroom) wyraźnie lepszą pracę patchowanego 9300 jako serwer. Jeśli z jakiś względów ktoś nie ma możliwości skompilowania dla siebie binarki dla linuxa, to najprościej użyć oficjalnych, dla 64bit linuxa stąd.

Proszę bardzo. Co do binarki na komputer. Z przeprowadzonych testów wynika, że po częściowym wprowadzeniu timepatch w kod, wszystkie nowe wersje na komputery chodzą mniej więcej porównywalnie. Co najwyżej usuwane są drobne błędy (ostatnio w gbox), przebudowywany jest webif, czy dodawane funkcje...

w takim razie pozostaje Tobie porównać ustawienia.

tak, ta rada się nazywa oscam 9300 z patchami, dopóki nie będzie w pełni zintegrowany z kodem timepatch, to timeouty mogą się zdarzać.

Krótko: bez logów, to co najwyżej można zgadywać co jest przyczyną, jako że piszesz, iż w odbiorniku jest "karta" ze splitera, to zgaduje, że przyczyną mogą być źle dobrane parametry mhz, cardmhz, a przez to zawieszanie się komunikacji czytnik<>karta, w najgorszym wypadku spliter może być nie do końca zgodny z odbiornikiem, na co może nie być rady, podanie "prawidłowych" wartości wspomnianych parametrów nie ma sensu, ze względu na różnorodność spliterów musisz samodzielnie eksperymentować