Posts by stschulze

    hi seahawk,


    super, danke ....da ich erstmal mit meiner installation das ganze zum laufen bekommen möchte, wäre ich dir dankbar, wenn du mir die für den betrieb mit softhddrm relevanten Config-Files hier posten könntest....möglicherweise läuft es dann ja.....


    Xorg.conf

    etc.....

    Das ist das Paket für softhdvaapi im yaVDR-PPA für focal: https://launchpad.net/~yavdr/+…shed&field.series_filter=

    Eine aktuelle libplacebo gibt es hier: https://launchpad.net/~yavdr/+…shed&field.series_filter=

    hi seahawk1986,


    vielen Dank.


    Allerdings hilft mir das nur bedingt.


    Es wäre gut für alle die das neue Plugin einsetzen wollen eine kleine Schritt-für-Schritt-Anleitung hier zu Posten. Dabei die erforderlichen Einstellungen in den conf-Dateien zu hinterlegen und die unbedingt erforderlichen Abhängigkeiten klar zu machen.


    Mit einer solchen Anleitung besteht die Möglichkeit das ganze zu implementieren und beim Testen und Verbesserungen zu helfen.


    Mir geht es da wie cinfo ..... ich bekomme mit iHD-Treiber und VAAPI nur ein schwarzes Bild mit Ton. Tuner kann ich umschalten ...


    Bin etwas ratlos, wie ich da weiterkommen soll.


    Herzliche Grüße

    Stephan

    Hallo zusammen,


    ich bin mir etwas unsicher nach den ganzen Posting bzgl. Einstellungen für das Webstreaming im live-Plugin ....Welche Einstellungen sollte ich für den Intel Nuc mit VAAPI-Unterstützung nun am Besten nehmen? Meint ihr das passt so?


    h264:

    ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i "http://192.168.0.32:3000/<input>" -map 0:v -map 0:a:0 -c:v copy -c:a aac -ac 2


    HEVC + mpeg2 + others:

    ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i "http://192.168.0.32:3000/<input>" -map 0:v -map 0:a:0 -c:v h264_vaapi -preset ultrafast -crf 23 -tune zerolatency -g 25 -r 25 -c:a aac -ac 2


    Gruß

    Stephan

    das wäre super ....


    ein Gedanke noch dazu ..... wenn noch irgendwelche anderen Devices dazu kommen würden, weil der vdrpbd noch auf anderer Hardware laufen müsste ....wäre es vielleicht sinnvoll die Devices in die conf einzutragen ....dann müsste nicht des vdrpbd-Skript angepasst werden ......

    Code
    1. root@BM2LTSR66Nuc64native:~# apt install libnet-dbus-glib-perl
    2. Paketlisten werden gelesen... Fertig
    3. Abhängigkeitsbaum wird aufgebaut.
    4. Statusinformationen werden eingelesen.... Fertig
    5. libnet-dbus-glib-perl ist schon die neueste Version (0.33.0-3build1).
    6. 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

    hatte nochmal ein reboot gemacht ....


    Bei Druck auf Powertaste der FB kommt jetzt die Meldung am VDR "Taste drücken um ausschalten abzubrechen" ...dann fährt der VDR den NUC runter. Wenn eine Aufnahme läuft kommt "VDR schaltet später aus. Power zum erzwingen...."


    alles schick an dieser Taste.


    Der Power-Taster am NUC reagiert allerdings noch nicht.

    mit neuem vdrpbd

    bei druck auf die PowerTaste der FB kommt eine Meldung des VDR am OSD bzgl. Ausschalten ...aber der NUC fährt sofort runter

    Ich würde sagen, diese drei Input-Devices sind zu beachten:


    Super wäre, wenn der vdrpbd in einem Analyselauf ein log in Datei schreibt und die Brauchbarkeit der Devices darstellt ..... oder ist das nicht machbar?

    Kann man machen, muss man aber nicht. Eigentlich war "vdrpbd" als "fire and forget"-Lösung gedacht um eben acpid nicht mehr konfigurieren zu müssen. Der sollte auf einem VDR-System dann eigentlich gar nicht mehr laufen.


    Wenn ich aber keine weiteren Infos mehr bekomme ist das Thema hier für mich durch. Selber habe ich kein CIR und VDR im Frontend nutze ich schon seit Jahren nicht mehr.


    Wie schon erwähnt: Mit Kodi geht das "einfach so". Der schaltet für die Tasten selber einen "inhibit" und behandelt die dann selber.

    mir wäre die Lösung über vdrpbd sehr recht ..... ich habe alles was ich finden konnte in den beitragen gepostet ...wir können gern zusammen versuchen das hinzubekommen.

    Lösung:


    ACPI-Events für den Intel NUC NUC8i3BEH2 benutzen


    Umsetzung unter Ubuntu 20.04:


    1. "Ausschalten der Sleep-State Targets"

    Code
    1. systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

    2. ACPI-Daemon Konfigurieren


    /etc/default/acpid

    /etc/default/acpi-support

    3. ACPI-Event's erstellen


    Event ermitteln durch Tastendruck auf jeweilige Powertaste

    Code
    1. acpi_listen


    /etc/acpi/events/nuc-powerbutton

    Code
    1. event=button/power LNXPWRBN:00 00000080
    2. action=/etc/acpi/vdrpoweroff.sh

    /etc/acpi/events/remote_powerbutton

    Code
    1. event=button/sleep SBTN 00000080 00000000 K
    2. action=/etc/acpi/vdrpoweroff_null.sh

    /etc/acpi/events/remote_powerbutton2

    Code
    1. event=button/power PBTN 00000080 00000000
    2. action=/etc/acpi/vdrpoweroff.sh

    4. ACPI-Skript's erstellen


    /etc/acpi/vdrpoweroff.sh

    Shell-Script
    1. #!/bin/sh
    2. # /etc/acpi/vdrpoweroff.sh
    3. /usr/sbin/svdrpsend.sh "HITK POWER" > /dev/null
    4. sleep 10


    /etc/acpi/vdrpoweroff_null.sh

    Shell-Script
    1. #!/bin/sh
    2. # /etc/acpi/vdrpoweroff_null.sh
    3. /usr/sbin/svdrpsend.sh "HITK POWER" > /dev/null


    4. ACPI-Daemon neu starten und Status kontrollieren

    Code
    1. systemctl restart acpid
    2. systemctl status acpid


    Fertig.

    habe auf der FB den Power-Button gedrückt und folgendes über ACPI_listen bekommen:

    Code
    1. root@BM2LTSR66Nuc64native:~# acpi_listen
    2. button/sleep SBTN 00000080 00000000 K

    dann legt sich der NUC schlafen .....erneuter Tastendruck auf Powertaste der FB:

    Code
    1. button/power PBTN 00000080 00000000

    jetzt ist die Box wieder da.....

    Code
    1. input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
    2. ACPI: Sleep Button [SLPB]
    3. input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
    4. ACPI: Power Button [PWRB]
    5. input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
    6. ACPI: Power Button [PWRF]

    evtl. hilf das hier weiter -> Input16 müsste es sein:


    ich komme der Sache näher ....


    wenn ich den Power-Button am NUC drücke reagiert der vdrpbd :

    Code
    1. May 10 15:01:58 BM2LTSR66Nuc64native vdrpbd[518]: Power key pressed. May 10 15:01:58 BM2LTSR66Nuc64native vdrpbd[518]: ConnectTCP: Connection refused at /usr/sbin/vdrpbd line 235.

    allerdings sieht es wohl so aus, dass der NUC über den eingebauten IR-Empfänger ein weiteres Device hat, welches bei Druck auf die Power Taste der FB (das läuft über LIRC) den NUC in den Schlafzustand versetzt ......

    Code
    1. root@BM2LTSR66Nuc64native:~# fuser -v /dev/input/event0
    2. BEN. PID ZUGR. BEFEHL
    3. /dev/input/event0: root 470 f.... acpid
    4. root 522 F.... systemd-logind
    5. root 962 F.... Xorg


    der vdrpbd greif auf event2 zu .....


    Code
    1. root@BM2LTSR66Nuc64native:~# fuser -v /dev/input/event2
    2. BEN. PID ZUGR. BEFEHL
    3. /dev/input/event2: root 503 F.... systemd-logind
    4. root 506 f.... vdrpbd
    5. root 507 f.... acpid
    6. root 1155 F.... Xorg

    wie sage ich dem X-Server, dass er das Device nicht einbinden soll?

    Ich habe vdrpbd auf Ubuntu 20.04 installiert:

    Code
    1. root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1# systemctl start vdrpbd.service
    2. root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1# systemctl enable vdrpbd.service
    3. Created symlink /etc/systemd/system/multi-user.target.wants/vdrpbd.service → /etc/systemd/system/vdrpbd.service.
    4. root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1#

    nach einem Neustart des NUC:

    sieht also ganz gut aus, der vdrpbd.service läuft.


    ABER:


    Bei Druck auf die Power-Taste der Fernbedienung wird der NUC dennoch in den Sleep gesetzt!