robert_cz

z tego co czytałem, to jest kwestia wkompilowania, lub nie SCP. @tux, takie pytanie edukacyjne, z jakimi opcjami kompilowałeś Twoją wersję?

@Tux, ja się z Tobą zgadzam, że SSH jest dobre i nawet nie ma co rozmawiać o telnecie. Pytanie jest tylko czy można coś zaoszczędzić zarówno w nand, jak i w RAM, właśnie dlatego, że te pikony tyle zajmują ;-) A na poważnie, soft się rozwija i dzięki Ci za to. Absolutnie się nie upieram, tak tylko zauważyłem i się podzieliłem spostrzeżeniem i jak by można było, to ja chętnie bym tą redukcje na kliencie SSH i SCP przyjął, serwer jest serwer, jasna sprawa. @tux, trochę roboty jest, bo ciągle "drewniano" mi idzie kompilowanie, ale oczywiście się staram coś tam sobie dłubać.

Obydwie z nowych paczek są obowiązkowe? Jak najbardziej rozumiem, że bezpieczeństwo i większa funkcjonalność, ale tak jak mawia mój ulubiony twórca systemu pod sh4: "to tylko tuner z małą ilością dostępnego miejsca i liczy się każdy kB" :-) Te 300kB to czasami potrafi uratować.

Absolutnie się nie upieram. A jaka funkcjonalność Cie przekonała? Może by się dało zrobić tak jak z wget, że w podstawowej wersji jest Dropbear, a jak ktoś chce, to może sobie zainstalować pełną paczkę OpenSSH? A tak przy okazji, co Ty na to, żeby rozdzielić OpenSSH na dwie paczki, obowiązkowy serwer i opcjonalny klient? Z 1MB by się oszczędziło, a 90% użytkowników których znam, nawet nie wie, że może z jednego tunera poprzez ssh łączyć się do kolejnego. Dodatkowo klient nie jest obowiązkowy żeby tuner działał jako tuner, prawda?

@Tux pytanko. Czemu zrezygnowano z "cienkiej wersji" ssh Dropbear na rzecz pełnego ssh? Pytam z ciekawości, bo widzę, że Dropbear jest ciągle rozwijany i oszczędziłby sporo miejsca w nand. z tego co mówi opkg, to jest to około 2MB: GraterliaOS:~# opkg info openssh Package: openssh Version: 6.9.p1-1 Depends: graterlia-core Status: install user installed Section: graterlia/system Architecture: sh4 Maintainer: tux MD5Sum: 5e9e052e797d8dcf297d1a93868ecb84 Size: 2120654 Filename: openssh_6.9.p1-1_sh4.ipk Conffiles: /etc/openssh/ssh_config 564d832ae2f91d65f8e901fa9b20e5a9 /etc/openssh/sshd_config c9b4d9e26a8802c86d81f4744bff8a3a Source: none Description: OpenSSH Server & Client 6.8p1 https://matt.ucc.asn.au/dropbear/dropbear.html

j00zek już to poprawił, dzięki. Mam jeszcze jeden problem. nbox przez CEC wyłącza mi przy przechodzeniu w moderate telewizor, niezależnie, czy telewizor jest przełączony na źródło zdefiniowane w CEC, czy nie. Co Wy na to, żeby przed wysłaniem polecenia wyłączenia nbox "zapytał" telewizor na jakim źródle teraz pracuje i jak się zgadza z tym co jest w konfiguracji CEC, to wysyłamy sygnał wyłączenia, jak nie, to nic nie wysyłamy? Jakiś programista mi podpowie jak czytać jakie odpowiedzi od telewizora przychodzą po HDMI CEC? To bym sobie przetestował. PS. Może te dwa skrypty dotyczące CEC lepiej jak by były w paczce z CEC, a nie w paczce ze skryptami. Taki tam pomysł optymalizacyjny.

bardzo dziękuję.

@richter Zauważyli koledzy, że na Twojej liście w folderze TNK SD są już nieistniejące wersje SD kanałów: Canal+, Canal+ Film, etc. mógłbyś poprawić, poproszę?

Zauważyłem dziwne zachowanie. Mimo ustawienia w opcjach HDMI-CEC HDMI2, po wybudzanie z moderate shutdown telewizor z uporem maniaka włącza się na HDMI1 zamiast na ustawiony w opcjach HDMI2. Macie tak samo?

Nie bądź takim pesymistą. Przecież możesz spełnić swoje marzenie. ;) A na poważnie. Mój TV nie ma CEC, więc nie pomogę. A to mam pytanko. w moderate port HDMI jest całkiem wyłączany, czy tylko wyprowadzenie wideo jest wyłączone? Ma ktoś pomysł jak nasłuchiwać na HDMI pakietów, żeby obudzić tuner jak przyjdzie właściwy?

