tux

Powtarza się pewien zwrot w logu: No space left on device.

@jakisneo Czy uważasz, że podałeś dokładny opis?

Napisz swoja procedure wgrania listy kanalow w punktach (dokladny opis).

No to dwa polecenia. Jedno z pakietu mencoder i jedno z pakietu ffmpeg. Nie wiem co w tym trudnego. Nie ma co prawda ładnych okienek, kreatorka itp. ale mimo wszystko podałem przepis chyba jasno.

Akurat BCM faktycznie tak działa i sam widziałem to na oczy w kilku rozwiązaniach. Wtykam kabel i NIC. Po 1,5 sekundy zazwyczaj zastanawiam się czy nie mam walniętego kabla. A tu niespodzianka, jeszcze z sekundę i mam LINKA :) W załączniku masz busybox z -t 10 wkompilowanym (prawdopodobnie bo nie mam jak teraz sprawdzić). Podmień (pamiętaj o wypakowaniu i 755). Napisz czy masz 10 zapytań. busybox.gz

Dla BCM :) Teraz rozumiem dlaczego tak mocno wielu trzyma się z daleka od tej firmy.

Jeżeli SD i MPEG2!: mencoder Nazwa_Pliku.TS -o OUT.mkv -ovc x264 -x264encopts pass=1:preset=AAA:fast_pskip=0:tune=film:frameref=15:bitrate=BITRATE:threads=ilosc_redzeni Gdzie: AAA to: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo BITRATE: Przepustowość w Kilobitach (np. 2500) Jeżeli HD MPEG4: ffmpeg -i Nazwa_Pliku.TS -deinterlace -c:v libx264 -preset AAA -tune film -crf 21 -r 50 -vf scale=-1:720 -c:a copy output.ts Gdzie AAA: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo -crf Parametr jakości. Im mniejsza wartość - tym lepsza jakość.

Zacznijmy od tego ze TS to nie tylko Mpeg2. Z jakiego janalu nagrane sa te bajki?

Mpeg2 czy Mpeg4 ?

A cel tego działania jaki jest?

1.5h filmu do w miarę dobrej jakości 4 rdzenie po 2,5GHz roia około 3h. Nie lidze nawet ile będzie to samo robił jeden rdzeń 266MHz.

Tak, będzie to problem. Dlaczego? Dlatego, że nie każdy używa sieci. Zakładając, że sieci może nie być to już nie jedna czy dwie linie a cały system kontroli czy sieciówka jest w ogóle skonfigurowana, następnie czy jest włączona w konfiguracji i jeszcze na koniec kawałek inteligencji omijającej konfigurację sieci jak nie dostanie IP po kilku razach. Jeżeli masz pomysł i chcesz coś włożyć w GOS - napisz coś takiego. Dodamy :) (po testach w gałęzi TEST). Systemy wbudowane mają to do siebie, że działają tak jakie są założenia. W tym wypadku cały system obsługi sieci jest minimalny bo zasoby (każde) boxa nie pozwalają na implementację pełnej obsługi. Przy tym założeniu sieć na boxie działa całkowicie prawidłowo. Jednym z założeń jest to, że druga strona (serwer) odpowiada na zapytania jak powinien a sam link jest ustanawiany od razu a nie po bliżej nieokreślonym czasie zastanawiania się co by tu zrobić. Przy czym w przypadku nBoxa stawiam na to, że są różne wersje HARDWARE i po różnych przejściach bo kupuje się nie fabrycznie nowe tunery a odnowione. Wystarczy, że nasz nBox przeżył kilka "ataków" wyższego napięcia i ma transformatory na wejściu LAN nadwyrężone. Wtedy nie trudno o długi proces negocjacji.

