Posts by Grillbert

    Aus den Quelltext wird das Paket vdr-plugin-softhdvaapi gebaut und das hat vor ein paar Monaten hat es auf meinem Haswell-System funktioniert...


    Man muss auf jeden Fall noch in der /etc/X11/xorg.conf.d/20-intel.conf in der ersten Section "Device" eine Zeile Option "DRI" "3" einfügen, und https://raw.githubusercontent.…-softhdcuvid/master/drirc als /var/lib/vdr/.drirc hinterlegen, damit das Plugin funktionieren kann (die zusätzlich in softhdcuvid jetzt mit VAAPI support von mir beschriebene Anpassung für das yavdr-frontend sollte nicht mehr nötig sein).


    Falls es da noch irgendwo hakt, würden mich interessieren, was das Plugin da so in den Logdateien von sich gibt.

    Bisher lief mein System gut auch mit dem ganz normalen softhddevice auf intel.
    Wenn ich die von Dir beschriebenen Vorraussetzungen erfülle und vdr-plugin-softhdvaapi installieren will bekomme ich ein


    Code
    1. Die folgenden Pakete haben unerfüllte Abhängigkeiten:
    2. vdr-plugin-softhdvaapi : Hängt ab von: vdr-abi-2.4.1-0yavdr ist aber nicht installierbar
    3. E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.


    Wie kann ich den Konflikt auflösen?

    Hier mal mein Versuch Video Transcoding mit GPU unterstützung zu nutzen:
    Ich habe zum Testen die Handy Variante von UWE67 genommen:


    Code
    1. /home/myhome/ffmpeg/ffmpeg-4.2.1-amd64-static/ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i <input> -map 0:v -map 0:a:0 -vf 'deinterlace_vaapi=rate=field:auto=1,scale_vaapi=w=640:h=360' -c:v h264_vaapi -preset slow -qmin 18 -qmax 30 -g 25 -r 25 -c:a aac -ac 2 -b:v 0.3M -maxrate 0.3M -bufsize 0.3M


    Ich verwende dasselbe Mainboard (J4105M von Asrock) allerdings läuft der VDR bei mir nicht Headless.
    Einen Test mit Frontend detached habe ich aber auch schon probiert - klappt auch nicht. Im Log landet folgendes (Nach einem Umschaltvorgang):



    Problem ist anscheinend, dass ffmpeg in der statischen variante die weiter oben angegeben war ohne vaapi Unterstützung gebaut wurde.
    Das kann man herausfinden mit:

    Code
    1. ffmpeg -buildconf


    Mir fehlt hier die Zeile:

    Code
    1. --enable-vaapi

    Auch diese beiden Version führen bei meinem Ubuntu (yavdr ansible) nicht zum gewünschten Ergebnis...


    https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-4

    https://snapcraft.io/ffmpeg


    Kennt jemand eine geeignete Quelle für ein Binary?

    Wenn man FFMPEG auch ab bestimmten Positionen Transkodieren lassen kann, dann würde ich einfach das bereits transkodierte bei jedem Sprung oder Pause verwerfen (und löschen). Wenn das zuverlässig klappt ist das ja schon mal super.

    Schön wäre wenn auch in einer laufenden Aufnahme die Wiedergabe durchläuft. (ich glaube KODI kann das inzwischen auch - könnte aber Tricky sein weil man FFMPEG beim start ja sicher alle Dateien die wiedergegeben werden sollen übergeben muss...)


    Wie der Player (mit EPD darunter) bei mir in Chrome aussieht habe ich angehängt.

    Leider klappt Transcoding auf meinem Intel System noch nicht so richtig. Das poste ich später mal separat.

    Noch eine kurze Frage: Ist das Login von live eigentlich einigermaßen sicher?
    Also wäre es kritisch einfach per Port-Forwarding Port 8008 auf den VDR weiterzuleiten?

    Gruß,
    Grillbert

    Gibt es denn auch Bestrebungen das Webstreaming auch für Aufnahmen zu ermöglichen ?

    Weiter oben wurde das auf jeden Fall erwähnt - ich hoffe dass das noch implementiert wird....
    Habe auch gestern das Plugin auf meinem YaVDR Ansible installiert und es läuft auf Anhieb schon mal sehr gut!

    Mit FFMPEG (habe mir auch eine aktuelle Version geladen) werde ich dann demnächst mal experimentieren um zu schauen wie gut GPU Transcoding auf meinem Intel Board läuft.

    Super Projekt auf jeden Fall - Vielen Dank!!

    Damit der VDR ein Plugin lädt, muss es eine passende Konfigurationsdatei in /etc/vdr/conf.d/ geben - vgl. https://www.yavdr.org/document…mentation.html#org35d6058

    Danke!
    Dazu musste ich noch das Binary umbenennen und beachten dass live standardmäßig einen anderen Ordner für Ressourcen verwendet, aber dann lief es.
    Zusätzlich braucht man noch ein aktuelles Binary von FFMPEG (muss nicht zwingend installiert sein).

    Ist einen Blick wert - interessantes Projekt!

    Ich hoffe mit dem aktuellen FFMPEG und GPU-Transcoding endlich ordentlich von "außen" auf meinen VDR zugreifen zu können...
    Bisher war mein Fritz-VPN immer einen tacken zu langsam für HD.

    Hallo,
    wie installiere ich bei yavdr ansible ein selbstgebautes Plugin??
    Ich wollte gerne dieses weiterentwickelte live plugin testen:

    vdr-live-plugin HTML5 Web-Streaming

    Nach dem Bau habe ich ...

    Code
    1. cp libvdr-live.so /usr/lib/vdr/plugins/
    2. cp -a live . /var/lib/vdr/plugins


    ... gemacht und den vdr neu gestartet.

    Mein Plugin Verzeichnis sieht jetzt so aus:


    Code
    1. root@vdr:/usr/lib/vdr/plugins# ls
    2. libvdr-dbus2vdr.so.2.4.0 libvdr-dvbapi.so.2.4.0 libvdr-live.so libvdr-osd2web.so.2.4.0 libvdr-softhddevice.so.2.4.0 skindesigner
    3. libvdr-desktop.so.2.4.0 libvdr-epg2vdr.so.2.4.0 libvdr-markad.so.2.4.0 libvdr-pulsecontrol.so.2.4.0 libvdr-tvguideng.so.2.4.0
    4. libvdr-devstatus.so.2.4.0 libvdr-femon.so.2.4.0 libvdr-menuorg.so.2.4.0 libvdr-skindesigner.so.2.4.0 libvdr-vnsiserver.so.2.4.0

    Hallo Ralf,
    hast Du das Problem noch lösen können?

    Das sich die durch Suchtimer generierten Timer doppeln kenne ich gut - und das war auch schon bei verschiedenen Installationen (Distributionen) bei mir zu beobachten... Ich vermute dass da ein Bug in den beteiligten Plugins ist.

    Sollte es ein Konfigurationsproblem sein bin ich brennend interessiert woran es liegt!

    Gruß,
    Gilbert

    Hallo zusammen,
    ich verfolge hier die Entwicklung und frage mich ob es irgendwelche qualitativen Vorteile bietet (außer UHD) die Ausgabe von Yavdr Ansible (Standardinstallation) auf meinem Gemini Lake Intel System auf das Ausgabeplugin aus diesem Thread umzustellen...
    Vor allem: Sind die letzten Versionen alltagstauglich?

    Man sagt zwar "Never Change a Running System", aber nachdem mein neuer Verstärker jetzt wie mein TV UHD-tauglich ist, juckt es schon ein bisschen wieder zu basteln...

    Ich hatte mal den Gedanken das STM32 basierte Projekt von JRIE (eigentlich ein IR Empfänger) um ein kleines OLED zu ergänzen.
    Das könnte man ohne zusätzliche Power an USB betreiben und sogar Informationen als Reaktion auf IR Befehle
    (nächster Timer, geplante Startzeit) anzeigen, ohne den VDR hochfahren zu müssen... Das fand ich ganz charmant weil ich doch ab und an wissen möchte ob das Abendprogramm programmiert ist oder nicht.

    Liegt alles zu Hause - es fehlt nur die Zeit ;)
    (und davon bräuchte ich viel weil ich jetzt nicht der Profi-Bastler bin und mir vieles erarbeiten müsste)

    Klicke in die debug messages , kopiere alles und füge es in einen Editor ein und poste das bitte.

    Zusätzlich poste bitte auch das Ergebnis von "get eeprom", "save file".


    Soweit ich es jetzt beurteilen kann habe liegt der Fehler bei mir ...
    Die map die ich oben gepostet habe war nicht identisch zu dem was ich ausgelesen habe.
    Hier waren Codes mehrfach vergeben und es wurde der 1. Eintrag genommen - "Works as Designed".

    Besten Dank für die schnelle Unterstützung!

    • Bei gestopptem eventlircd (systemctl stop eventlircd.{socket,service}) mit evtest (sudo evtest) nachsehen, welche Tasten vom Empfänger kommen, wenn du die rote Taste auf der Fernbedienung drückst.
    • Mit der von evtest angezeigten Nummer des Input Device kannst du dann seine Udev-Attribute abfragen:
    Code
    1. Event: time 1565624314.088079, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7004d
    2. Event: time 1565624314.088079, type 1 (EV_KEY), code 107 (KEY_END), value 1
    3. Event: time 1565624314.088079, -------------- SYN_REPORT ------------
    4. Event: time 1565624314.096039, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7004d
    5. Event: time 1565624314.096039, type 1 (EV_KEY), code 107 (KEY_END), value 0
    6. Event: time 1565624314.096039, -------------- SYN_REPORT ------------


    Das ist schon mal ein anderer Key als ich ihn definiert habe.
    Für die grüne Taste funktioniert es interessanterweise korrekt...


    In der Ausgabe von



    Code
    1. Event: time 1565624315.456035, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0
    2. Event: time 1565624315.456035, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
    3. Event: time 1565624315.456035, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70008
    4. Event: time 1565624315.456035, type 1 (EV_KEY), code 18 (KEY_E), value 1
    5. Event: time 1565624315.456035, -------------- SYN_REPORT ------------
    6. Event: time 1565624315.464029, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0
    7. Event: time 1565624315.464029, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0
    8. Event: time 1565624315.464029, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70008
    9. Event: time 1565624315.464029, type 1 (EV_KEY), code 18 (KEY_E), value 0
    10. Event: time 1565624315.464029, -------------- SYN_REPORT ------------


    Ich vermute die 2 Events kommen für keypress und keyrelease ...

    In der Ausgabe von

    Code
    1. sudo udevadm info --query=all --attribute-walk --name=/dev/input/event1

    finde ich gar keinen Treffer auf "lircd":


    Hallo,
    ich werde nicht ganz schlau aus dem Keymapping...
    Zunächst habe ich für meinen YaVDR Ansible die Keymap aus dem Template mit meiner Fernbedienung (Harmony, KLS1.6) und stm32kbdIRconfig_gui (Windows) befüllt und es lief ganz OK - allerdings funktionierte die Rote Taste nicht.
    Dann ist mir eingefallen dass YaVDR ja andere Tasten verwendet (F Keys 1-4 für die Farbtasten und habe versucht ein eigenes Mapping auf den Tasten des YaVDR zu erstellen. Das hat (bis auf die Ziffern) so gar nicht geklappt... Nochmal im Thread gelesen und gemerkt dass die Tasten doch mit eventlircd events statt der normalen Tastatur-Tasten gleichzusetzen sind.
    Also auf Basis von https://www.yavdr.org/documentation/0.5/en/ch03s03.html ein weiteres eigenes Template gebaut und einfach mal probiert Keys wie "KEY_PVR" mit zu belegen. Geht nicht - die Fehlermeldung sagt dass nur Keys vom Keyboard belegt werden können (Sinngemäß).

    Dann wieder zurück zum alten Template und hoffen dass es beim ersten Anlauf nicht funktioniert hat weil sich ein Fehler eingeschlichen hat - alle Tasten nochmal angelernt - selbes Ergebnis.

    Muss ich für YaVDR ansible vielleicht irgend etwas beachten? Gibt es Ideen?

    So sieht meine MAP jetzt aus:



    Ich frage mich ja ob der "korrekt gestartete" Service dann auch funktioniert. Was passiert denn wenn der physikalische Power-Button am Board dann gedrückt wird? Hat das Board überhaupt einen?

    Das sieht zumindest korrekt aus - Yavdr meldet im Display sowas wie "Taste Drücken um Ausschalten abzubrechen"



    Quote

    Bitte mal journalctl -f laufen lassen und den Power-Button drücken. Meldet denn dein modifiziertes vdrpbd einen Tastendruck?



    Quote

    Edit: Mach mal "modprobe button". Eventuell ist dein Kernel mit "CONFIG_ACPI_BUTTON=m" gebaut und aus irgendeinem Grund wird das Modul nicht automatisch geladen.

    Das liefert schlicht gar nix!

    Die Meldung kommt laut Quellcode, wenn das Verzeichnis /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input nicht geöffnet werden kann.


    Was sagen denn ls /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input und cat /proc/bus/input/devices auf dem betroffenen System?


    Da fehlt offenbar ein directory ...

    Code
    1. root@vdr:/sys/devices/LNXSYSTM:00/LNXSYBUS:00# ls /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input
    2. ls: cannot access '/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input': No such file or directory
    3. root@vdr:/sys/devices/LNXSYSTM:00/LNXSYBUS:00# ls /sys/devices/LNXSYSTM\:00
    4. hid LNXSYBUS:00 LNXSYBUS:01 modalias path power subsystem uevent



    [edit]


    Script ein wenig angepasst ($basepath) und der service startet korrekt:

    Kennt jemand dieses Problem?



    Jul 19 14:21:55 vdr vdrpbd[796]: failed to query for input device

    Jul 19 14:21:55 vdr systemd[1]: vdrpbd.service: Main process exited, code=exited, status=1/FAILURE

    Jul 19 14:21:55 vdr systemd[1]: vdrpbd.service: Failed with result 'exit-code'.



    Hängt das evtl. zusammen, dass ich den VDR nur über Tastatur (bzw. dem irmp-auf-stm32-ein-usb-hid-keyboard von JRIE ) steuern will und daher kein LIRC bei der Installation ausgewählt habe?

    Hallo,
    hat eigentlich jemand yaVDR Ansible mit einer Intel HD600 laufen?
    Gibt es da Einschränkungen? Muss ich besondere Anpassungen in den Playbooks machen oder Treiber nachinstallieren?

    Gruß,
    Grillbert

    So - die Frage habe ich mir selber beantwortet ... erster Test ohne Schnickschnack läuft - super Bild, super Umschaltzeiten HD und SD funzt.

    Yavdr Ansible (Installiert nach upgrade und dist-upgrade) Asrock j4105M mit INTEL HD600 Grafik.

    Hallo,
    hat eigentlich jemand yaVDR Ansible mit einer Intel HD600 laufen?
    Gibt es da Einschränkungen? Muss ich besondere Anpassungen in den Playbooks machen oder Treiber nachinstallieren?

    Gruß,
    Grillbert

    Für alle die es interessiert - eine kurze Zusammenfassung der "Stolpersteine" die ich mitgenommen habe...

    - "Blue Pill"... man könnte denken (da der Fehler seit Jahren bekannt ist) dass der USB Widerstand inzwischen korrekt ist...
    -> IST ER NICHT!!

    - Maple Mini (Baite) mit Bootloader habe ich nicht dazu überreden können den über DFUUTILS geflashten Code auszuführen.
    (Mit STM32 Stick ohne Bootloader flashen hat dann geklappt)

    Die Timings sind wichtig!!
    Für meine Harmony (KLS 1.6) habe ich
    repeat delay:250
    repeat period:100
    repeat timeout:15

    eingetragen. Mit den voreingestellten Werten kommen nur sehr sporadisch Tastendrücke an.

    USB braucht natürlich Strom im ausgeschalteten Zustand...
    Bei meinem Asrock Board muss man dazu "Deep S5" auf "Auto" stellen - und die "Wake on USB" Einstellungen dazu aktivieren.
    Ich habe aber den Eindruck dass man das Board einmal ganz stromlos machen muss damit die Einstellungen auch aktiv sind.

    Den Pin durchmessen der "Power On" macht klappt natürlich nur wenn man den Maple Mini nicht über einen aktiven USB Port mit Strom versorgt. (Hatte ich in dem langen Thread überlesen...)
    Wenn mann dann (fast) klug ist und statt des PC USB Ports eine Powerbank nimmt, zieht der Maple den Pin natürlich auf die Masse der Powerbank kann man toll mit dem Multimeter messen, interessiert ein Mainboard aber herzlich wenig.
    Wenn dann alles klappt (USB hat im ausgeschalteten Zustand Strom, Power Switch korrekt verdrahtet) klappt es leider immer noch nicht, weil der Maple ein USB Wakeup sendet UND den Power Switch "drückt" ... dann ist das Board direkt wieder aus....

    Wenn ich bei meinem Board USB mit Strom versorge kann man wohl genausogut auch auf Verkabelung zum Power Switch verzichten denke ich.

    Insgesamt trotzdem ein super Projekt ... Danke nochmal an jrie!!