Beiträge von poggenpower

    Hallo Sebbl,


    die Treiber sollten auch funktionieren, auch wenn ich es mit den aus dem DVB Forum gemacht habe.
    Die Firmware scheint auch korrekt sein.


    Code
    root@poempel:~# md5sum /lib/firmware/dvb-fe-ds3000.fw
    a32d17910c4f370073f9346e71d34b80  /lib/firmware/dvb-fe-ds3000.fw
    root@poempel:~#


    Spannend wäre, ob die Installation erfolgreich war und das /var/log/kern.log sagt.
    Damit es hier nicht zu viele Daten sind versuch mal ein:


    Code
    root@poempel:~# egrep -ie 'dvb|dw2102' /var/log/kern.log


    Gruß
    Thomas

    Moin,


    da ich obiges Gehäuse/System mit dem yavdr 0.4 getestet habe, hier meine Erfahrungen.
    Es klingt ja erst mal verlockend einen VDR ohne Lüfter laufen zu haben. Da ich eine SSD verbaut habe, macht das System wirklich keinen Mucks.


    Nach der Installation sieht das System auch funktionsfähig aus. d.h. die Hardware wird soweit erkannt, der VDR startet.
    Aufnahmen etc. funktionieren. Ich benutze die Mystique SaTiX-S2 Sky USB, für die man etwas frickeln muss, aber das liegt ja nicht am Shuttle.


    Wenn man dann ans finetuning geht, gibt es doch ein paar Nachteile.


    Ich habe keinen Restart des Systems zu entsprechenden Aufnahmen hinbekommen.
    Das BIOS ist da sehr sparsam und ermöglicht keine Einstellungen.
    Im Syslog findet man zwar hinweise, dass ein Wakeup aus S4 also Suspend to disk möglich sein sollte und auch die Einstellungen der RTC sind möglich, aber die Kiste startet einfach nicht neu.
    Davon mal ganz abgesehen, dass S4 zur Zeit vom yavdr nicht unterstützt wird und das noch eine ganze Menge gefrickel gewesen wäre.
    Aus S3 (suspend zu RAM) und S5 (Soft Off) wird die Kiste nicht wach.
    Wake on LAN funktioniert auch nicht. Der Verbaute Netzwerkchip kann es zwar, aber Shuttle hat die Unterstützung nicht ins System gebaut.
    Leider gibt es auch nicht die Einstellung, dass die Kiste nach einem schalten der Stromzufuhr automatisch startet. Mit letzten beiden Varianten könnte man ja noch was externes frickeln.
    Es gibt laut BIOS noch die Möglichkeit eines "Wake on USB", aber hier ist mir nichts gescheites eingefallen, wie ich die Kiste darüber zu bestimmten Zeiten wecken kann.


    Die Kiste durchlaufen zu lassen war mir dann doch ein wenig zu unökologisch/unökonomisch, denn das System zieht ~25 WATT.


    Ein weiteres Manko ist der Ethernet Chip, ich bin mir nicht sicher ob er ohne aktualisierten Treiber gar nicht laufen würde, aber auch mit der aktuellsten Version habe ich keinen 1GBit Link hinbekommen.
    Da mein VDR seine Aufnahmen auf ein NAS legen soll, sind Jumboframes (geht nur mit 1000baseT) ein riesen Performace gewinn.


    Fazit:
    Der Shuttel ist eine schöne Kiste, die keinen Mucks von sich gibt. Auf dem Standfuß ist die Luftzirkulation auch so gut, dass das System nicht beunruhigend heiss wird.
    Wer keine Wake-Up und kein schnelles LAN braucht, der hat sicherlich ein wohnzimmertaugliches Gerät.


    Gruß
    Thomas

    Hi,


    ich habe noch ein bisschen rum probiert und recherchiert.


    Meine Idee ist nicht einen Poweroff Kernel zu booten, da das erstellen und warten einer initrd zu aufwendig ist, sondern per Kernelparameter ein abgespecktes System zu booten, dass dann den S4 auslöst.
    Dabei bin ich auf einen Konfigurationsparameter von "init" gestoßen:


    Aus der man-Page, bzw. --help


    Code
    thl@lenz:~$ sudo init --help
    Usage: init [OPTION]...
    Prozessverwaltungsdienst
    
    
    Options:
          --confdir=DIR           specify alternative directory to load configuration files from


    Damit könnte man z.b. in /etc/init-s4 nur die Scripte ablegen, die man wirklich braucht um runter zu fahren.


    Doof ist nur folgendes:


    Code
    thl@lenz:~$ sudo init --confdir /etc/init
    init: invalid option: --confdir
    Try `init --help' for more information.
    thl@lenz:~$


    Der Parameter funktioniert bei mir nicht. Auch auf einem "normalen" Ubuntu nicht. Hat jemand eine Idee?


    Gruß
    Thomas


    P.S: ein Boot mit init=/usr/sbin/pm-hibernate funktioniert leider auch nicht, da das script auf der Platte rumschreiben will und die FIlesysteme noch readonly gemountet sind.

    ich hab hier indertat nicht den besten empfang, bei hd kanälen sagt femon 45%, gut femon is ja nur ein schätzeisen, aber könnte schon möglich sein, das hier der fehler liegt. Greifst du über ssh zu, oder konfigurierst du den Rechner lokal? ssh ist nämlich kaum nutzbar, wenn der fehler auftritt.


    ssh ging noch. Habe jetzt nicht gemerkt, dass hier IO der ähnliches gefressen hat.
    Allerdings hatte ich da auch schon wieder Empfang.


    Noch ne andere Sache, wie siehts eigentlich mit support für linux-media aus? Die Treiber bauen ja leider nur bis Kernel 38.


    Das ist leider der Trouble mit den gefrickelten Treibersätzen. Man weiss halt nicht was da verändert wurde und daher kann man nicht so ohne weiteres einen Patch erzeugen.
    Irgendwo in diesem Threat wurde das noch mal genauer diskutiert.


    Gruß
    Thomas

    Hi nc17,


    die Tests habe ich auch schon hinter mir,
    was willst Du erreichen? Eine andere FB anlernen?


    irrecord hat bei mir besser gearbeitet, wenn ich eine existierende conf mitgegeben habe, irrecord lernt daraus Voreinstellungen.


    Allerdings hatte ich mit dem neulernen der Terratec und auch mit dem lernen von anderen FBs kein Erfolg.
    DIe Tasten wurden mit 0x00 protokolliert.


    Auch einfach eine andere an einem HomeBrew-Serial Adapter funktionierende Lircd.conf hat nicht funktioniert, obwohl der USB-Receiver per LED einen Empfang anzeigt.


    Gruß
    Thomas

    Der fake S4 hat einen normalen S4 gemacht und beim Starten wurde das resume image ignoriert, es hat also kein geordneter Shutdown stattgefunden. Dies bedeutet das die Platten nicht sauber ausgehängt wurden was dann verschiedentliche Probleme nach sich zog welche fnu angesprochen hat.


    Ich könnte mir auch vorstellen einen angepassten PowerOff-Kernel zu nutzen, dann sind die Änderungen im Produktiven-Teil gering und den PowerOff-Kernel "unsauber" zu beenden sollte nicht so schlimm sein, da es ja eine RAM DIsk ist.


    Gruß
    Thomas

    Hallo!


    Vielen Dank für die vielen und sehr ausführlichen Antworten! Das gibt insbesondere seahawk!
    Jetzt verstehe ich schon viel mehr und die lircd2uinput Lösung gefällt mir immer besser.


    Zu mal ja auf dem lircd-Socket schon entprellte Events ankommen, sollte da ja nicht mehr viel schief gehen.


    Danke
    Thomas


    P.S: ich werde von meinem Erfolg berichten

    Hi,


    ich hatte heute bei dem Unwetter folgende Fehler kontinuierlich im Log, auch als das Unwetter vorbei war.



    Wärend des Unwetters war das Satteliten-Signal zwischen durch weg. Auch der DVB-S2 Tuner in meinem Fernseher wollte nichts mehr anzeigen.
    Nur nach dem Unwetter funktionierte der Fernseher wieder, allerdings hatte sich der VDR mit obigem Fehler verabschiedet.
    ein

    Code
    reload dvb-driver


    hat geholfen.


    Gruß
    Thomas

    Wieso falsche lircd-config?

    Weil die VDR konfiguriert ist, dass es lirc benutzen soll. Ich weiss nicht, ob das ein Überbleibsel ist, weil ich mal lirc über das WFE konfiguriert habe:


    Aus dem Syslog:
    Jan 3 17:23:50 poempel vdr: [2414] ERROR: lircd connection broken, trying to reconnect every 3.0 seconds


    der VDR Prozess
    vdr 1160 1 9 17:24 ? 00:00:19 /usr/bin/vdr --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction [...]


    Wenn es ein Überbleibsel ist. Wie werde ich es wieder los? Habe schon die Templates durchgesehen, bin aber nicht fündig geworden.


    Wenn du nur lircd nutzen willst, dann muss der VDR aber auf den Start von lircd warten.

    Ahh O.K. das habe ich mittlerweile auch verstanden. Aber ich schätze ich habe da gerade eh ein Problem, dass VDR auf den Lircd wartet. s.o.


    Meine Lösung ist für die nächste Version von yaVDR schon größtenteils in den Quellen und funktioniert bei mir und den anderen im yaVDR-Team, die noch lircd-Empfänger verwenden soweit ich gehört habe gut...

    O.K. das hört sich doch auch gut an! Ein paar Verständnisfragen habe ich trotzdem noch s.u.

    Zitat von »poggenpower«




    Man macht den eventlircd heile, dass er mit den Events klar kommt.

    Warum sollte man eventlircd fixen, wenn es nicht kaputt ist (aber wenn du da was basteln willst hält dich keiner davon ab :unsch )?

    Nee, will ja eben nicht basteln. Nach ein wenig nachdenken, liegt das unterschiedliche Verhalten ja im LIRCD.
    Was ich noch nicht verstehe sind zwei Dinge:


    1. Unterschiedliche Events
    Warum schickt der lircd unterschiedliche (Anzahl) an Events an die unterschiedlichen sockets

    • /var/run/lirc/lircd-usb~hiddev0: alles im grünen Bereich
    • /dev/input/event<X> : Events in drei unterschiedliche Varianten und die in unkontrollierter Dopplung.

    Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.
    Oder kann man dem lircd bei der Option -uinput beibringen die Events so zu schicken wie auf dem Standardsocket.
    Ich will nicht die Arbeit an dem phython-wrapper schlecht machen, es geht mir drum, dass was an einer stelle schon richtig ist nicht an einer anderen Stelle noch mal zu korrigieren.


    2. Drei Varianten
    Laut den Traces, die ich gepostet, habe funktioniert der Eventlirc IMHO richtig, es gibt keine Dopplung der einzelnen Events mehr gibt. Nur scheint es drei Typen (Nummeriert 1,2,3) zu geben, die der Lircd ins Userland schickt. Hat jemand einen Tipp, warum es die drei unterschiedlichen Events gibt?
    Würde der python-warpper das auch kompensieren oder auf welchen der drei Typene reagiert er?
    Gibt es eine Beschreibung wie python-uinput funktioniert? und wo es sich die Events herholt und ausgibt.


    Gruß
    Thomas

    Ich vermute mal, da schlägt ein Bug zu, wenn lircd mit --uinput aufgerufen wird dann gibt es Tastenpreller am erzeugten Event-Gerät.
    Siehe [0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe und für USB-Empfänger zusätzlich noch [0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe



    Wenn ich nc17 richtig verstanden habe, hat er die Probleme mit gleichem FB und Empfänger eben nicht.
    Daher die Frage nach der Config.


    Ist es denn ein Bug im lircd? Oder ein Feature?


    Gruß
    Thomas