Posts by Paulaner

    Allerdings hatte ich es auch schon, dass sichder VDR nach einer Abfolge von Bedienvorgängen auf Tastendrücke nicht mehr reagiert hat.

    Dieses Verhalten habe ich auch ab und zu, wenn ich mehrere Befehle per Fernbedienung kurz hintereinander sende.
    Leider konnte ich bisher keine regelmäßige Ursache erkennen, aber "gefühlt" ist es oftmals nach Beendigung einer Aufnahme.

    Bin wieder daheim und kann hier wieder mitmachen.

    Meine IPTV Sender haben alle EPG, welches ich aus einer externen Quelle über das vdr-plugin-xmltv4vdr zufüge. Also am fehlenden EPG kann es nicht liegen.

    Aber heute früh ist mir was aufgefallen: Ich wollte eine gestern Abend erstellte Aufnahme löschen und da kam dann die Meldung: "Timer ist noch aktiv, trotzdem löschen?"
    Der Timer war definitiv nicht mehr aktiv, aber das ist doch auch ein Hinweis, das für den VDR der Timer noch nicht abgelaufen ist und deshalb wird er auch nicht aus der Timerliste gelöscht.

    Nachtrag:
    Die Meldung heißt: "Timer zeichnet auf, trotzdem löschen?".
    Ist mir nämlich soeben wieder passiert. ;)

    Ich habe das mit input9::capslock probiert und in /usr/share/X11/xkb/compat/ledcaps das Ausrufezeichen vor allowExplicit; entfernt.
    Sieht jetzt so aus:


    Ist allerdings auch nicht erfolgreich gewesen.
    Denn wenn ich das angepasste Script ausführe kommt keine Fehlermeldung, aber die LED blinkt auch nicht. Schade :(

    Bash
    #!/bin/sh
    
    while :
    do
        echo 1 > /sys/class/leds/input9::capslock/brightness
        sleep 1
        echo 0 > /sys/class/leds/input9::capslock/brightness
        sleep 1
    done


    Ich habe auch noch etwas recherchiert: cat /sys/class/leds/input9::capslock/trigger

    Code
    [none] usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock disk-activity disk-read disk-write mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 panic rc-feedback mmc0 bluetooth-power hci0-power rfkill0 r8169-0-100:00:link r8169-0-100:00:1Gbps r8169-0-100:00:100Mbps r8169-0-100:00:10Mbps phy0rx phy0tx phy0assoc phy0radio rfkill1

    Ich denke das disk-activity disk-read disk-write wäre genau das, was man für die Activity-LED brauchen würde.
    Aber irgendwas will noch nicht so richtig. :(

    Okay, das ist ja schonmal ein Ansatzpunkt.
    Wenn ich ein  ls -l /sys/class/leds  eingebe, dann bekomme ich folgende Ausgabe:

    Wenn ich das richtig interpretiere, dann ist:
    enp1s0 --> LEDs am Ethernetport
    input9 --> LEDs an einer Tastatur ???
    mmc0 --> USB-Ports ???
    Letzteres wäre dann also vermutlich das was man bräuchte.

    Ich habe mal ein Testscript nach Deinem Vorschlag erstellt, musste es aber etwas abwandeln, da sonst nur diese Fehlermeldungen kamen:

    Code
    root@yavdr:/home/yavdr# test-led
    /usr/local/bin/test-led: 9: cannot create /sys/class/leds/mmc0::usr/brightness: Directory nonexistent
    /usr/local/bin/test-led: 11: cannot create /sys/class/leds/mmc0::usr/brightness: Directory nonexistent
    /usr/local/bin/test-led: 9: cannot create /sys/class/leds/mmc0::usr/brightness: Directory nonexistent
    /usr/local/bin/test-led: 11: cannot create /sys/class/leds/mmc0::usr/brightness: Directory nonexistent
    /usr/local/bin/test-led: 9: cannot create /sys/class/leds/mmc0::usr/brightness: Directory nonexistent
    /usr/local/bin/test-led: 11: cannot create /sys/class/leds/mmc0::usr/brightness: Directory nonexistent


    Ich habe nochmal etwas nachgeschaut, wenn z.B. das /sys/class/leds/mmc0:: öffne, dann komme ich in ein neues Verzeichnis:

    Code
    -rw-r--r-- 1 root root 4096 Dez  3 18:07 brightness
    lrwxrwxrwx 1 root root    0 Dez  3 18:01 device -> ../../../rtsx_usb_sdmmc.1.auto
    -r--r--r-- 1 root root 4096 Dez  3 18:15 max_brightness
    drwxr-xr-x 2 root root    0 Dez  3 18:15 power
    lrwxrwxrwx 1 root root    0 Dez  3 15:17 subsystem -> ../../../../../../../../../class/leds
    -rw-r--r-- 1 root root    0 Dez  3 18:15 trigger
    -rw-r--r-- 1 root root 4096 Dez  3 18:15 uevent


    Mit diesem geänderten Script kommen keine fehlermeldungen mehr, aber es blinkt auch nichts!

    Code
    while :
    do
        echo 1 > /sys/class/leds/mmc0::/brightness
        sleep 1
        echo 0 > /sys/class/leds/mmc0::/brightness
        sleep 1
    done


    Wahrscheinlich hat mein Script nicht die richtige Syntax oder ich müsste eine andere LED nehmen o.ä.
    Ich habe es nochmals anstelle von mmc0:: mit input9::capslock  probiert, aber ebenfalls erfolglos. Keine Fehlermeldung, aber auch kein Blinken.

    Was könnte ich noch probieren? :/

    Inzwischen läuft mein VDR mit dem MiniPC "Geekom Mini Air12 mit Intel N150" schon im produktiven Einsatz und der "alte" yaVDR-PC ist nur noch als Notfall-Backup vorgesehen.

    Mal was zum Stromverbrauch:

    MiniPC "Geekom Mini Air12":
    -- Standby: --> 0,5W
    -- Nur der MiniPC ohne Peripherie: --> ca. 10W
    -- Mit 2x SSD Sandisk 4TB + USB-3.2-Hub und 2x USB-Tuner MyGica T230 + USB-3.2-Hub: --> 15W

    Der über 10 Jahre "alte" yaVDR-PC hat da im Vergleich:
    -- Standby: --> 1,8W
    -- Mit den SSDs und PCI-Tuner --> 45W

    Ist also doch schon einiges weniger Verbrauch als vorher. :)
    Vom Spaßfaktor mit der Installation und der Inbetriebnahme vom neuen MiniPC mal ganz abgesehen! :)

    Apropos Inbetriebnahme:
    Der MiniPC hat auf der linken Frontseite eine "Activity LED", die blinkt wenn auf die Festplatten zugegriffen wird.
    Allerdings blinkt bzw. funktioniert dies nur, wenn ich den MiniPC mit Windows 11 betreibe. Das Windows 11 ist original bei dem MiniPC vorinstalliert.
    Unter dem von mir für yaVDR verwendeten Ubuntu-24.04 ist diese LED auf Dauer-EIN. Das ist jetzt nur suboptimal.
    Hat jemand eine Idee, wie man diese "Activity LED" auch unter Ubuntu zum "blinken" bringen kann? :/

    Hier mal noch ein Bild von der Front des MiniPCs, da sieht man das Dauerleuchten der LED:

    Sorry, dass ich das zuerst im falschen Thread gepostet habe.
    Bin eben ein Newbie mit dem IRMP-LIRC-Zeugs! ;)

    Anfängerprobleme von einem USB-IR-Empfänger mit RP2040 Zero:

    Ich bin ja dabei meinen seit vielen Jahren genutzten Intel-i5-PC mit einer Nvidia GT1030-Grafikkarte in Rente zu schicken.
    Als Nachfolger habe ich mich für einen MiniPC Geekom Mini Air12 mit Intel-N150 als VDR entschieden, siehe dazu diesen Thread!
    Die neueren MiniPCs haben ja genügend Power, bei einer wesentlich geringeren Verlustleistung von nur ca. 10W.

    Als Distri habe ich wieder das yaVDR-ansible genommen, da ich das schon seit sehr vielen jahren nutze.
    Die Installation von yavdr-ansible auf Ubuntu-24.04.3 war fast problemlos, bis auf den aktuellsten Intel-Grafiktreiber, den ich separat nachinstallieren musste.

    Für die Fernbedienung habe ich das Angebot von Emma53 genutzt und mir einen USB-IR-Empfänger mit RP2040 Zero gekauft.
    Bei der Programmierung meiner Philips-Fernbedienung auf den RP2040 gab es Anfangs auch ein paar Probleme, aber mit Hilfe von Helmut konnte das schnell gelöst werden. Super schnelle Hilfe. :thumbup:

    Die Bedienung per Fernbedienung des yaVDRs inkl. KODI klappt nun einwandfrei und auch das WakeUP funktioniert wie gewünscht. :)

    Allerdings gibt es ein Problem mit vermutlich "eventlircd", was auf fast jeden beliebigen Tastendruck meiner Universal-FB reagiert.
    Bemerkt habe ich das bei einer Testaufnahme auf dem MiniPC:
    Aufnahme läuft -> Power drücken -> VDR fährt nicht runter, aber nach einer Weile wird das softhddevice-Plugin "detached". So soll es auch sein!
    Und das bleibt dann so, bis ich wieder eine Taste auf der Universal-FB drücke und dabei muss die Universal-FB auf dem Gerät MiniPC stehen.

    Aber jetzt passiert folgendes:
    Ich aktiviere auf meiner Universal-FB irgendein anderes Gerät, z.B. den Sony-TV oder den Denon-AVR und drücke da irgendeine Taste und sofort wird das softhddevice-Plugin auf dem MiniPC attached und Bild+Ton sind da. Es werden keine Befehle ausgeführt wie Up, Down, OK o.ä.. Nur das softhddevice-Plugin wird "attached".
    Der gleiche Test mit dem "alten" yavdr-PC zeigt dieses Verhalten nicht. Da wird das softhddevice-Plugin nur dann detached, wenn auch die Universal-FB auf den yaVDR-PC gestellt ist. Alle anderen Geräte ignoriert das "eventlircd" vollkommen.

    Jetzt meine Frage:
    Bisher habe ich nur die beim Anlernen der FB an den RP2040 erstellte "keymap" in die Datei /etc/irmplircd/irmplircd.map kopiert.
    Mehr habe ich nicht gemacht bzw. aktiviert. Der MiniPC lässt sich einwandfrei bedienen.
    Muss ich nun noch etwas anderes konfigurieren damit das eventlircd nicht mehr auf alles reagiert? :/

    vdr_rossi mit das LibreElec*VDR*Generic würde es auf jeden Fall funktionieren!
    Das "normale" LibreElec-Generic habe ich ja schon getestet, siehe hier Beitrag#8 und da funktionier HDR mit KODI einwandfrei. :)

    Ich habe nur das Problem das ich für die IPTV-Streaming-Sachen ein paar Python-Scripte/Programme am laufen habe, die ich unbedingt benötige.
    Und da weiß ich noch nicht, wie ich diese Programme/Scripte in LibtreElec rein bekomme, denn normalerweise ist da ja alles geblockt.

    Jetzt bin ich erstmal dabei, dass dies alles (auch ohne HDR-Wiedergabe) mit dem yaVDR läuft mit Fernbedienung, IR-Einschalter per Fernbedienung usw. rund läuft, damit ich den alten Stromfresser-yaVDR-PC in rente schicken kann! ;)