Beiträge von <kein>

    Notiz an mich selbst: nächstes Mal einfach nochmal 24 Stunden länger warten.


    Eigentlich habe ich nicht viel gemacht, den einzigen Fehler den ich entdeckt habe war, dass das Update die Datei /lib/udev/rc_keymaps/hauppauge_a415 überschrieben hat. Hier hatte ich in der alten Version die Kopfzeile eingefügt, die in der neuen Version aus der Paketverwaltung gefehlt hat.

    Code
    root@xi:~# head -n 4 /lib/udev/rc_keymaps/hauppauge_a415
    # table rc-rc6-mce, type: RC-5
    0x1e3b KEY_HOME
    0x1e3d KEY_POWER2
    0x1e1c KEY_TV
    Code
    root@xi:~# ll /lib/udev/rc_keymaps/hauppauge_a415*
    -rw-r--r-- 1 root root  763 Jul 24 20:48 /lib/udev/rc_keymaps/hauppauge_a415
    -rw-r--r-- 1 root root  732 Jul  9 21:32 /lib/udev/rc_keymaps/hauppauge_a415.orig

    Ansonsten hatte ich im Wesentlichen die Dateien geprüft, /var/lib/vdr/remote.conf /lib/udev/rc_keymaps/ und mit den anderen /lib/udev/rc_keymaps/*haupp* Dateien experimentiert, damit zumindest sudo ir-keytable -a /etc/rc_maps.cfg -s rc0 -v ohne Speicherzugriffsfehler durchläuft. systemctl mask --runtime --now eventlircd.{socket,service} && evtest /dev/input/event8 hat bei mir nie funktioniert und von LIRC habe ich mich nur verwirren lassen, da ich früher immer nur LIRC benutzt habe. Im Endeffekt hatte ich natürlich nie eine funktionierende Kombination der Dateien, bis zum Schluss. Es hat mich mal wieder 6 Stunden wertvoller Lebenszeit gekostet...


    Grüße,

    j.

    Hi,


    sorry für das erneute Ausgraben dieses Themas. Nachdem ich das Streamdev-Client-Plugin nachinstallieren wollte, hat das System ein Update gemacht (von 2.4.7 auf 2.4.8) und nun geht die Fernbedienung (wieder) nicht mehr. Ehrlicherweise habe ich jetzt keine Ahnung, wo ich mit der Fehlersuche anfangen soll, weil es vorher ohne Probleme lief und nun nicht mehr. Eine Auffälligkeit habe ich gefunden:

    Code
    root@xi:/etc/vdr# sudo systemctl status lircd.service
    Warning: The unit file, source configuration file or drop-ins of lircd.service >
    ● lircd.service
    Loaded: masked (Reason: Unit lircd.service is masked.)
    Drop-In: /etc/systemd/system/lircd.service.d
    └─lircd2uinput.conf
    Active: inactive (dead)

    Kann es daran liegen, dass der lircd kaputt gegangen ist?

    Bei ir-keytable -v erhalte ich einen Speicherzugriffsfehler (siehe unten) wie bereits letztes Jahr. Das System ist inzwischen vielfach neu gebootet und der Fehler geht wohl dieses Mal nicht von alleine weg. evtest erkennt auch keine Tastendrücke.


    Ich benutze weiterhin den Atric 5 mit der Hauppauge A415 Fernbedienung.


    Grüße,

    j.


    Code
    root@xi:~# cat /etc/rc_maps.cfg
    #
    # *** ANSIBLE MANAGED FILE ***
    # template: /root/yavdr-ansible/roles/yavdr-remote/templates/rc_maps.cfg.j2
    ...
    serial_ir   rc-rc6-mce          /lib/udev/rc_keymaps/hauppauge_a415
    ...

    Folgende Änderung in der /lib/udev/rules.d/99-graphlcd-base.rules hat nun zum Erfolg geführt:

    Bash
    #
    # all displays / modules supported by graphlcd-base
    #
    # Futaba DM140-GINK VFD displays, incl. activity 5xx
    ATTRS{idVendor}=="040b", ATTRS{idProduct}=="7001", GROUP="uucp", MODE="0660"
    ATTRS{idVendor}=="1509", ATTRS{idProduct}=="925d", GROUP="uucp", MODE="0660"
    # AX206DPF-based picture frames (modified firmware)
    ATTRS{idVendor}=="1908", ATTRS{idProduct}=="0102", GROUP="uucp", MODE="0660"
    Bash
    # ALPHACOOL USB DISPLAY, 240x128 Pixel
    ATTRS{idVendor}=="060c", ATTRS{idProduct}=="04eb", GROUP="uucp", MODE="0660"

    Also war es im Endeffekt ein Rechte-Problem...

    Hier mal das Log vom letzten Start: im Anhang.

    Alles was zu GraphLCD gehört sieht in meinen Augen OK aus.


    Das Display selbst hat kein Gerät unter /dev (im Gegensatz zu z. B. SeduAtmo, unter /dev/ttySEDU). Folgendes sagt dmesg:

    Code
    root@xi:/etc/udev# dmesg |grep "usb 4-2"
    [    2.454944] usb 4-2: new full-speed USB device number 3 using ohci-pci
    [    2.690056] usb 4-2: New USB device found, idVendor=060c, idProduct=04eb, bcdDevice= 0.00
    [    2.690059] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [    2.690061] usb 4-2: Product: ALPHACOOL USB DISPLAY
    [    2.690062] usb 4-2: Manufacturer: ALPHACOOL
    [    2.690064] usb 4-2: SerialNumber: 1.0.0


    Im Betrieb wird dann das Gerät nach USB 4:3 verschoben:

    OK, mit showargs kann ich sehen, dass die Änderungen eingetragen sind:

    Code
    ...
    --plugin=graphlcd -d alphacool -s touchcol
    ...


    Mit showpic (nach Installation von graphlcd-tools) kann ich auch einfach ein Logo anzeigen lassen:

    Code
    showpic -c /etc/graphlcd.conf -d alphacool /usr/share/vdr/plugins/graphlcd/logos/replay/replay-dvd_v2_l.glcd

    gehen tut es - wie gesagt - trotzdem nicht (von VDR aus)...


    kann es sein, dass das Problem an der serdisplib liegt, die ja unter Ubuntu libserdisp1 heißt?

    Wie gesagt, testserdisp und showpic arbeiten beide einwandfrei.


    Oder fehlen dem Benutzer vdr eventuell die Rechte um auf das USB-Gerät zugreifen zu dürfen (wäre trotzdem nicht logisch, da ja das TargaVFD auf Anhieb funktionierte)?

    Nachdem mir Ubuntu nun auch diese Installation geschrottet hat, musste ich nochmal neu installieren und das Theater mit der doofen Fernbedienung geht wieder von vorne los. Diesmal ist der serielle Empfänger nämlich auf rc1 gelandet und ich habe keine Ahnung wie ich den wieder zum Laufen bekomme.

    Code
    root@xi:~# ir-keytable -a /etc/rc_maps.cfg -s rc1
    Speicherzugriffsfehler (Speicherabzug geschrieben)

    ;(


    Edit: wieder geht's nach mehrmaligem Reboot, strange...

    Hi,


    nachdem in meinen VDR die Boot-Platte abgeraucht ist und ich jetzt als Übergangslösung yaVDR installiert habe, bekomme ich das GraphLCD-Plugin nicht mehr zum Laufen. Es wird folgendes USB-Gerät erkannt:

    Code
    Bus 004 Device 003: ID 060c:04eb EEH Datalink GmbH ALPHACOOL USB DISPLAY

    Zusätzlich habe ich lcd4linux installiert. Ein Test mit testserdisp funktioniert auch, d. h. es werden die Koordinaten x=240 und y=120 angezeigt.

    Code
    testserdisp -n alphacool -p 'USB:060C/04EB'

    Nun ist die Frage wie ich dem yaVDR mitteile, dass das GraphLCD-Plugin eben dieses Display zur Ausgabe verwenden soll (ist vmtl. ganz einfach, ich weiß halt nur nicht wie). Im meiner alten selbstkompillierten Installation wurde der VDR noch mit dem Pluginparamerter selbst aufgerufen:

    Code
    vdr ... -P 'graphlcd -d alphacool' ...

    wobei "alphacool" die Beschreibung in der /etc/graphlcd.conf ist.


    Grüße,

    j.

    OK, das heisst ich trage die Plugins in yavdr07.yml ein und führe dann das Playbook einmal neu aus:

    Code
    sudo -H ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="vdr_plugins"

    ?!

    So, ich weiss nicht was ich gemacht habe, aber nach mehreren Reboots geht es wie von Geisterhand...


    Kann man eigentlich andere Plugins (wie z. B. SeduAtmo) über apt installieren oder muss man da wieder in irgendwelchen Config-Dateien rumfummeln?

    Sorry für das Ausgraben des alten Threads.


    Nachdem die Boot-Platte in meinem alten VDR gestorben ist und ich auf die Schnelle einen VDR brauche, habe ich ein yaVDR Ansible aufgesetzt. Im Rechner ist ein ATRIC seriell eingebaut und als Fernbedienung habe ich eine Hauppauge A415. Allerdings taucht der ATRIC im ir-keytable gar nicht auf. Jetzt stehe ich auf dem Schlauch wie ich den wieder aktiviert bekomme. In der alten Installation lief das alles noch einwandfrei mit LIRC.

    Also auch diese Version kennt nun wieder das VideoDirectory nicht.

    Wie kann das dem Plugin mitgeteilt werden?

    @ ffmpeg.cpp:88; vermutlich fehlt am Anfang #include <sstream> , hab aber nicht nachgeschaut.

    :thumbup: ja, siehe:

    Code
    root@xi:/usr/local/src/vdr# ls -l /usr/lib/vdr/plugins/*live*
    -rwxr-xr-x 1 root root 28694760 Sep 25 21:52 /usr/lib/vdr/plugins/libvdr-live.so.2.2.0

    Die nötige Änderung war:

    Code
    #include <cxxtools/stringstream.h>

    Ob es nun läuft, wird sich nach der nächsten Aufnahme zeigen.


    Ansonsten lautet die GCC-Version:

    Code
    root@xi:/usr/local/src/vdr/PLUGINS/src/live# gcc --version
    gcc (Debian 4.7.2-5) 4.7.2
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    OK, damit kommt nun eine andere Fehlermeldung:

    Code
    *** Plugin live:
    CC tntconfig.o
    tntconfig.cpp: In member function 'void vdrlive::TntConfig::Configure(tnt::Tntnet&) const':
    tntconfig.cpp:208:3: error: incomplete type 'tnt::HttpReply' used in nested name specifier
    compilation terminated due to -Wfatal-errors.
    make[1]: *** [tntconfig.o] Fehler 1

    Mal schauen, ob man die auch nach diesem Verfahren loswird...


    Edit: mit sessionscope.h und httpreply.h läßt sich nun zumindest das tntconfig.o bauen, nun gibt es noch Fehler im FFmpeg:

    Code
    CC ffmpeg.o
    ffmpeg.cpp: In member function 'virtual void vdrlive::FFmpegThread::Action()':
    ffmpeg.cpp:88:15: error: aggregate 'std::stringstream ss' has incomplete type and cannot be defined
    compilation terminated due to -Wfatal-errors.
    make: *** [ffmpeg.o] Fehler 1

    Könnte aber hier sein, dass meine alte FFmpeg-lib nicht kompatibel ist. Da werde ich nochmal die alten Versionen (0.3.1) versuchen.

    Hallo Stefan,

    Libtnt hast du inkl dev?

    Ja, siehe:

    Außerdem habe ich für live noch die libcxxtools8 installiert. Aber es sieht in der Tat so aus als würde etwas fehlen, leider liefert Google zu der Fehlermeldung keinerlei weiterführende Hinweise (für mich).


    Grüße,

    j.

    Ansonsten ist die aktuellste Version von live hier zu finden: https://github.com/REELcoder/vdr-plugin-live

    Danke für den Tipp! Leider liefert auch diese Version den gleichen Fehler wie im Eingangspost:

    Benötigt man für live noch einen Patch im VDR? Habe dazu in der Doku nichts gesehen...


    Grüße,

    j.

    Hallo Christian,

    VDR-2.2.0 wurde Februar 2015 released. Vielleicht schaust Du lieber mal, ob Du nicht irgendwann mal auf eine aktuelle Version umsteigst.

    ich habe mit einem 1.6.0'er VDR für SD angefangen und weil ich dann unbedingt HD wollte immer die neuesten 1.7'er selbst kompiliert. Vernünftige Pakete gab es damals nicht, weil alles stets im Wandel war. Viele Plugins wurden nicht mehr gepflegt, obwohl es für diese eine breite Nutzerbasis gab, kann es aber den Entwicklern nicht verübeln, schließlich soll jeder seine freie Zeit so einteilen wie er mag. Dazu kamen dann noch ein Haufen Änderungen an der API, so dass eine weitere Reihe an Plugins rausfiel. Viele der Plugins bei mir sind im Quellcode schon von anderen Distries geklaut, weil es nicht anders gegangen ist, bspw. zeigt mein GraphTFT beim Start immer das Logo von yaVDR an, obwohl ich gar keinen yaVDR habe, was schon ziemlich nervig ist.

    Außerdem habe ich auf meinen anderen Rechner überall Devuan ASCII und auch dort ist die Version im Paketmanager 2.2.0-6. Erst mit Beowulf kommt ein 2.4'er VDR, aber soweit bin ich noch nicht, da hier wieder alle GTK2-Pakete rausfallen und ich noch viele Anwendungen benutze, die auf diesen Paketen aufbauen.

    Irgendwann hatte ich mal versucht einen 2.3'er VDR zu kompilieren, aber aufgrund der ganzen kaputten Abhängigkeiten nie zum Laufen bekommen, es sind auch meiner Meinung nach viel zu viele Patches für den VDR-Kern unterwegs, dass es vmtl. einfacher wäre was fertiges zu nehmen (z. B. EasyVDR). Das scheitert bei mir daran, dass ich eine einheitliche Umgebung mit Devuan haben möchte und der Leidensdruck nicht hoch genug ist, sprich eigentlich funktioniert mein VDR so wie er soll in der alten Version und Änderungswünsche habe ich nur ganz ganz wenige.

    Wenn Du das nur für den vdrmanager brauchst, kannst Du auch den streamdev-server nehmen. Damit lassen sich auch Aufnahmen streamen.

    Möglicherweise lässt sich das bei Dir ja leichter installieren.


    Grüße

    kamel5

    Du bist ein Genie! Habe gar nicht gesehen, dass man den streamdev auch als Zuspieler für die Aufzeichnungen auswählen kann. Damit geht jetzt das, was ich brauche. Trotzdem schade, dass wieder ein Plugin mehr kaputt ist, wie so viele andere vor ihnen...