Dla systemu Embedded TAK. Zauważ, że masz do dyspozycji aż 60MB w NAND. Spróbuj tam wepchnąć pełnego klienta DHCP wraz ze wszystkimi jego zależnościami. Systemy Embedded rządzą się innymi prawami. Na tym z mojej strony KONIEC. KOMPLETNY KONIEC. Dyskusja jest bez sensu póki nie zrozumiesz, że nie masz do czynienia z pełnym systemem Linux a wersją, która ma wykonać konkretne zadania i implementacja każdej funkcjonalności nie jest możliwa. A tak poza tym. Skoro u mnie nie wysyła w kosmos to znaczy, że mój serwer DHCP odpowiada. Skoro u Ciebie jest inaczej to może zacznij od doprowadzenia serwera DHCP do stanu, w którym zacznie odpowiadać na zapytania. Jeżeli link masz spóźniony to doprowadź u siebie do tego, żeby był ustanawiany w odpowiednim czasie. Może problemem są niektóre boxy? Może rodzaj przeróbki, może inny czynnik? Zawsze najłatwiej szukać wszędzie byle nie tam gdzie trzeba.

Robiłem analizę. Od 1 do 3. Zależy od tunera i szybkości jego startu. Jednak nie ma to absolutnie żadnego znaczenia ponieważ 99% ludzi nie widzi problemu. Nie ma wylewu setek czy tysięcy postów po forach. Czasem coś komuś nie działa, ale to już normalne. Zawsze się znajdzie jakiś wyjątek. A jako ciekawostkę do Twojej analizy (ja już daję sobie spokój z odpisaniem) napiszę: weź stoper do ręki; podepnij się do debug; i teraz: - sprawdź czas odpowiedzi PING na IP tunera przy DHCP ON; - sprawdź czas odpowiedzi PING na IP tunera przy stałym IP. Zdziwisz się jak tuner ze stałym IP odpowie wcześniej niż z DHCP. Wniosek jest jeden - to nie tuner wysyła zapytanie w powietrze, to serwer DHCP odpowiada dłużej niż 3 sec i kończy się to jak się kończy. Może wystarczy zmienić na serwerze DHCP czasy oczekiwania? Ale jak pisałem wyżej - to już nie mój problem. U mnie link każdy dekoder uzyskuje w czasie poniże 0,5 sekundy od czasu wpięcia kabla pod warunkiem, że karta sieciowa wstała (u-boot się uruchomił lub załadował się sterownik podczas startu). Biorąc pod uwagę, iż sterownik karty załadowany jest kilka sekund przed odpaleniem skryptu sieci to do jasnej XXXXX co rogi reszta sieci żeby się dogadać skoro u mnie jest to 0,5sec. Wtykam kable i zaraz świeci.

Jeżeli rozmowa merytoryczna to jedynie przyznanie Ci racji i dostosowanie się do Ciebie i tej małej grupy, którą reprezentujesz to tej rozmowy nie będzie. Nie jest to możliwe. Podałem Ci konkrety. Jeżeli coś działa nie tak u Ciebie i tej małej grupy osób - sami szukajcie co. Ja nie mam czasu na zawracanie mi głowy czymś takim. Jeżeli znajdziesz konkretny błąd, naprawisz to i podeślesz rozwiązanie - możemy pomyśleć nad wdrożeniem. Póki co wszystkim poza maleńką ilością osób działa. Dla mnie koniec tematu i nie zamierzam dalej go kontynuować. W sumie nie tylko ja mam już dość.

