Danke seahawk1986 . Mach Dir keinen Stress. 
Mit dem softhdvaapi haperts noch irgendwie mit dem Umschalten auf tty3 und dem dortigen Starten. Warum verstehe ich gerade nicht.
Muss jetzt erst mal auf Dienstreise; nächstes WE guck ich wieder auf die Konsole.
Fernbedienung hatte ich mangels Empfänger zum Testen bisher noch nicht angefasst; das wäre der nächste Schritt gewesen.
Danke für den Tipp, der mir sicher helfen wird!
So, muss nach der langen Zeit mal einen Wasserstand vermelden, der gar nicht mal schlecht ausschaut.
Zum Kodi wechseln und zurück geht und der Bursche gibt HDR aus.
Ich habe jetzt erst mal mit dem softhddrm weitergemacht, da es mich neugierig machte. Subjektiv finde ich das Bild etwas besser als mit softhdvaapi-nocebo. Aber ob das wirklich so ist? Montag bin ich eh beim Augenarzt zwecks Untersuchung.
Eingerichtet auf einem yavdr-headless ohne yavdr-xorg und ohne yavdr-desktop. Die von mir erst angedachte tty3-Tmux (s.o.) ist gar nicht nötig.
Habe Dein kodi-on-console.service quick & dirty ergänzt um ein ExecStopPre & Post für die Umschaltung. Und löschen des ...run/user/666/pulse/, da ich mein Singal immer per Paththrough ausgebe.
[Unit]
Description=Start KODI on a local console
Conflicts=getty@tty3.service
[Service]
User=vdr
EnvironmentFile=/var/lib/vdr/.headless-env
ExecStartPre=/usr/bin/svdrpsend plug softhddrm deta
ExecStart=/usr/bin/flatpak run --device=all --command=kodi tv.kodi.Kodi --standalone --windowing=gbm
ExecStop=/bin/bash -c "[ -n \"$MAINPID\" ] || exit 0; /usr/bin/flatpak run --command=kodi-send tv.kodi.Kodi --action=QUIT; while ps -p $MAINPID -o comm=; do sleep .25; done"
ExecStopPost=/usr/bin/svdrpsend plug softhddrm atta
TimeoutStopSec=10
SuccessExitStatus=0 127 SIGKILL
Restart=on-failure
StandardInput=tty-force
StandardOutput=journal
TTYPath=/dev/tty3
TTYReset=no
TTYVHangup=yesManchmal macht das softhddrm beim ATTA Probleme, dass das Fernsehbild stottert und flackert, weil Frames gedroped werden - warum auch immer (Signal kommt aktuell per Streamdev rein.).
Lösen kann man das mit einem oder mehreren DETA/ATTA oder per vdr-Neustart.
Ich probiere den Ansatz bei Gelegenheit nochmal mit dem softhdvaapi.
Danke für Deinen Support!
Wenn ich den kodi-on-console.service aus der Konsole starte, dann springt's bei mir zurück auf X mit Mauszeiger. Der tty3-login verschindet dann auch.
Ich habe Deinen exec mal manuell auf über tmux auf tty3 gestaret (ohne --filesystem=/run/user/666/pulse/ da ich kein pulseaudio installiert habe), dann startet Kodi schon mal.
Mir ist noch aufgefallen, dass die Profildaten nicht kommen (z.B. beim Hauptschalter gibt's nur EXIT) und dass die Hardware-Decodierung nicht läuft. Beim manuellen Vorgang fehlt dann bestimmt die Weitergabe der Daten aus dem .headless-env....
CPU ist bei 4k h265 und AV1 Contentn zwischen 60-80%. Zum Vergleich aus meinem Userkonto: <20 %.
Muss der User vdr vielleicht noch in eine andere Gruppe rein?
PS Nachtrag hatte das unter dem softhdvaapi-nocebo probiert
So, Dienstreise wurde verschoben. Also kann ich wieder in die ssh-Console.
Wenn ich in /etc/vdr/conf.d/00-vdr.conf den User auf root umschalte, klappt's direkt mit dem Ton.
Seltsamerweise ist dann ein CPU-Kern permanent bei 100 % (Die Threads vdr und dbus-daemon) verursachen das. Das syslog wird auch vollgeschrieben mit (unexpected replay 2 when releasing name de.tvdr.vdr ......dbus2vdr: system: connected with unique name)
Habe dann einfach mal die dbus-confs modifiziert und als policy user=root eingestellt: de.tvdr.vdr.conf und de.yavdr.frontend.conf.
Danach lief der vdr mit niedriger Auslastung.
Jetzt kann ich das ganze auf tty1 laufen lassen und DETA. Beim ATTA kriege ich aber nur ein Flackerbild. 
Das sollte aber schon laufen, sonst macht der softhddr-Weg keinen Sinn.
NACHTRAG: Hä, komisch, jetzt klappt das deta / atta auch ohne Flackern! Nur beim ersten DETA/ATTA flackerts. Nach dem zweiten DETA/ATTA nicht mehr.
Puh, ich bin mir nicht so sicher, ob das mit dem softhddrm der richtige Weg für meine Wunschkonfiguration ist.
Danke, Stefan für den Tipp.
Ein schnelles Durchlaufen des ansible ergab schon mal ein Bild. Ton wollte irgendwie noch nicht.
Ich erinnere mich gelesen zu haben, dass der vdr als root schuften muss. Vermutlich hat es daran gelegen.
Dann gucke ich mir das mal Ende der Woche genauer an.
Kodi ist ja mittlerweile unter Linux fähig HDR auszugeben.
Eine Restriktion ist, dass man Kodi ohne Desktop starten muss.
Bei yavdr wird ja - soweit nach meinem Verständnis - Kodi auf tty7 in einer Openbox-Umgebung im Fullscreen gestartet. Wenn man ein kodi-gles (obiger Link) per Flatpak installiert hat, dann meldet der Kodi auch erwartbarerweise: "keine HDR Bildschirme erkannt".
Switche ich auf eine andere tty, logge mich ein und starte Kodi klappt das mit dem hdr10.
Nun mache ich mir gerade Gedanken, wie man das mit hohem WAF realisiert; soll ja auf dem Wohnzimmer-yavdr laufen.
Der Dokumentation und vielen Threads hier habe ich entnommen, dass beim Wechsel von Kodi folgendes passiert:
- vdr-Frontend wird detached (bei mir softhdvaapi-nocebo)
- Fernbedienung wird deaktiviert
beides quasi "mittels frontend-dbus-send stop"
- kodi.service wird gestartet aus systemd-user-Session -> Voll-Fenster in openbox
Jetzt tät ich das gerne umbiegen auf eine andere tty, zB tty3 ohne Berücksichtigung des laufenden openbox auf tty7.
Und beim Beenden von Kodi natürlich wieder der Switch zurück zum vdr (zurück auf tty7 und frontend attachen).
Ich habe schon mal etwas rumgespielt und wollte folgenden Weg gehen; wobei ich mir nicht sicher bin, ob ich mir beim Handstand von hinten durchs Auge schieße....
So super fit, wie die meisten hier bin ich beim Custom-Modding von linux-Diensten nicht.
Mein bisheriger Startpunkt:
tmux-Session als Service, der auf tty3 gestartet wird und beim Beenden zurück zu tty7 hüpft.
matthias@chickpea:~$ sudo cat /etc/systemd/system/tty3tmux.service
[Unit]
Description=Tmux session in tty3
[Service]
Type=idle
User=vdr
KillMode=process
ExecStart=/usr/bin/tmux new-session -s tty3 -A
ExecStartPost=+/usr/bin/chvt 3
ExecStop=/usr/bin/tmux kill-session -t tty3
ExecStopPost=+/usr/bin/chvt 7
TTYPath=/dev/tty3
StandardInput=tty
StandardOutput=tty
StandardError=tty
[Install]
WantedBy=multi-user.target
Ich weiß jetzt nur (noch) nicht so genau, wie ich das jetzt am elegantesten mit dem /var/lib/vdr/.config/systemd/user/kodi.service verknüpfe,
damit man obiges erreicht.
Manuell und recht dirty hatte ich mal im .bashrc eine Abfrage eingebaut, ob tty3 vorliegt und dann kodi von gestartet. Getestet über ssh. Das ging mal, aber es scheint mir kein vernünftiger Weg, den ein yavdr-Entwickler gehen würde. 
Hat da jemand eine Idee?
LG, Matthias
Nach einem upgrade von "vdr-plugin-softhdvaapi-nocebo"
funktioniert nun alles
Ich hole mal den Thread hoch, um eine Ergänzung zu machen. Hier passt es gut rein und ein neuer Thread lohnt nicht.
Im Aufbau habe ich das Schwester-Board von Asrock, das N100M (Micro ATX mit zwei PCIe 1x).
Der yavdr-ansible Installationsprozess für Ubuntu Noble 24.04 lief super durch. Und wie bei meinem J4105 setzte ich gleich auf softhddevice als Ausgabe-Plugin auf.
Dabei stellte ich nur bei den 720p Sendern ein verwaschenes Bild fest - fast wie immer deinterlaced; im Anhang der Vergleich. Seltsamerweise war die 1080i Qualität okay.
Außerdem gab es immer wieder mal ein paar Tonaussetzer (Ton über HDMI und -p hw:PCH,3 rausgeschleust).
Lösung:
Das Umstellen auf vdr-plugin-softhdvaapi-nocebo brachte sofort Abhilfe - scheint mir nun alles top zu sein.
Habe mir ein Asrock N100M zum Rumspielen geholt. So als "irgendwann"-möglichen Ersatz vom J4105, der immer noch tolle Dienste tut.
Also habe ich auch mal probiert, Kodi mit gles zu bauen. Gemäß obiger bzw. dieser Anleitung. Dauert auf dem N100 eine halbe Ewigkeit.
(https://github.com/flathub/tv.kodi.Kodi/issues/248#issuecomment-2616667994)
Im 24.04 gibt es Probleme mit dem flatpak-builder, der mit den Ubuntu-Quellen kommt. Das konnte ich nachvollziehen -> Fehler und Abbruch des Builds.
In meinem yavdr-ansible bekomme ich so meinen kodi-gles auch zum Laufen, allerdings mehr schlecht als recht.
4K mit HDR spielt er gar nicht ab. Der Bildschirm bleibt schwarz; auch AV1 komprimiertes.
Beim Kodi aus dem Flatpak-Repo spielt er zwar 4k HDR ab, aber es ruckelt vor sich hin. AV1 1080p tut hingegen.
Was unterscheidet den Build aus dem Flatpak-Repo denn noch? Ich bin was Flatpak betrifft blutigster Anfänger.
Auf einer Coreelec-Box mit S905X4 tut alles; aber ich meine, da ist Kodi noch mehr modifiziert.
Habe mal die logs angehängt. Vielleicht wird jemand daraus schlau.
Ich vermute der Casus-Knaxus liegt hier:
2025-02-18 21:16:56.078 T:7 info <general>: GLES: Selecting single pass rendering
2025-02-18 21:16:56.078 T:7 info <general>: GLES: Selecting YUV 2 RGB shader
2025-02-18 21:16:56.078 T:7 error <general>: GLES: BaseYUV2RGBGLSLShader - unsupported format 3
2025-02-18 21:16:56.138 T:7 info <general>: Skipped 1 duplicate messages..
2025-02-18 21:16:56.138 T:7 info <general>: GLES: Selecting YUV 2 RGB shader
2025-02-18 21:16:56.138 T:7 error <general>: GLES: BaseYUV2RGBGLSLShader - unsupported format 3
2025-02-18 21:16:56.187 T:25 info <general>: Skipped 1 duplicate messages..
NACHTRAG: Habe den VDPAU-Teil oben gerade gesehen. Das habe ich mit =ON mit reingeschraubt und nicht deaktiviert.NACHTRAG: War alles Unsinn. Es tut. Ich war in einer xorg-Session.
Irgendwie ist da was abhanden gekommen. 
Ich hatte auch versucht den vdr*elec auf die Box zu bekommen, bis ich diesen Thread fand.
Schade, dass es nicht geht. Finde aber summa summarum, dass es sich lohnt, sich mit den X4-boxen zu beschäftigen.
Ich mag den Thread nun nicht unnötig aufwärmen und ich verstehe auch die Argument hinsichtlich des Kernel.
Also was will ich mit den Boxen:
Audio und Video in allen Varianten mit möglichst bester Ton- und Bildqualität wiedergeben.
Und das geht eben alles mit CoreElec problemlos.
Das will ich auch.
Mit dem Odroid N2 hatte ich auch schon rumprobiert (siehe RE: [VDR*ELEC] - LibreELEC/CoreELEC mit VDR Client) und finde das VDR*ELEC klasse. Den N2 muss ich nun wegen eines anderen Projektes einer anderen Anwendung zuführen, so dass ich mich dort nicht weiter mit beschäftigen kann.
Warum nutze ich Corelec nun mit der HK1 RBOX X4 und dem Amlogic S905X4?
Eigentlich nur deswegen, weil der den AV1 hardwareseitig decodieren kann. Man sieht immer mehr Anbieter, die in AV1 streamen. Nun, ich bin kein Prophet, aber es spricht schon vieles dafür, dass da noch mehr drauf springen werden. Über Kompression und Qualität vom AV1 mag ich jetzt nicht referieren, das ist schon nochmal ein deutlicher Fortschritt zum h265. Nun, das dürften im VDR-Forum fast alle überblicken.
Hi Zabrimus ,
ein tolles Stück Software hast Du da zusammengebaut. Die Idee der Fusion von vdr und coreelec ist schon spitze! 
Habe auch gleich mal auf meinem Odroid-N2 getestet.
Ich fahre seit x-Jahren mit meinem yavdr-ansible (amd64) sehr beständig, so dass ich die ganze Konfiguriererei gar nicht mehr gewohnt war 
. Trotzdem bekam ich Bild und Ton:
Dabei aktivierte ich den streamdev-server im enabled_plugins. Konfigurieren musste ich den aber im setup.conf. Da war ich etwas verwirrt. Ich wollte erst an eine eigene streamdev-client.conf ran. Den Irrweg konnte ich aber schnell verlassen.
War es nicht so, dass der streamdev-Server (mein Ansible unter Focal) stellt neben dem DVB-Stream (Sat) auch die Aufnahmen bereitstellt. Das tut's bei mir nicht. Muss man da noch was einstellen?
Aufnahmen werden, wie angegeben, im /storage/videos abgelegt. Tut.
Auf dem Streamdev-Server wäre mir lieber; ich vermute, das geht über einen Workaround mit nfs-Mount nach /storage/videos, oder?
Meinen Ton sende ich von allen Medien-Devices per Passthrough an einen Onkyo-Receiver. Das funktioniert ganz gut. Nur einmal nach dem Ändern von ein paar Einstellungen kam kein Ton mehr, was aber durch einen Neustart behoben werden konnte.
Mir fällt allerdings auf, dass es im Receiver hin und wieder beim Umschalten in den Boxen scheppert. Das kenne ich sonst nicht.
Bei der Fernbedienung (hier nutze ich den Standard von Corelec auf einer Harmony 650) gibt's muss ich noch das Prellen wegkriegen. Der springt gerne doppelt so weit wie er soll. Das muss ich mir im VDR-Einstellungen-Sonstiges mal angucken.
Neee, ich hatte die edid.bin schon im Keller, da musst nix mehr runterfallen.
Wie Du diese besorgt hattest in Zusammenfassung-Intel-Vaapi-Edid.bin, ist mir sehr wohl aufgefallen.
Aber ist das Script von seahawk1986 nicht so firm, dass es diese gleich bereitstellt?
Bevor ich mich zurückmelden wollte, lies ich die Änderungen von meiner Frau ausgiebig testen, während ich mich auf Dienstreise begab. 
Was ich gemacht habe:
Dein Skript "Shell-Script: /etc/initramfs-tools/hooks/include-edid-data" aus dem oberen Link eingefügt.
Die /etc/default/grub erweitert um:
GRUB_CMDLINE_LINUX="video=HDMI-A-1:1920x1080@50D drm.edid_firmware=HDMI-A-1:edid/edid.bin"Und final:
sudo update-initramfs -u
sudo update-grubVielen Dank, es funktioniert einwandfrei.
Hallo,
ich tue mir etwas schwer mit einem "schönen" Thread-Titel; hab's trotzdem mal versucht.
Ich nutze seit Okt 20 yavdr 0.7 unter Focal und habe mir das ansible-Skript entsprechend eingerichtet.
Die Verwendete Hardware ist Asrock J4105M + Onkyo TX-RZ 840 + LG OLED65C7D
Nun habe ich folgendes Phänomen, bei dem ich mir nicht 100 % sicher bin, ob's am yavdr liegt:
Damit das Frontend immer startet, ist folgendes eingetragen:
Ich verwende softhddevice
/etc/yavdr-frontend/config.yml
....
vdr:
id: 0 # vdr instance id
dbus2vdr_bus: SystemBus # the bus to communicate with the dbus2vdr plugin - SystemBus or SessionBus
attach_on_startup: always # choose one of auto, always or never - original: auto
wakeup_ts_file: "/var/cache/vdr/acpiwakeup.time"
frontends: # assign output plugins to a frontend implementation
softhddrm:
module_name: yavdr_frontend.frontends.softhddrm
class_name: Softhddrm
use_pasuspend: False # suspend pulseaudio while softhddrm is active, so it has direct ALSA access
softhdcuvid:
module_name: yavdr_frontend.frontends.softhdcuvid
class_name: Softhdcuvid
use_pasuspend: False # suspend pulseaudio while softhdcuvid is active, so it has direct ALSA access
softhdvaapi:
module_name: yavdr_frontend.frontends.softhdvaapi
class_name: Softhdvaapi
use_pasuspend: False # suspend pulseaudio while softhddevice is active, so it has direct ALSA access
softhddevice:
module_name: yavdr_frontend.frontends.softhddevice
class_name: Softhddevice
use_pasuspend: False # suspend pulseaudio while softhddevice is active, so it has direct ALSA access
.....Von meinem Verständnis her müsste doch nun das Frontend starten und stets Bild+Ton am HDMI ausgegeben werden.
Habe ich was übersehen?
LG
Matthias
Ich hätte da mal eine Frage, wie das mit den Filtern, in meinem Fall Deinterlacing, läuft.
Kann es sein, dass das deinterlaced automatisch erkannt wird und der Filter yadif automatisch gesetzt wird (beim encoden)?
Im logfile sehe ich eine Erkennung:
scantype=Interlaced
deinterlace=yadif
Mit dieser Befehlszeile wollte ich eigentlich eine 1080i Aufnahme deinterlacen und mit x265 encoden:
vt -vf yadif=1 -h264 hevc -ac3 copy -o mkv
Wenn das Filter-Setzen automatisch erfolgt, dann wäre es ja doppelt gemoppelt, oder?
Auch weil ich im log-File sehe:
... -vf yadif=1,yadif ...
Und dies tät reichen:
vt -h264 hevc -ac3 copy -o mkv
VLG
Matthias
Danke, das dachte ich mir schon, dass es vom ffmpeg kommen könnte.
Beholfen habe ich mich nun mal so, dass ich den Startpunkt schneide und dann das mkv nochmal durch's Skript jage. Ohne den ss-Schalter funktioniert nämlich das -t oder -to.
Hallo, ich hoffe, es ist okay, hier im Thread eine Frage zu stellen.
Ich habe auf meiner Platte ein paar alte Klamotten gefunden, die ich gerne vom ts-Format ins mkv transferieren möchte.
Dabei wähle ich nur die Video und die ac3-Spur aus - gänzlich ohne Konversion - und lass laufen. Klappt prima.
Jetzt wollte zudem noch schneiden, weil ich es mittels vdr verpennt hatte. Eigentlich kein Thema dachte ich mir und suchte schnell die Zeiten raus.
Leider habe ich dabei ein Problem, denn er findet nur den Einstiegsschnitt mittels "-ss 00:03:48", aber nicht den Ausstiegssschnitt: weder mittels "-t 7471" oder mittels "-to 02:04:34".
Habe ich etwas übersehen?
Hier noch ein exemplarischer Skriptaufruf: "vt -h264 copy -ac3 copy -ss 00:03:48 -t 7471 -o mkv"
BTW: Das Skript ist super - herzlichen Dank!
Bei mir residiert momentan das J4105 (im schönen flachen Gehäuse ohne eingreifende Lüfter - sehr angenehm) mit DVB-Sky-Karten als Haupt-VDR unter yavdr-ansible (erst bionic nun focal). Kodi spielt zwar 4k-Filme ab, aber ohne HDR. Schade, dass Linux soweit hinterherhinkt.
Nur zu diesem Zweck habe ich mir den o.g. Odroid-N2 noch auf das VDR-Gehäuse geschnallt. Den nutze ich persönlich unter Coreelec lediglich für 4k-HDR Content, egal ob Platte oder von UHD1. Ich könnte damit per VINSI auch VDR gucken, aber wir kennen das ja. Es ist nicht so schön wie unter VDR höchstpersönlich.
Mit ist mittlerweile bewusst, dass das Setup auch nicht ewig halten wird. Die nächste Sau im Dorf wird kommen, genauso wie der nächste Hardwareumbau.
Man möge mir verzeihen, dass ich den Thread nach einem Jahr ausbuddele, aber es passt irgenwie nur hier rein.
Mein vdr ist unser yavdr-ansible und focal unterwegs mit dem J4105 Mainboard (ähnlich dem oberen 5005).
Beim Versuch yavdr-addon-pip zu nutzen, habe ich den gleichen log-Eintrag wie r371769 oben und der vdr startet ebenfalls neu.
Ich nehme an, das es im addon keine weiteren Fortschritte gab, das pip unter vaapi lauffähig zu machen.
Keine Kritik an dieser Stelle, kann ich doch selbst programmiertechnisch nichts beitragen - testen könnte ich schon.
Ich möchte nur sichergehen, dass ich konfigurationstechnisch nicht etwas essentielles übersehen habe.