Posts by Negge

    Hallo,


    die Fernbedieung ist eine RC-5, die Standard Hauppaupe von den FullFeatured damals (die silberne). Hab aber auch andere FBs gestestet (die sonst an ihren Geräten funktionieren). Da blinkt nix und weder bei cat "/dev/hidraw0" noch bei "irw /var/run/lirc/irmplircd" wird bei Fernbedienungdrücken irgenwas angezeigt.


    Wie kann ich denn checken ob was an dem IR-Teil kaputt ist? Oder ist die Firmware nicht richtig darauf geflasht?!? Oder hab ich was falsh angeschlossen. +;GND;n.c.;IR der oberen Pinleiste wenn man von hinten darauf guckt ist doch richtig, oder?!?

    Besten Dank für schonmal für die Rückmeldungen:


    ranseyer : Also alle 3 Pakete sind installiert (hängen auch von den addon-Paket ab...)


    @seahawk:


    ich hab dann meine udev-regel wieder gelöscht. Ich hatte auch nochaml den USB-Port gewechseltl. Hängt jetzt nacgh lsusb an

    Code
    1. Bus 002 Device 002: ID 16c0:27d9 VOTI

    und es wird ein hidraw0-device erzeugt.


    Nach dem booten sagt dmesg folgendes:



    Raus-reinstecken liefert:


    dmesg:


    Ein device "/dev/hidraw" gibt es es jetzt auch. Ein cat /dev/hidraw0 (ist das eintige hidraw-device) liefert beim drücken auf Fernbedienungen aber nichts...


    Auch leuchtet an dem usbasp die rote led dauerhaft, aber nichts flackert (hatte irgenwo gelesen die grüne led solle flackern?).


    Ich hab jetzt auch 3 TSOPs getestet, den beigelegten 1756, nen 34136 und nen 173x vom avboard (nach tauschen von GND und + am Stecker, avboard hat Belegung GND;+;n.c;IR, die V2 Platine nach anleitung ja +;GNG;n.c.;IR). Was kann ich noch testen? :wand

    Hallo


    irgenwie bin ich wohl zu blöd das Teil zum laufen zu bekommen. Hab unter yavdr das yavdr-addon-irmp installiert und ir_control findet das Teil auch:


    ir_control -V:

    Code
    1. ir_control 1.0.0 (20.05.2012)
    2. IRMP: 2.2.3


    Da kein HIDRAW* erzeugt wurde, hab ich die UDEV-Rule von hier irmplircd für USB IR Remote Receiver (based on irmp)
    eingefügt:

    Code
    1. "KERNEL=="hidraw*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", RUN+="/bin/mkdir /var/run/lirc", RUN+="/usr/local/sbin/irmplircd /dev/%k", RUN+="/bin/ln -s /var/run/lirc/lircd /dev/lircd""


    HIDRAW0 wird nun auch erzeugt, aber weder cat /dev/hidraw0 zeigt nichts an. Zudem verschwindet das hidraw0 nach einiger Zeit wieder.


    lsusb zeigt das device an:


    Code
    1. Bus 003 Device 002: ID 16c0:27d9 VOTI


    bzw. lsusb -s 003:002 -v


    Das ganze ist gesteck auf nen Asus At5-ion-T Deluxe unter aktuellem yavdr (0.5a mit updates). Kann mir da jemand weiterhelfen?


    Beste Grüße

    Also mhddfs packt die Platten der Reihe nach voll. Also erst die erste, wenn voll dann die nächste etc. Normalerweise landen so die Daten einer Aufnahme immer auf der selben Platte, wenn genug Platz vorhanden ist. Funktioniert auch soweit gut (bei mir mit 4 Platten). Performance ist wohl schlechter, aber auch mit mehreren Aufnahmen parallel ist das immer noch mehr als ausreichend schnell. Einziher Haken. Wenn ich eine Aufnahmen lösche, kommt es zu kurzen Bildstörungen im VDR (die dann leider auch in der Aufnahmen sind). Ursache ist mir noch nicht ganz klar, hängt aber vielleicht mit dem MHDDFS und den USB-DVB-S2 zusammen, die ich verwende? Alternativ zu MHDDFS gäbe es auch noch UnionFS oder AUFS (advanced union FS), das man wohl vergleichbar zu MHDDFS einrichten kann. Es ist allerdings komplexer und kann auch mehr als MHDDFS. Aber da es wohl kernel-module gibt, soll die performance besser sein als bei MHDDFS. Habs noch nicht getestet. MHDDFS läuft wie gesagt...

    Nur so als weitere Option. Wie wäre es denn mit einen USB2 DVB-S2 Adapter? Braucht keinen Platz im Gehäuse, kann bspw. unterm Schrank hinterm/ unterm Schrank liegen und dann hast du noch ein paar mehr Optionen was das Mainboard angeht. Und mal wenn du mal hier im "Flohmarkt" schaust -> Gebraucht ist meist günstiger als neu wenns ums Geld sparen geht.

    Aha, beim Skin Rendering bring eine aktuellere Grafikkarte nichts?!?


    Also bei mir läuft auf dem ION2 auch gar keine VDR-Instanz, sondern nur das frontend (sprich Grafikausgabe über vdr-sxfe ). Der VDR selbst läuft auf der der VDR (backend, xineliboutput) selbst läuft auf dem Server.
    Die CPU im ION2 sollte also relativ wenig zu tun haben. Wobei ich den Elchi-Skin nutze, der ja auch recht genügsam sein soll. Eine potentere Grafikkarte bringt also keinen Vorteil?

    Hi,


    die GT630 (GK208) scheint ja ne recht gute Option für nen VDR-Ausgabedevice zu sein. Ich hab hier nen At5ionT mit nem Ion2-Chipesatz, mit dem der VDR auch ganz passabel läuft. Was wären denn die Vorteile der GT630. Das Board hat nen PCI-E x4-Slot. Laufen da überhaupt GT630 Grafikkarten. Und was Nachteile,höherer Strombedarf?, oder eventl. sogar ein niedrigerer.

    Hi,


    ja ein Update war gelaufen. Hatte wohl auch den EPG-Daemon geupdated (unbedarft wie ich war). Jetzt steht der auf Hold in der vorher funktionierenden Version.


    Nach einem "epdg-dropall" sowie "epg-tool del-db", "epg-tool del-u", "epg-tool new-db" und "epg-tool del-u" scheint der epgd nach neustart nach log auch sauber zu laufen macht sauber ein EPG-Update.



    Aber der VDR will (nach dem Restart) dennoch nicht mit epgd zusammen?

    Code
    1. Mar 20 08:18:00 vdr-server vdr: EPG2VDR: Statement 'insert into vdrs set uuid = ?, inssp = ?, updsp = ?, name = ?, version = ?, dbapi = ?, lastupd = ?, nextupd = ?, state = ?, master = ?, ip = ?;' with (11) in parameters and (0) out bindings prepared
    2. Mar 20 08:18:00 vdr-server vdr: EPG2VDR: Statement 'update vdrs set updsp = ?, name = ?, version = ?, dbapi = ?, lastupd = ?, nextupd = ?, state = ?, master = ?, ip = ? where uuid = ?;' with (10) in parameters and (0) out bindings prepared
    3. Mar 20 08:18:00 vdr-server vdr: EPG2VDR: Found dbapi 3, expected 4, please alter the tables first! Aborting now.


    Nix EPG :wand ... ?!?

    Hi,
    der EPGD lief bei mir seit einigen Tagen. Heute gabs kein EPG mehr und das Syslog sagte, "Found dbapi 3, expected 4, please alter the tables first! Aborting now.". Ich hab darauhin " /usr/share/vdr-epg-daemon/mysql/alter/alter.sql" aufgerufen und erhalte folgende Fehlermeldung: "ERROR 1060 (42S21) at line 1: Duplicate column name 'imagecount'" . Was läuft da schief und wie ist das zu reparieren ?!?


    Besten Dank

    7490 ist auch gefixxt. Ich hatte auf irgendeinem aktuelleren Pressebericht gelesen, dass wohl auf auf der SSL-Seite der Fritzbox tatsächlich die Usernamen auslesbar waren und dann in einem weiteren Schritt über eine Sichheitslücke der Zugirff auf die Box möglich wurde mit einem Admin-User möglich war. Fernwartung bleibt bei mir nun erstmal aus...

    Was ich noch vergessen hatte, irw /var/run/lirc/lircd-lirc0 hatte ich vorher schon gestetsg,. Es lliefert etwas ausgiebigere infiormationen als nur irw, z.B. wird die Lircd.conf-Bezeichnung der gedrückten Fernbedienungstaste mit augebeben:


    bspw bei der Taste OK der Hauppaue FB bei der Taste OK:

    Code
    1. 00000000000017a5 00 KEY_OK Hauppauge_A415-HPG

    und bei der ensprechenden Technotrend-Fenbedienung (wenn in der lircd konfiguriert) auch dort die entsprechende Bezeichnung.
    Im moment ist die Technotrend-Fernbedienung in der Lircd.conf deaktiviert (siehe vorheriger Post), und auch "irw /var/run/lirc/lircd-lirc" gibt bei Tastendrücken auf der Technotrend-Fernbedienung nichts aus (der VDR reagiert aber), bei der Hauppauge Fernbedienung dagegen alles wie erwartet.

    HI,


    so ich habe die Technotrend Ferbnedienung in der lircd.conf jetzt komplett auskommentiert. D.h. für LIRC ist die nicht mehr konfigueriert. irw (ohne angabe eines Sockets) gibt auch nichts mehr aus, wenn ich auch der schwarzen technotrend-Fernbedienung einen Knopf drücke, ABER der VDR reagiert immer noch auf die Fernbedienung, allerdings nicht mehr mit doppeleter ausführung der Befehle. Ziehe ich den Igor-USB-Stecker raus dann, reagiert der VDR nicht mehr auf die Fernbedienungen. Um das ganze also nochmal Zusammenzufassen:


    Beobachtung:
    1) ohne eingestecken IgorUSB funktioniert keine Fernbedienung
    2) die silberne Hauppauge Fernbedienung funktioniert über die Lircd.conf und den IgorUSB wie erwartet, nachdem --lirc=/var/run/lirc/lircd zum vdr-sxfe-Aufruf hinzugefügt wurde
    3a) die schwarze Technotrend-Fernbedienung funktioniert auch noch, wenn diese in der lircd.conf garnicht konfiguriert ist
    3b) die schwarze Technotrend-Fernbedienung funktioniert auch, wenn vdr-sxfe ohne den parameter --lirc=/var/run/lirc/lircd gestartet wird.
    4) ist die schwarze Technotrend-Fernbedieung in der lircd.conf konfiguriert und vdr-sxfe wird mit dem parameter --lirc=/var/run/lirc/lircd gestartet, werden die Tastendrücke der schwarzen Fernbedienung vom sowohl von Lirc wie in der lird.conf als auch als von der auswertung nach 3) detektiert, was zu doppelten Tastendrücken bei einfachen aufruf fürht.
    5) Das Verhalten von 4) kann per vdr-sxfe aufgerufenen remote-vdr auf dem server als auch beim xmbc lokal auf dem client beobachtet werden.


    Daraus lässt sich IMHO folgendes ableiten:
    A) Nach der Beobachtung 5) handelt es sich um ein lokales Problem des clients.
    B) Nach 1) werde die IR-Signale vom Igor-USB-ausgewertet
    C) Nach 2) und 4) funktioniert zumindest die konfiguration von lircd.conf korrekt.
    D) Die Signale der schwarze Fenbedienung über den IgorUSB werden offenbar noch an der lircd.conf vorbei an anderer Stelle im System augewertet und an die Programme vdr-sxfe und xmbc übermittelt. Beim vdr-sxfe offenbar so, dass auch der Parameter --lirc=/var/run/lirc/lircd nicht nötig ist.


    Die Frage ist jetzt, wo passiert D), wie kann ich dies einstellen oder ausstellen (damit ich das dann über lircd.conf konfigureiren kann)? Irgenwo muss das ja konfiguriert sein. AHHRRRRGS Irgendwie muss man dem doch auf die Schliche kommen...

    lircd.conf:


    Ich sehe da aber auch keine Ursache?!?

    Was ich noch übersehen hatte. cat /proc/bus/input/devices liefert folgendes, wobei ich da jetzt nichts sehe was probleme machen könnte...


    Ich hab gerade mal xbmc auf dem client gestartet, vergleichbare Problematik. Bei der Technotrend Fernbedienung werden alle tastendrücke doppelt interpretiert, bei der Hauppauge nicht.


    irw


    "ps aux | grep lirc" liefert:

    Code
    1. root 667 0.3 0.0 0 0 ? S 22:10 0:12 [lirc_dev]
    2. root 854 0.0 0.0 35028 816 ? Ss 22:10 0:01 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --output=/var/run/lir /lircd-lirc0 --pidfile=/var/run/lirc/lircd-lirc0.pid /etc/lirc/lircd.conf
    3. root 860 0.0 0.4 69184 9412 ? S 22:10 0:01 /usr/bin/python /usr/bin/lircd2uinput --lircd-socket=/var/run/lirc/lircd-lirc0
    4. root 1130 0.0 0.0 10692 876 ? S<s 22:10 0:00 /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd
    5. root 1131 0.0 0.0 6368 572 ? Ss 22:10 0:00 /usr/bin/irexec /etc/lirc/lircrc
    6. vdr 4718 15.2 2.3 942880 47548 ? S<Lsl 23:11 0:19 /usr/bin/vdr-sxfe --post tvtime:method=use_vo_driver --buffers=300 --reconnect --audio=alsa --syslog --silent --tcp --lirc=/var/run/lirc/lircd --nokbd --config /etc/vdr-sxfe/config_xineliboutput xvdr://192.168.1.30:37890
    7. root 5025 0.0 0.0 10896 936 pts/9 S+ 23:13 0:00 grep --color=auto lirc

    Ist RC5.


    Wenn es daran liegen würde, dann dürfte der VDR ja nicht mit unterschiedlichen Effekten auf diesselbe Taste reagieren (siehe Taste mit der Beschriftung Text, wo am am VDR erkennen kann, dass er mal erst das VDR-Menu und dann den Videitext öffnet. Mal nur der Videotext kurz aufpop (so als hätte man erst die Videitext-Taste und dann die die Menutaste drückt) oder wenn man die Taste mal etwas länger (ca. 1s) festält das Munter zwischen dem VDR-Menu und dem Videotext-Signal hin und her flackert und auch mal das Vdr-Menu am ende offen bleibt. Also das IR-Signal derselben Taste wird also 2mal unterschiedlich bewertet, wobei es in der Lircd.conf (als auch nach IRW) immer dem Befehl KEY_MENU zugeordnet ist. Wird also definitiv 2mal interpretiert, als gäbe es irgenwo noch eine 2te Lirc-Instanz, die IRW nicht sieht, mit unterschiedlicher lirc-config?!?


    Ich hab jetzt auch nochmal testweise das lirc 0.9.0-16 aus das aus dem testing yavdr geupdatet, kein Unterschied...

    Die Tastendrücke werden offen nicht über das Kbd übertragen, da mit der Effekt auch noch bei der Option "--nokbd" im vdr-sxfe auftauchen.


    und dann hab ich nochmal das den IgorUSB (bei laufendem vdr-frontend) rausgezogen und wieder eingesteckt


    Ergebnis

    Code
    1. Aug 14 20:38:05 q150 kernel: [ 3292.600079] usb 3-1: USB disconnect, device number 2
    2. Aug 14 20:38:05 q150 kernel: [ 3292.603168] lirc_igorplugusb[2]: GET_INFRACODE: error -71
    3. Aug 14 20:38:05 q150 kernel: [ 3292.603213] lirc_igorplugusb 3-1:1.0: lirc_igorplugusb[2]: igorplugusb_remote_disconnect done
    4. Aug 14 20:38:05 q150 udevd[5254]: failed to execute '/etc/init.d/lirc' '/etc/init.d/lirc stop udev': No such file or directory
    5. Aug 14 20:38:08 q150 kernel: [ 3295.052058] usb 3-1: new low-speed USB device number 3 using uhci_hcd
    6. Aug 14 20:38:08 q150 kernel: [ 3295.235575] lirc_igorplugusb 3-1:1.0: lirc_dev: driver lirc_igorplugusb registered at minor = 0
    7. Aug 14 20:38:08 q150 mtp-probe: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1"
    8. Aug 14 20:38:08 q150 kernel: [ 3295.257118] lirc_igorplugusb[3]: Ing. Igor Cesko, Copyright(c) 2003 IgorPlug-USB (AVR) on usb3:3
    9. Aug 14 20:38:08 q150 mtp-probe: bus: 3, device: 3 was not an MTP device
    10. Aug 14 20:38:08 q150 udevd[5257]: failed to execute '/etc/init.d/lirc' '/etc/init.d/lirc restart udev': No such file or directory


    Verhalten ist so wie zuvor (die Fehlermeldung /etc/init.d/lirc restart ist vermutlich noch ein überbleibsel aus init.d-zeiten, oder?)