Jeżeli jest to "konsumencke" Cisco to mnie nie przekona! Jest to temat na osobny wątek. W skrócie - Cisco chciało dać tanie COŚ dla domowego użytku. Wyszło koszmarnie a jeszcze zepsuli to co robił Linksys po tym jak go kupili. W wyższych modelach (ale to już dziesiątki tysięcy złotych) tego problemu mieć nie będziesz. Wracając do zapytań DHCP. Obecnie w GOS jest ich chyba 10. Nie pamiętam teraz, wybacz.... Działa to tak: tuner śle 3x zapytanie do DHCP; po otrzymaniu pierwszego serwer robi analizę i pcha odpowiedź i tutaj - tuner dostanie odpowiedź pomiędzy 1-2 → nie da już zapytania 3; - tuner dostanie odpowiedź pomiędzy 2-3 → dostanie adres za trzecią odpowiedzią itd. Na przestrzeni lat używałem dwóch daemonów jako DHCP Server. na PLD - DHCP - daemon można by napisać oryginalny; na PLD - DNS Masq - lekki daemon cacheujący DNS i przy okazji posiadający funkcję DHCP; Za każdym razem konfiguracja była taka sama: każde urządzenie w sieci dostaje IP na podstawie MAC; jest pula pięciu IP przyznawanych MAC spoza listy. W każdym przypadku DZIAŁA. Jako, że jestem w trakcie modernizacji sieci w domu (będzie osobny post z info co zrobiłem i dlaczego bo może się komuś przydać) przetestowałem też kilka innych rozwiązań szukając urządzeń do konkretnych zadań. I tak szukając AP (bo potrzebowałem czegoś z 5GHz bo na 2,4GHz u mnie nie da się już pracować) przetestowałem je również jako routery. Do zawodów stanęły: Netgear WNDR4300; Asus RT-N53; Asus RT-AC56U (został jak AP, ale o tym w innym poście); Dodatkowo bo miałem pod ręką to w celach naukowych (ten wątek) sprawdziłem: TP-Link TL-WR842ND; TP-Link TL-WR702N; Więcej nie miałem pod ręką. Sprawdziłem zarówno soft oficjalny jak i DD-WRT/OpenWrt tam gdzie się dało. Co bym nie wyczyniał i tak zawsze tuner za 2 lub 3 zapytaniem dostawał dane. Tyczy się to zarówno LAN jak i WiFi. Z kart WiFi testowałem na karcie Ferguson 03 i Tl-WN727N. Gdzie leży problem u Ciebie? Nie mam zielonego pojęcia, ale za diabła jasnego nie potrafię tego zreprodukować efektów, o których piszesz na pięciu urządzeniach, trzech wersjach softu na każdym z nich, dwóch sieciówkach WiFi i stosie kabli.

Skrypt od OPKG poprawiony. Przy następnej aktualizacji nie będzie tego problemu.

