Ich habe einen yavdr 0.4 mit obiger Beschreibung ans fliegen gebracht.
Wenn die Installation der Kernel Module nicht erfolgreich ist, gibt es sicherlich eine Fehlermeldung - die wäre schon mal hilfreich.
Gruß
Thomas
Ich habe einen yavdr 0.4 mit obiger Beschreibung ans fliegen gebracht.
Wenn die Installation der Kernel Module nicht erfolgreich ist, gibt es sicherlich eine Fehlermeldung - die wäre schon mal hilfreich.
Gruß
Thomas
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.
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:
Gruß
Thomas
Du hast "=" vergessen.
Gerald
habe beide Varianten versucht. --help und man haben da unterschiedliche Syntax.
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
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:
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
Jupp funktioniert alles wie es soll.
Leider wiederholt die FB bei einer gedrückten Taste über den Lirc-Socket die Events nicht, so dass gar kein automatisches Scrollen möglich ist.
Aber das ist jetzt wirklich eine Eigenart des samsung-Treibers.
Danke noch mal!
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
Reicht Dir ja oder brauchst Du einen Lebenslauf
Seit 2000 setzte ich privat nur Linux ein (Debian/Ubuntu), seit 2002 habe ich einen VDR.
Auch beruflich ist mir das ganze nicht fremd.
Bin allerdings kein Kernel-Developer, daher meine Frage wo es harkt, dann kann ich auch sagen, wo ich mit anpacken kann.
Viele Grüße
Thomas
Die Grundlagen
Es folgen noch Details zu:
- Inputgeräten
- rc-core
- automatisch erkennbare Lirc Geräte
- nicht automatisch erkennbare Lirc Geräte
Das dann aber in jeweils seperaten Posts.
Gibt es irgendwo diese Posts oder sind sie in der Diskussion verloren gegangen?
Vielleicht kann man sie hier verlinken.
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
Hallo
vielen Dank für den Status.
Ich habe einen Shuttle Barebone, der einen Wakeup nur aus S4 aber nicht aus S5 macht, daher wäre interessant, was für Probleme das waren.
Würde auch gerne bei der Fehlerbehebung unterstützen.
Gruß
Thomas
Hi,
ich hatte heute bei dem Unwetter folgende Fehler kontinuierlich im Log, auch als das Unwetter vorbei war.
Jan 4 00:29:40 poempel kernel: [24032.900205] dw2102: i2c transfer failed.
Jan 4 00:29:42 poempel kernel: [24034.900072] dvb-usb: bulk message failed: -110 (1/0)
Jan 4 00:29:42 poempel kernel: [24034.900083] dw2102: i2c transfer failed.
Jan 4 00:29:44 poempel kernel: [24036.900196] dvb-usb: bulk message failed: -110 (5/0)
Jan 4 00:29:44 poempel kernel: [24036.900206] dw2102: i2c transfer failed.
Jan 4 00:29:46 poempel kernel: [24038.900195] dvb-usb: bulk message failed: -110 (1/0)
Jan 4 00:29:46 poempel kernel: [24038.900206] dw2102: i2c transfer failed.
Jan 4 00:29:47 poempel vdr: [2821] ERROR: video data stream broken
Jan 4 00:29:47 poempel vdr: [2821] initiating emergency exit
Jan 4 00:29:48 poempel kernel: [24040.900196] dvb-usb: bulk message failed: -110 (5/0)
Jan 4 00:29:48 poempel kernel: [24040.900206] dw2102: i2c transfer failed.
Jan 4 00:29:50 poempel kernel: [24042.900197] dvb-usb: bulk message failed: -110 (1/0)
Jan 4 00:29:50 poempel kernel: [24042.900208] dw2102: i2c transfer failed.
Jan 4 00:29:52 poempel kernel: [24044.900198] dvb-usb: bulk message failed: -110 (5/0)
Jan 4 00:29:52 poempel kernel: [24044.900208] dw2102: i2c transfer failed.
Alles anzeigen
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
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 )?
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
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
Oh sorry, warum habe ich die nicht gesehen.
Danke, habe die gleichen Einstellungen.
Die gleiche Frage stelle ich mir auch gerade. Vielleicht hat vom yaVDR Team ja eine Idee!
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
Du hast aber im Webfrontend nichts aktiviert, oder?
Nö, hatte ich erst. Aber das passiert ja alles per UDEV.
Postest Du die conf noch. Im Zweifelsfall zum Vergleich.
Danke
Thomas
Ja, habe schon ganze Abende geschaut und auch komplette HD Aufzeichnungen gemacht.
Habe allerdings nur eine Karte in der Kiste.