Działa świetnie, wielkie dzięki. Tak jeszcze, ale pewnie w sferze marzeń pozostanie, marzy mi się wybudzanie z moderate przez telewizor po HDMI.

Dodane do opkg jako nowa paczka, czy aktualizacja?

Chyba dlatego, że dla małego pilota nie działa wybudzanie. Mnie też spotkał ten problem

Nie wiem, czy u Was też, ale u mnie zauważyłem, że przestało działać aktualizowanie tapety z National Geographic. Z Bing działa OK.

Dzięki za pomoc, okazuje się, że podejrzenia miałem słuszne, to błąd pamięci: memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 5MB (5242880 bytes) got 5MB (5242880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok FAILURE: 0x00000001 != 0xa2000a01 at offset 0x000ce274. FAILURE: 0x00000000 != 0x3d00b000 at offset 0x000ce278. FAILURE: 0x00000000 != 0x3000b400 at offset 0x000e2584. FAILURE: 0x00000001 != 0x9300e601 at offset 0x000e2588. Compare DIV : FAILURE: 0x7fff9d53 != 0xffff9f53 at offset 0x000ce274. FAILURE: 0x7fff9d52 != 0x7fffbd52 at offset 0x000ce278. FAILURE: 0x7fff9d52 != 0x7fffbd52 at offset 0x000e2584. FAILURE: 0x7fff9d53 != 0xffffff53 at offset 0x000e2588. Compare OR : FAILURE: 0x77fb0403 != 0xf7fb0603 at offset 0x000ce274. FAILURE: 0x77fb0402 != 0x77fb2402 at offset 0x000ce278. FAILURE: 0x77fb0402 != 0x77fb2402 at offset 0x000e2584. FAILURE: 0x77fb0403 != 0xf7fb6603 at offset 0x000e2588. Compare AND : Sequential Increment: ok Solid Bits : ok Block Sequential : testing 38FAILURE: 0x25262526 != 0x26262626 at offset 0x001ec810. FAILURE: 0x25262526 != 0x26262626 at offset 0x001ec814. Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : testing 11FAILURE: 0x00000400 != 0x00000800 at offset 0x00199c08. FAILURE: 0x00000400 != 0x00000800 at offset 0x00199c0c. 8-bit Writes : ok 16-bit Writes : ok Można prosić o dodanie programu jako opcjonalnej paczki? Pytanie off-topic: Jak po adresach zlokalizować o którą kość chodzi?

Witam, Czy ktoś wie czy uda się coś takiego skompilować na nasze tunerki: https://github.com/jnavila/memtester Mam tuner który dziwnie mi się zachowuje i wydaje mi się, że to może być błąd pamięci, wszystko inne włącznie z dodatkowym chłodzeniem już sprawdziłem.

Pomoże ktoś z tym błędem w irrecord? ow hold down button "KEY_1". Something went wrong. Please try again. (9 retries left) Something went wrong. Please try again. (8 retries left) Something went wrong. Please try again. (7 retries left) Something went wrong. Please try again. (6 retries left) Something went wrong. Please try again. (5 retries left) Something went wrong. Please try again. (4 retries left) Something went wrong. Please try again. (3 retries left) Something went wrong. Please try again. (2 retries left) Something went wrong. Please try again. (1 retries left) Something went wrong. Dziwne, nawet standardowe piloty mi się tak zachowują na BSKA, czy to może być jakiś problem BSKA?

Dobra, coś więcej zrozumiałem i mam garść obserwacji. Po przejściu do moderate irw nie pokazuje naciśnięć żadnego z klawiszy poza Power, wygląda na to, że te pozostałe kody "przechwytuje" wait4button. wait4button nie mogę zabić, bo wtedy tuner wyjdzie z moderate, więc zabiłem lircd, czym zerwałem połączenie wait4button z lircd, dzięki temu irw w moderate już pokazuje naciśnięcia innych klawiszy. duży pilot tryb moderate: 193f442a13830100 00 KEY_POWER& RC-nBox(XMP) 193f442a1d830700 00 KEY_UP& RC-nBox(XMP) 193f442a11832100 00 KEY_DOWN& RC-nBox(XMP) 193f442a1f835000 00 KEY_RIGHT& RC-nBox(XMP) 193f442a1e835100 00 KEY_LEFT& RC-nBox(XMP) 193f442a1c834400 00 KEY_MODE& RC-nBox(XMP) 193f442a1e830600 00 KEY_OPTION& RC-nBox(XMP) 193f442a1f830500 00 KEY_INFO& RC-nBox(XMP) 193f442a1a832800 00 KEY_VOLUMEDOWN& RC-nBox(XMP) 193f442a1c830800 00 KEY_VOLUMEUP& RC-nBox(XMP) 193f442a1f835000 00 KEY_RIGHT& RC-nBox(XMP) duży pilot tryb normalny: 193f442a19032100 00 KEY_DOWN RC-nBox(XMP) 193f442a11832100 00 KEY_DOWN& RC-nBox(XMP) 193f442a16035100 00 KEY_LEFT RC-nBox(XMP) 193f442a1e835100 00 KEY_LEFT& RC-nBox(XMP) 193f442a15030700 00 KEY_UP RC-nBox(XMP) 193f442a1d830700 00 KEY_UP& RC-nBox(XMP) Małego pilota w trybie moderate irw w ogóle nie czyta. Wygląda tak jak by w trybie moderate lircd działał inaczej, tak jak by nie widział (nawet dla dużego pilota) naciśnięcia, tylko dopiero przytrzymanie. Tak jak mi to mickey wyjaśnił: " 193f442a1b030100 00 KEY_POWER RC-nBox(XMP) - naciśnięto POWER 193f442a13830100 00 KEY_POWER& RC-nBox(XMP) - ciągle jest wciśnięty POWER (przypadłość pilota z nboksa: przytrzymany klawisz generuje inny kod, stąd nazwa KEY_POWER&)" Ma ktoś jakieś pomysły dlaczego tak jest, że w moderate lircd nie widzi kodu naciśnięcia klawisza, tylko dopiero kod przytrzymania? Aktualizacja: Postanowiłem zrobić sobie plik z odczytami pilota w trybie moderate i przy irrecord mam taki błąd przy tym "losowym wciskaniu klawiszy", w normalnym trybie go niema: irrecord: WARNING: read invalid data from device /dev/lirc dla dużego pilota jest ten błąd, ale potem kilka kolejnych naciśnięć czyta, a dla małego jest tylko ten błąd. dla małego pilota

j00zek, nie jest tak, że nie wierzę, tylko chce zrobić coś z moją "niewiedzą", pomożesz?

OK, ale w trybie moderate nie wykrywa żadnego przycisku poza power, więc jeśli pilot wysyła coś innego, to irw nic nie pokaże. coś z tym & jest na rzeczy, bo w mapach klawiszy to są dwa różne kody z & i bez. A gdzie mogę znaleźć to powiązanie 116 z odpowiednim przyciskiem i gdzie jest wywołanie wait4button przy uruchamianiu moderate, bo nie mogę znaleźć.

Zrobiłem i przy naciśnięciu Power na małym pilocie nic a przy innym: 193f442a13830100 00 KEY_POWER& RC-nBox(XMP) Postanowiłem też sprawdzić i wygląda na to, że wait4button czeka na przycisk 116 = KEY_POWER&. Niestety mały pilot daje tylko: 193f442a1b030100 00 KEY_POWER RC-nBox(XMP) A duży daje obydwa: 193f442a1b030100 00 KEY_POWER RC-nBox(XMP) 193f442a13830100 00 KEY_POWER& RC-nBox(XMP) dlatego działa. Chciałbym zrobić kilka dodatkowych testów, ale niestety brakuje mi wiedzy. Pomoże ktoś? Szukam jaki jest kod przycisku KEY_POWER (ten bez &) dla wait4button, A drugie czego szukam, to jak, gdzie w moderateshutdown wywoływany jest wait4button 116?

Słyszałem, że są problemy z integracją autofs 5.x (za bardzo puchnie przy kompilacji), dlatego postanowiłem wrócić do pomysłu odchudzenia autofs: Skasowałem proponowane przeze mnie pliki i zrestartowałem demona, nie wyskoczył żaden z błędów. Odchudzenie, moim zdaniem nie wywiera negatywnego wpływu na system. [Aktualizacja] po dłuższym czasie obserwacji, nie widzę problemów, moim zdaniem można wyrzucić z paczki te kilka plików, jak pisałem powyżej: /usr/lib/autofs/lookup_userhome.so /usr/lib/autofs/lookup_yp.so /usr/lib/autofs/lookup_nisplus.so /usr/lib/autofs/mount_afs.so /usr/lib/autofs/mount_changer.so Dodatkowo znalazłem, że w pliku konfiguracyjnym: /etc/auto.hotplug jest odniesienie do urządzeń których nie mamy w dev i osobiście nie wyobrażam sobie tylu podłączonych dysków: ... sda9 -fstype=auto,noatime,nodiratime :/dev/sda9 ... sdb9 -fstype=auto,noatime,nodiratime :/dev/sdb9 ... sdc9 -fstype=auto,noatime,nodiratime :/dev/sdc9 ... sdd9 -fstype=auto,noatime,nodiratime :/dev/sdd9 sde1 -fstype=auto,noatime,nodiratime :/dev/sde1 sde2 -fstype=auto,noatime,nodiratime :/dev/sde2 sde3 -fstype=auto,noatime,nodiratime :/dev/sde3 sde4 -fstype=auto,noatime,nodiratime :/dev/sde4 sde5 -fstype=auto,noatime,nodiratime :/dev/sde5 sde6 -fstype=auto,noatime,nodiratime :/dev/sde6 sde7 -fstype=auto,noatime,nodiratime :/dev/sde7 sde8 -fstype=auto,noatime,nodiratime :/dev/sde8 sde9 -fstype=auto,noatime,nodiratime :/dev/sde9 sdf1 -fstype=auto,noatime,nodiratime :/dev/sdf1 sdf2 -fstype=auto,noatime,nodiratime :/dev/sdf2 sdf3 -fstype=auto,noatime,nodiratime :/dev/sdf3 sdf4 -fstype=auto,noatime,nodiratime :/dev/sdf4 sdf5 -fstype=auto,noatime,nodiratime :/dev/sdf5 sdf6 -fstype=auto,noatime,nodiratime :/dev/sdf6 sdf7 -fstype=auto,noatime,nodiratime :/dev/sdf7 sdf8 -fstype=auto,noatime,nodiratime :/dev/sdf8 sdf9 -fstype=auto,noatime,nodiratime :/dev/sdf9 sdg1 -fstype=auto,noatime,nodiratime :/dev/sdg1 sdg2 -fstype=auto,noatime,nodiratime :/dev/sdg2 sdg3 -fstype=auto,noatime,nodiratime :/dev/sdg3 sdg4 -fstype=auto,noatime,nodiratime :/dev/sdg4 sdg5 -fstype=auto,noatime,nodiratime :/dev/sdg5 sdg6 -fstype=auto,noatime,nodiratime :/dev/sdg6 sdg7 -fstype=auto,noatime,nodiratime :/dev/sdg7 sdg8 -fstype=auto,noatime,nodiratime :/dev/sdg8 sdg9 -fstype=auto,noatime,nodiratime :/dev/sdg9 sdh1 -fstype=auto,noatime,nodiratime :/dev/sdh1 sdh2 -fstype=auto,noatime,nodiratime :/dev/sdh2 sdh3 -fstype=auto,noatime,nodiratime :/dev/sdh3 sdh4 -fstype=auto,noatime,nodiratime :/dev/sdh4 sdh5 -fstype=auto,noatime,nodiratime :/dev/sdh5 sdh6 -fstype=auto,noatime,nodiratime :/dev/sdh6 sdh7 -fstype=auto,noatime,nodiratime :/dev/sdh7 sdh8 -fstype=auto,noatime,nodiratime :/dev/sdh8 sdh9 -fstype=auto,noatime,nodiratime :/dev/sdh9 Może to jest dobry moment na małą odchudzającą modyfikację tej paczki? [Aktualizacja 2] Postanowiłem zrobić aktualizację paczki, testowałem i wygląda dobrze, zmieniłem ostatnią cyfrę z 6 na 7. autofs_4.1.4.7_sh4.ipk [Aktualizacja 3] @tux w zaktualizowanej wersji autofs - 4.1.4-2 wyrzucił zbędne wpisy. Zobaczy ktoś i wrzuci do test jeśli można prosić? autofs_4.1.4.7_sh4.ipk

Mam wielką prośbę, można prosić aby pusty plik blacklist nie nie był częścią paczki z listami? Bo mi OPKG cały czas zastępuje plik z zablokowanymi kanałami, albo żeby co najmniej był plikiem konfiguracyjnym, jeśli ktoś by wprowadził niepusty plik z kanałami np xxx.

Jeszcze nie mogłem sprawdzić, nie ma mnie w domu. Dzięki za modyfikację, na 100% sprawdzę, ale wydaje mi się, że 10 to trochę dużo, są takie nboxy które nie mają karty sieciowej i tam o te 10 prób po 3 sekundy się przedłuży.

Dobra poszukam dokładniej w dokumentacji standardu Ethernet zamiast w prezentacji jednego z producentów który dane z tego standardu prezentuje.