Pozwolę się też nie zgodzić i będę trwał w tym stanowisku. System Operacyjny dla Tunera SAT (o tym tu piszemy) to w zasadzie System Embedded. Ten system z założenia nie posiada 100% funkcjonalności pełnego OS. Założenie jest takie, że to, co może obciążać urządzenie, na którym działa taki OS, należy wyłączyć. Liczy się każdy wolny promil zasobów. Tutaj w przypadku sieci panuje zasada taka, że tuner dostaje IP i tyle. Nie zakłada się, że ktoś ma kiepską/złą/niezgodną ze standardem sieć i trzeba będzie kombinować jak koń pod górę, by to działało. Między innymi dlatego można wyłączyć DHCP i ustalić parametry na sztywno. [*]Zużywasz zasoby, gdyż masz kiepską/złą/niezgodną ze standardem sieć na dodatkowy daemon w RAM i "cykający" w odstępach czasu, bo może wreszcie ta kiepska/zła/niezgodna ze standardem sieć odpowie (albo i nie) oraz może przypadkiem zmieniły się parametry sieci. W GOS od samego początku nie popieramy obchodzenia problemów i nie ma takiej siły, żeby to zostało zmienione. Co innego, gdyby to miało coś istotnego naprawić. Rozwiązanie to jednak nie naprawia problemu , za to utwierdza osoby z kiepską/złą/niezgodną ze standardem siecią, że tak ma być, że to oni mają rację i reszta się myli. Jak ktoś ma kiepską/złą/niezgodną ze standardem sieć, niech sam sobie poprawia GOS pod swoją sieć i nie zawraca nam głowy. To nie my mamy coś źle, a ta osoba (na własną odpowiedzialność); Nie do pominięcia jest też fakt, że niewielka grupa osób chce zmusić wszystkich do zużywania zasobów, bo tak i już, bo im nie działa i błędnie zakładają, iż jest ich cała masa. [*]Przyśpieszy się, ale wyjdą dodatkowe problemy. Tobie i pewnie podobnym Tobie osobom będzie to wisieć, aczkolwiek: * NTP nie będzie działać poprawnie podczas startu. Nie będzie, bo jak sieć nie wstanie (a może wstać np. po 25 sekundach), to nie przejdzie sprawdzenie czy jest PING i NFP po prostu nie zsynchronizuje czasu, mimo iż sieć później wstała. Ma to jeszcze jeden pejoratywny skutek - brak synchronizacji czasu z netu == automatem włączony czas z TP, a to z kolei odbije się bardzo negatywnie na pracy OSCAM - to już było omawiane! * AutoFS i zasoby sieciowe - daemon wstanie, ale sieć później - zapomnij o działających udziałach; * CIFS i inne - podobna sytuacja co wyżej; Ogólnie dla garstki osób należy przeprojektować pół systemu, bo ich kiepską/złą/niezgodną ze standardem sieć niedomaga? Przypominam, że nadal mamy do czynienia z systemem typu Embedded! [*]Zakładanie odgórne, że WiFi - którego może nie być w ogóle, jak i sterownika - jest bezsensem samym w sobie. Dyskusja z mojej strony zakończona. GOS ma tę zaletę, że masz w miarę proste i porządnie napisane skrypty startowe - modyfikuj pod siebie, wolno Ci; [*]Zerknij jak działa NFS i zerknij do skryptów, a potem się wypowiadaj. Wybaczcie użytkownicy kiepskiej/źłej/niezgodnej ze standardem sieci, ale nikt w GOS dla Was nie będzie dostosowywał systemu. To Wy, moi mili, macie obowiązek, jeśli chcecie mieć coś poprawnie funkcjonującego, mieć tak wykonaną sieć, aby nie sprawiała problemów. Nie po to w GOS prostujemy każdy kawałek systemu, by potem cofać się i nagle wprowadzać "system obchodzenia problemów użytkowników", którzy nie potrafią zrozumieć, że problemem nie jest GOS, a coś u nich, w tym wypadku ich sieć.

[*]zużywasz zasoby tunera do obchodzenia problemu jakości sieci; [*]nie przyśpieszysz, chyba że wyłączysz NTP; inaczej ładowanie NTP na starcie straci sens; [*]i wybacz, ale dla mnie WIFI może nie istnieć, także może nie faworyzować danego połączenia [*]nie wiem czy wiesz, ale soft może startować z NTP - tu też będzie problem. Można by zastosować daemona, jednak tylko wtedy gdy jest DHCP, i tylko wtedy gdy ktoś ma problemy z siecią. Swoją drogą niedługo postaram się więcej wyjaśnić na temat sieci podczas opisywania domowego serwera.

sysbckp robi tylko kopię z NAND/NOR (póki co, do tego nie na każdym z odbiorników). Jeżeli chcesz wykonac kopię NOR ESI-88 to powinno działać. Jeżeli zaś kopia partycji na innym nośniku niż NOR to na razie pozostanie ręcznie wykonać kopię. Np. tak: mkdir /kikut; mount /dev/sdX /kikut cd /kikut tar -cvzf /hdd/backup/nasza_kopia_2015-04-23.tar.gz * cd ~ umount /kikut

@artur_n Czy ty kopiujesz działający system z zamontowanymi vistualnymi systemami plików?

Na początek to wypadałoby napisać podstawowe dane - to jest model odbiornika.

Przy tych podejrzeniach zerknij w partycje z systemu linux.

Nawet jakby użyć ffmpeg to prędzej byś zasnął jak niedźwiedź na zimę niż się doczekał produktu końcowego :)

Szczerze to nie mam pojęcia jak zadziałało. Nie mam Windows (ani innych produktów M$ od 1997 roku) a na NFS takich jaj nie miałem jak ty. Wszystko na zasobach NFS działa jak na dysku lokalnym.