Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Hallo Zabrimus,

    bekomme folgende Fehlermeldung bei Nutzung des skinflatplus-Plugin

    Code
    Mai 29 12:13:45 CoreELEC vdr[3973]: [3973] loading plugin: /usr/local/lib/vdr/libvdr-skinflatplus.so.2.6.1
    Mai 29 12:13:45 CoreELEC vdr[3973]: [3973] ERROR: libXext.so.6: cannot open shared object file: No such file or directory

    Gruß

    kla.b

    VDR 1 : yavdr ansible focal, Asus M3N-HDMI, AMD x240, 2x TT3200,1x Sundtek DVB-C, 6 TB HDD

    VDR 2 : yavdr ansible focal, ASRock J5005, DVBSky S952 Dual

    VDR 3 : reelVDR, IBM Thinkcenter, HDe, am Beamer Sony AW15

  • bekomme folgende Fehlermeldung bei Nutzung des skinflatplus-Plugin

    Das Problem kann ich gar nicht reproduzieren. Den Skin kann ich auswählen und er wird auch genutzt.

    Welchen Branch nutzt du denn? 19, 20 oder Matrix?


    Funktionieren andere Skins oder tritt der Fehler exklusiv bei skinflatplus auf? Ich kann nicht nachvollziehen, woher die Abhängigkeit von libXext herkommen soll. Im Build Plan taucht libXext auch gar nicht auf.

  • Zabrimus ,

    vielen Dank für das Zufügen der Fonts! :thumbup:

    Jetzt funktioniert mein Skin auch! :)


    Das menuorg-Plugin teste ich bei Gelegenheit auch noch!

    Aber jetzt darf ich erstmal nicht mehr am VDR arbeiten, sonst lyncht mich die Family! ;)

  • Das ist doch zum Mäusemelken X(Jetzt habe ich meine Fonts verloren. Teletext, Skin, ...

    Bin auf der Fehlersuche.


    Edit:

    Jetzt sollte wieder alles funktionieren.

    Hi Zabrimus,

    eine dumme Frage: Wie update ich denn Deine Installation? Muss ich jedesmal wieder in einen komplett neuen Build Prozess anstossen?

    Beim Einspielen von Fonts vermutlich nicht, aber sonst?
    git pull; ./build-local.sh -t -0 ?


    Nochmal Danke für Deine tolle Initiative! Macht Spass!

  • eine dumme Frage: Wie update ich denn Deine Installation? Muss ich jedesmal wieder in einen komplett neuen Build Prozess anstossen?

    Beim Einspielen von Fonts vermutlich nicht, aber sonst?
    git pull; ./build-local.sh -t -0 ?

    Genauso mache ich es auch. Das reduziert enorm die Build Zeit, wenn die Verzeichnisse build.CoreELEC* und sources nicht gelöscht worden sind.


    git checkout coreelec-20-VDR; git pull --all; ./build-local.sh -t -0

  • Es kann wohl manchmal die Notwendigkeit auftreten, weitere Libraries mittels LD_PRELOAD vor dem Start von VDR zu laden.

    Dazu habe ich die VDR Startscripte geändert um dies zu ermöglichen:


    The VDR start scripts adds the mandatory library /usr/lib/libMali.so to LD_PRELOAD. It is possible to add other libraries if needed by setting a variable in /storage/.profile

    Code
    VDR_LD_PRELOAD=/path/to/lib1.so:/path/to/lib2.so

    Normalerweise wird man das wohl nicht brauchen und muss entsprechend nix ändern.

  • VDR_LD_PRELOAD=/path/to/lib1.so:/path/to/lib2.so

    Vielen Dank dafür! :)

    Damit konnte ich nun einen Sundtek Dual DVB Stick mit VDR an einer TanixTX3 in Betrieb nehmen. :)


    Mit nano /storage/.profile  folgendes hinzufügen, nachdem unter CoreELEC der Sundtek Treiber als Addon installiert wurde!

    Code
    ...
    VDR_LD_PRELOAD=/storage/.kodi/addons/driver.dvb.sundtek-mediatv/lib/libmediaclient.so
    ...


    Viele Grüße

    Uwe

    Einmal editiert, zuletzt von Uwe ()

  • Zabrimus ,

    nach dem das menuorg-Plugin läuft, kommt auch schon der nächste Wunsch von mir:

    Bitte das vdr-plugin-dbus2vdr einbauen.


    Ich benutze das Plugin um zur Laufzeit des VDR das Bild per Fernbedienung zu zoomen, weil ich die schwarzen Balken bei manchen Filmen einfach als störend empfinde. Vor allem da ich einen Philips-TV mit Ambilight habe, wo dann die schwarzen Balken kontraproduktiv sind! ;)

    Dazu gab es mal vor einiger Zeit einen Thread: [SOLVED] Zoomfunktion in Softhddevice


    Seit dem läuft das bei mir perfekt auf meinem yaVDR.

    Das hätte ich nun auch gern auf meinem Odroid-Client am laufen, aber dazu benötige ich eben das vdr-plugin-dbus2vdr.

    Aber das ganze eilt jetzt nicht, denn ich bin jetzt eh erstmal über 2 Wochen unterwegs und kann nichts am VDR machen! :)

  • Bitte das vdr-plugin-dbus2vdr einbauen.

    Erledigt oder auch eher nicht. Das Plugin ist committed und kann gestartet werden.

    Aber jetzt steht mir meine Unkenntnis über den DBUS im Weg, weil ich keine Ahnung habe, was schief geht und wie das zu fixen ist:

    Code
    Mai 31 17:40:43 tanix1 vdr[4330]: [4330] starting plugin: dbus2vdr
    Mai 31 17:40:43 tanix1 vdr[4330]: [4330] creating directory /storage/.config/vdropt/plugins/dbus2vdr
    Mai 31 17:40:43 tanix1 vdr[4330]: [4368] dbus2vdr: mainloop started
    Mai 31 17:40:43 tanix1 vdr[4330]: [4368] dbus2vdr: System: connected with unique name :1.13
    Mai 31 17:40:43 tanix1 vdr[4330]: [4368] dbus2vdr: thread-pool for handling signal-emits started
    Mai 31 17:40:43 tanix1 vdr[4330]: Unexpected reply 2 when releasing name de.tvdr.vdr
    Mai 31 17:40:43 tanix1 vdr[4330]: [4368] dbus2vdr: System: connected with unique name :1.14
    Mai 31 17:40:43 tanix1 vdr[4330]: Unexpected reply 2 when releasing name de.tvdr.vdr
    Mai 31 17:40:43 tanix1 vdr[4330]: [4368] dbus2vdr: System: connected with unique name :1.15
    Mai 31 17:40:43 tanix1 vdr[4330]: Unexpected reply 2 when releasing name de.tvdr.vdr

    Und das geht so weiter bis ich den VDR stoppe. Was ist falsch (konfiguriert) und wie kann ich das beseitigen?

  • Ich wollte das auch mal ausprobieren und bekomme den folgenden Fehler:


  • Zitat
    1. cp: cannot stat '/home/dirk/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/_vdr-plugin-streamdev-da74779591827ad7e10493b0eade65a11c525171/usr/local/lib/vdr/libvdr-streamdev-client.so.2.6.1': No such file or directory

    Zur Info, diesen Fehler hatte ich am Montag auch ... die 20er lief durch. Nutze jetzt die 20er CoreELEC Version.

  • Was genau wollt ihr denn bauen? Also was ist das Ziel? Das tar oder das installierbare Image?

    Für den Parameter "-t" gibt es tatsächlich noch ein Problem bei streamdev.


    Der Unterschied ist, daß der Parameter "-t" ein File build-artifacts/coreelec-19-vdr.tar.gz anlegt, daß auf der Maschine entpackt werden muss. Dabei wird VDR in /opt/... entpackt.

    Das nutze ich persönlich gar nicht mehr, weil die Installation des Images "-0" oder "-9" so schnell und einfach geht.


    Kleine Umfrage:

    Nutzt jemand den Parameter "-t" noch absichtlich oder installiert VDR in das /opt Verzeichnis? Weil ich eigentlich plante, den zu entfernen.


    Edit:

    Ich sehe gerade, daß "-t" explizit nur den Branch "19.4-Matrix" baut. Nicht den 19er oder 20er.

  • Was genau wollt ihr denn bauen? Also was ist das Ziel? Das tar oder das installierbare Image?

    Für den Parameter "-t" gibt es tatsächlich noch ein Problem bei streamdev.

    Wie gesagt ich bin noch am ausprobieren. Ich hab bereits ein Coreelec 19.4 am laufen und wollte da zusätzlich den VDR installieren.

  • Ah okay. Dann liegst du mit "-t" richtig. Ich habe das Problem hoffentlich beseitigt, im Moment läuft ein Test-Build, der allerdings noch etwas dauert. Ich will sicherstellen, daß nicht noch etwas nicht funktioniert.

  • Der build des VDR-only tar (build-local.sh -t) sollte jetzt wieder funktionieren.


    Allerdings wird nicht alles funktionieren, weil in dem Fall die Änderungen, die ich am Image gemacht habe, natürlich nicht vorhanden sind. Spontan fallen mir ein: vdr-plugin-dbus, die zusätzlichen Font-Verzeichnisse, pip, ...


    Und bei den notwendigen Änderungen bin ich zur Überzeugung gelangt, daß das VDR-only tar Anfangs eine nette Idee war, aber man sich zuviele Nachteile mit in den Warenkorb legt. Ich hatte dieselbe Befürchtung, daß ich mein System zerschiessen könnte, wenn ich ein Update auf das neue erzeugte Image durchführe. Allerdings ist der Update Mechanismus in alle Richtungen (zumindest wenn man in der Version bleibt: 19 oder 20) bisher sehr stabil und zuverlässig. Ich bin zwischendurch auch mal immer wieder auf offiziellen CoreELEC Images gesprungen, um etwas zu testen.


    Um das Originalsystem wieder herzustellen reicht es aus:

    - die Änderungen in /storage/.profile, /storage/.config/autostart.sh rückgängig machen

    - die systemd Dateien in /storage/.config/system.d zu löschen (switch_kodi_vdr.* und vdropt.*)

    - das Verzeichnis /storage/.config/vdropt und /storage/.config/vdropt-sample löschen

    - Das Original-Image von CoreELEC einspielen (/storage/.update)


    Wenn man sich unsicher ist, kann man die vorhandene SD einer bereits bestehenden Installation klonen und dann das Update durchzuführen. Oder falls man nur VDR und die Kodi Standardinstallation ausprobieren will, eine neue SD zu erstellen.


    Ich habe mich bemüht, die VDR sehr vorsichtig in das bestehende Image zu integrieren.

  • Das Problem kann ich gar nicht reproduzieren. Den Skin kann ich auswählen und er wird auch genutzt.

    Welchen Branch nutzt du denn? 19, 20 oder Matrix?


    Funktionieren andere Skins oder tritt der Fehler exklusiv bei skinflatplus auf? Ich kann nicht nachvollziehen, woher die Abhängigkeit von libXext herkommen soll. Im Build Plan taucht libXext auch gar nicht auf.

    Hallo Zabrimus,

    hat leider etwas gedauert.


    Alles neu installiert --- läuft tip-top :)


    git checkout coreelec-20-VDR; git pull --all; ./build-local.sh -t -0


    Vielen Dank für Deine Hilfe


    Gruß

    kla.b

    VDR 1 : yavdr ansible focal, Asus M3N-HDMI, AMD x240, 2x TT3200,1x Sundtek DVB-C, 6 TB HDD

    VDR 2 : yavdr ansible focal, ASRock J5005, DVBSky S952 Dual

    VDR 3 : reelVDR, IBM Thinkcenter, HDe, am Beamer Sony AW15

  • Ich habe noch ein Problem mit den DVB USB Treibern. Dazu habe ich unter Kodi das Paket "DVB Treiber form latest Kernel" installiert (sonst geht es nicht).

    Leider ist dieses Paket mit CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=y übersetzt und damit wird das Log zugemüllt.


    Zabrimus könntest du nicht per default die aktuellen DVB Kerneltreiber installieren und dann mit CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=n übersetzen ?

    Ich denke es werden eh immer die aktuellen Treiber vom Anwender nachgeladen.

  • Ich habe noch ein Problem mit den DVB USB Treibern. Dazu habe ich unter Kodi das Paket "DVB Treiber form latest Kernel" installiert (sonst geht es nicht).

    Leider ist dieses Paket mit CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=y übersetzt und damit wird das Log zugemüllt.


    Zabrimus könntest du nicht per default die aktuellen DVB Kerneltreiber installieren und dann mit CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=n übersetzen ?

    Ich denke es werden eh immer die aktuellen Treiber vom Anwender nachgeladen.

    Damit verlasse ich meine Wohlfühlzone, weil ich nicht weiß, wie ich das machen soll.


    Ich nehme an, du willst diesen Treiber packages/linux-driver-addons/dvb/dvb-latestmit übersetzt und im Image haben und dabei soll CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=ygesetzt werden. Richtig?

    Ich finde aber schon keine Stelle, an der die Config überhaupt auf "y" gestellt wird.


    Hmm. Das scheint aus dem media_tree zu kommen. Aber selbst da finde ich auf Anhieb keinen Hinweis.

    Ich brauche ein paar Hinweise, was wie gemacht werden soll.

  • Ich brauche den Parameter auf n. Ich weiss auch nicht wie du das ins Image bekommst. Aber sollte das nicht auch wie alle anderen Pakete funktionieren ? Beim Kernel sind die Parameter alle in .config Evtl. kannst du das dann patchen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!