Posts by presskopf

Ein Dank an diesen Thread. Er hat quasi auch meine 650 gerettet.

Herrlich, wie gut das wieder funktioniert.

Servus seahawk1986

wenn es was bzgl. des neuen yavdr-frontend-Skript zu testen gibt, einfach Bescheid geben. Vielleicht kann ich da ja helfen.

So bis jetzt klappt das Setup mit Softhddrm und Kodi-gles ganz gut.

Nur manchmal zappelt das Bild extrem, wenn beim Zurückwechseln auf vdr das softhddrm wieder attached wird (siehe auch oben). Ich habe mir ein deta-atta-skript gebaut, das ich aus dem Menü manuell ausführe, dann verschwindet das fast immer. Manchmal muss ich aber auch fünf, sechs mal das deta-atta durchführen. Das nervt ein wenig.

Prinzipiell ist das ganze wohnzimmertauglich.

seahawk1986 Hattest Du nochmal die Möglichkeit eine Wechsel-Kombi von softhdvaapi unter x und kodi-gles ohne x aufzusetzen?

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.

seahawk1986

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=yes

Manchmal 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.

Post

RE: Flatpak: Kodi GLES (HLG & HDR support) - kodi-gles.flatpak

Ich konnte Deinen Fehler nachvollziehen

Info´s zu HDR & KODI unter LINUX

[…]

damit sieht der Config-Teil für Kodi so aus -- Jemand eine Idee was fehlt oder noch angepasst werden sollte (für eine VAAPI-Lösung)?

(Code, 43 lines)

cinfo

December 31, 2024 at 10:02 AM

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

Quote from pille2011

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.

Quote from Paulaner

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-grub

Vielen 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:

• Das normale Starten per FB (PC, Receiver, TV) klappt einwandfrei: Bild und Ton sind da.
• Der Timer-Start funktioniert auch. D.h. der Kollege startet, nimmt auf und verabschiedet sich mit Herunterfahren (alles ohne Receiver und TV natürlich).
  Allerdings: Wenn ich zum per-Timer gestarteten VDR den Fernseher und den Receiver anschalte, erhalte ich kein Signal: Kein Bild und kein Ton.

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.