Installation eines VDR+Plugins nativ auf CoreELEC Boxen

Quote from reini-at

/usr/local/lib/vdr/libvdr-softhdodroid.so.6: undefined symbol: glBindFramebuffer

Nein die suche ich nicht. Da hast du ein Problem mit deinen mesa libs weil da glBindFramebuffer beim laden nicht gefunden wird.

okay, dann cleane ich mal und baue neu

Quote from reini-at

ls /dev/dri ergibt folgendes:

by-path card0 renderD128

Hast du auch ein Dune HD ? Ich hätte vermute das es da eher eine card1 gibt.

oh pardon, nein, ich habe eine X96 max2+

Ok, dann vermute ich mal das es bei dir läuft wenn das Problem mit der lib behoben ist.

die Preisfrage: woher kommt der lib fehler fehlt mir irgendeine lib in der build umgebung?

vermutlich hat es damit was zu tun:

Package glesv2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glesv2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glesv2' found
Package egl was not found in the pkg-config search path.
Perhaps you should add the directory containing `egl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'egl' found
Package glesv2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glesv2.pc'
to the PKG_CONFIG_PATH environment variable

Quote from reini-at

Package glesv2 was not found in the pkg-config search path.

Läuft denn der build Fehlerfrei durch ? Falls nicht und das die Fehlermeldung ist, dann stimmt etwas nicht mit deine build Umgebung.

Ich war gestern abend etwas schnell mit der Anleitung wie man den vdr auf der Konsole startet. Besser ist es wenn du "/usr/local/bin/start_vdr.sh" aufrufst. Da wird die libmali preloaded.

Wenn damit immer noch glBindFramebuffer fehlt dann liegt es wirklich an den fehlenden gl libs.

Quote from Zabrimus

jrie

Danke. Die letzte Version des Patches funktioniert

https://github.com/Zabrimus/VDRSt…e29b1d1118552e7 Das in der commit message enthaltene jrie zeigt github als Link auf https://github.com/jrie und das ist jemand anders. Mein github ist aber https://github.com/j1rie. Also jrie at vdr-portal.de ohne @ vor jrie ODER @j1rie, was als Link auf https://github.com/j1rie angezeigt wird. Das sind so die github Eigenheiten ...

Danke.

Alle paar Jahre kommt es vor, dass git bzw. github mich an den Rand der Verzweiflung treibt

Quote from jojo61

Mär 18 16:56:02 CoreELEC kernel: [drm:meson_hdmitx_get_modes] *ERROR* get vic_list from hdmitx dev return 0.
Mär 18 16:56:02 CoreELEC vdr[1399]: Connector >HDMI-A-1< is connected
Mär 18 16:56:02 CoreELEC vdr[1399]: VideoInit: FindDevice() failed
Mär 18 16:56:02 CoreELEC vdr[1399]: amlSetString: error writing /sys/class/graphics/fb0/mode

Poste mal ein "ls /dev/dri" Und falls du es hinbekommst dann gehe mal per ssh auf die Box und start den vdr mal manuell. Um die dazu passende Zeile zu sehen mach ein "ps ax | grep vdr" und dann eine "systemctl stop vdropt"

Sorry, irgendwie ist das an mir vorbeigegangen.

Aber ich hatte inzwischen ein paar andere Probleme, da der USB-Stick mit der VDR*ELEC-Installation nicht mehr funktionierte.
Ich konnte CoreElec gar nicht mehr starten, da immer gleich am Anfang eine Bootmeldung kam, dass das Laufwerk "Storage" nicht gemountet werden konnte. Und damit ist CoreElec nicht mehr gestartet.
Ich habe dann festgestellt, dass der USB-Stick auf einmal einen Schreibschutz hat, der ums Verrecken nicht wegzubekommen ist.
Da habe ich mehrere Tage rumprobiert, aber der USB-Stick ist defekt! Nicht mal neu Formatieren kann ich den Stick.

Jetzt habe ich einen neuen Stick genommen und das System neu aufgesetzt.
Der Fehler mit dem fehlendes OSD bei Neustart/Reboot ist aber immer noch da!

Ich habe mal versucht die von Dir gewünschten Eingaben per SSH über "KiTTY" zu machen.

Hier mal die Ausgabe von "ls /dev/dri":
ls /dev/dri
by-path     card0       renderD128

Start des VDR von der Konsole : systemctl start vdropt
die Meldungen von ps ax | grep vdr :

Quote

CoreELEC:~ # ps ax | grep vdr
1439 root 0:00 {start_vdr.sh} /bin/sh /usr/local/bin/start_vdr.sh
1565 root 0:16 /usr/local/bin/vdr --grab=/storage/tmp --watchdog=0 --vfat --lirc --terminal=/dev/tty0 -v /storage/vdr_recordings --shutdown=shutdown -h now -P skindesigner -s /storage/.config/vdropt/plugins/skindesigner/skins -i /storage/.config/vdropt/plugins/skindesigner/installerskins -l /storage/backup/VDR-channellogos/vdr-channellogos -e /storage/cache/epgimages -P skinelchihd -l /storage/backup/VDR-channellogos/vdr-channellogos -P conflictcheckonly -P dbus2vdr -P devstatus -P epgsearch -P epgsearchonly -P epgsync -P femon -P live -P markad -b /usr/local/bin -l /storage/.cache/vdr/markad -P menuorg -c /storage/.config/vdropt/plugins/menuorg.xml -P osdteletext --directory=/storage/.cache/vdr/plugins/osdteletext -P remoteosd -P streamdev-client -P svdrpservice -P systeminfo --script=/storage/.config/vdropt/plugins/systeminfo/systeminfo.sh -P tvguideng -P softhdodroid -w alsa-driver-broken -w use-spdif -a hw:CARD=AMLAUGESOUND,DEV=2 -p hw:CARD=AMLAUGESOUND,DEV=2 -g 1920x1080
1704 root 0:00 grep vdr

Vielleicht kannst Du da was erkennen.
Ansonsten muss ich bei der "alten" VDR*ELEC-Version bleiben, wo ich noch das OSD auch nach einem Neustart habe, bleiben.

Quote from Paulaner

Vielleicht kannst Du da was erkennen.

Du hast fast alles richtig gemacht. Aber leider nur fast

Also wenn du dich mit ssh auf der Konsole eingeloggt hast dann stoppe den vdr mal mit "systemctl stop vdropt". Dann starte ihn auf der Konsole mit "/usr/local/bin/start_vdr.sh". Dann solltest du einige Debug prints sehen. Zumindest müsste er die EDID Modes ausdrucken die er versucht zu lesen. Dazu musst du wieder die "-g 1920x1080" in die config schreiben. Ausserdem müsste er einen Fehler ausgeben warum er das dri device nicht findet.

Okay, so kann ich es auch machen!

In der "softhdodroid.conf" habe ich das -g 1920x1080 wieder aktiviert + reboot.

Zuerst zum Test nochmals die Ausgabe von "ls /dev/dri":
ls /dev/dri
by-path     card0       renderD128

Nach dem systemctl stop vdropt wird der VDR beendet. Es kommt keine Meldung.

Jetzt wieder starten des VDR über:
/usr/local/bin/start_vdr.sh
es kommt allerdings nun nur 1 Meldung, mehr kommt da nicht:
killall: splash-image: no process killed

Der VDR wird wieder gestartet (ohne OSD). Es gibt keine Debug-Meldungen o.ä.
Ich habe auch den Loglevel vom VDR mal in der "vdr.conf" auf --log=3 gesetzt, aber da kamen auch keine weiteren Meldungen.

Hier mal noch die Meldung von den VDR-Einstellungen über ps ax | grep vdr :

Quote

CoreELEC:~ # ps ax | grep vdr
1575 root 0:00 {start_vdr.sh} /bin/sh /usr/local/bin/start_vdr.sh
1699 root 0:09 /usr/local/bin/vdr --grab=/storage/tmp --watchdog=0 --vfat --lirc --terminal=/dev/tty0 -v /storage/vdr_recordings --shutdown=shutdown -h now --log=3 -P skindesigner -s /storage/.config/vdropt/plugins/skindesigner/skins -i /storage/.config/vdropt/plugins/skindesigner/installerskins -l /storage/backup/VDR-channellogos/vdr-channellogos -e /storage/cache/epgimages -P skinelchihd -l /storage/backup/VDR-channellogos/vdr-channellogos -P conflictcheckonly -P dbus2vdr -P devstatus -P epgsearch -P epgsearchonly -P epgsync -P femon -P live -P markad -b /usr/local/bin -l /storage/.cache/vdr/markad -P menuorg -c /storage/.config/vdropt/plugins/menuorg.xml -P osdteletext --directory=/storage/.cache/vdr/plugins/osdteletext -P remoteosd -P streamdev-client -P svdrpservice -P systeminfo --script=/storage/.config/vdropt/plugins/systeminfo/systeminfo.sh -P tvguideng -P softhdodroid -w alsa-driver-broken -w use-spdif -a hw:CARD=AMLAUGESOUND,DEV=2 -p hw:CARD=AMLAUGESOUND,DEV=2 -g 1920x1080
1776 root 0:00 grep vdr

Muss ich evtl. noch was anderes machen?
Ich habe mal noch ein journal-Log nach dem Start des VDRs /usr/local/bin/start_vdr.sh gemacht, vielleicht hilft es:

journal-3.txt

Hmm da müsste eindeutig mehr debug kommen. Nimm mal das "--terminal=/dev/tty0" aus der vdr.conf raus. Das könnte dazu führen das die Debug Meldungen auf der falschen Konsole rauskommen.

Und nimm mal die "softhdodroid-zoom-off.sh" beim starten raus. Die fummelt sehr ungünstig beim start in denn ablauf.

Ich habe mal eine video.c mit weiteren debugs angehängt. Ich weiss nicht wie aber da müsstest du dann selber bauen.

Im log sieht man nun das er zumindest die /dev/card0 aufmachen kann, aber das setzen des mode geht schief.

Quote from Zabrimus

Es gibt es eine Möglichkeit eigene VDR*ELEC Build direkt auf Github durchzuführen.

Das mag schon stimmen, aber schnell ist was anderes. Auf meinen Notebook dauert ein kalter build knapp 2,5 Stunden. Und ein rebuild wenn ich etwas geändert habe z.b. am softhdodroid nur 1 Minute.

Alle dash2ts sachen baue ich nur als einzelnes package und schiebe es dann per scp auf die N2+ . Da läuft das dann im /storage/.config/vdropt directory weil ich es da hinschreiben kann.

Aber auch ein Image zu aktualisieren dauert auf dem N2+ nur ca. 3 Minuten. Ich nutze übrigens ein natives debian zum build.

Quote from jojo61

Aber auch ein Image zu aktualisieren dauert auf dem N2+ nur ca. 3 Minuten. Ich nutze übrigens ein natives debian zum build.

Selbiges hier. Ich baue aber auf einem RPI5. Und wenn ich nur softhddevice-drm-gles neu baue sind es 10 Sekunden und ich muss dank Samba auch keine *.so weiterschieben... Für public releases und build tests geht das mit den github actions wohl gut, aber als Dauerlösung für den Eigenbedarf und vor allem wenn man einzelne Packages testen und nicht das ganze image haben will, eher nicht so geeignet.

So, jetzt habe ich das --terminal=/dev/tty0 auskommentiert und da gibt es endlich ein paar Meldungen auf der Konsole:

Quote

CoreELEC:~ # systemctl stop vdropt
CoreELEC:~ # /usr/local/bin/start_vdr.sh
killall: splash-image: no process killed
FindDevice: open /dev/dri/card0: meson
Connector >HDMI-A-1< is connected
Mode 0 1920x1080 Rate 120
Mode 1 4096x2160 Rate 60
Mode 2 4096x2160 Rate 50
Mode 3 4096x2160 Rate 24
Mode 4 3840x2160 Rate 60
Mode 5 3840x2160 Rate 50
Mode 6 3840x2160 Rate 30
Mode 7 3840x2160 Rate 25
Mode 8 3840x2160 Rate 24
Mode 9 1920x1080 Rate 60
Mode 10 1920x1080 Rate 60
Mode 11 1920x1080 Rate 60
Mode 12 1920x1080 Rate 50
Use Mode 12 1920x1080 Rate 50
Error: : Invalid argument

Display More

Das Error::Invalid argument scheint ja auf das Problem hinzuweisen.
Dazu noch das journal-Log nach dem Ausführen von /usr/local/bin/start_vdr.sh:

journal-11.txt

Nach einer Weile, während ich das hier geschrieben habe, hat sich der VDR selbst beendet, Bild schwarz+kein Ton mehr.
Habe nochmals ein journal.log gemacht und angehängt:

journal-12.txt

Quote from Paulaner

So, jetzt habe ich das --terminal=/dev/tty0 auskommentiert und da gibt es endlich ein paar Meldungen auf der Konsole:

Wenn ich mir das Log so ansehe dann habe ich eine Idee was es sein könnte. Ich muss mir das hier auf der SK1 mal ansehen. Stay tuned.