Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Ich habe einen Fix committed, wobei ich nicht verstehe, warum das überhaupt einen Unterschied machen sollte. Zumindest der Build des Plugins funktioniert wieder.

    Ich habe jetzt mal einen kompletten Build gestartet.


    Mein Fix im package.mk (das scheint aber wahrscheinlich nicht notwendig zu sein):

    Code
    pre_make_target() {
      export LDFLAGS="$(echo ${LDFLAGS} | sed -e "s|-Wl,--as-needed||") -L${SYSROOT_PREFIX}/usr/local/lib"
      export PKG_CONFIG_DISABLE_SYSROOT_PREPEND="yes"
    +  export PKG_CONFIG=${TOOLCHAIN}/bin/pkg-config
    +  export ECPPC=${TOOLCHAIN}/bin/ecppc
    }


    Wichtiger ist wohl das hier. Und das verstehe ich überhaupt nicht. Das sollte eigentlich überhaupt keine Auswirkungen haben - nach meinem Verständnis:

    Ich warte jetzt erst einmal den Testbuild ab.

  • Es ist immer wieder Mühsam das ganze neu zu bauen. Nun findet er mal wieder die libxml nirgendwo weil wohl gitlab.gnome.org mit einem internal Server Error antwortet und der libreelec mirror die gesuchte libxml Version (2.12.6) nicht hat.

    D.h. dann wohl warten bis der gnome server wieder läuft :(

  • jojo61: Nutzt du beim bauen nicht den cache von ./sources ?

  • Nutzt du beim bauen nicht den cache von ./sources ?

    Jain hin und wieder lösche ich alles und baue von Grund auf neu. Aber dein Tipp ist gut weil ich die "alte" Version nur umbenannt habe und dort im Cache die libxml2 noch vorhanden ist. Die habe ich nun einfach umkopiert. Ich bin halt einfach ein Trottel was diese Make Magic angeht.

  • Es kam mal wieder alles zusammen und die Fehlerkombination hat leider Probleme ergeben.


    Wie in dem vdr-plugin-live Thread ersichtlich, funktionierte live nach einem Upgrade auf die letzte Version von VDR*ELEC nicht.

    Die Ursache für den live-Fehler lag darin, daß z.B. die Javascript-Dateien von Live nach der Installation nicht aktualisiert wurden. Aber das eigentliche Problem liegt im fehlerhaften Packaging von radio-ng und dem Abbruch von unzip, der nicht aufgefallen ist.

    Zuviele verwirrende Informationen?


    Okay. Der Reihe nach. Beim Start von VDR wird zusätzlich das script /usr/local/bin/vdrsternupgrade.sh ausgeführt um ein Upgrade verschiedener Konfigurationsdateien vorzunehmen, wenn eine neue Version installiert wurde. Darunter befinden sich eben auch die Dateien des Live-Plugins.

    Durch das fehlerhafte Packaging der radio-ng Samples ist unzip mit einem Fehler ausgestiegen und das eigentliche Upgrade wurde eben nicht durchgeführt und Live funktionierte nicht so, wie gewünscht.


    Ich sagte ja, es kam alles zusammen.... :rolleyes: Die letzte Version im Git von VDR*ELEC sollte wieder einwandfrei funktionieren.

  • Jetzt habe ich einen seltsamen Fehler. Mit der aktuellen GIT Version stürzt der VDR mit SIGABRT ab wenn ich das live plugin aktiviere.

    Allerdings nur wenn ich es mit systemctl start vdropt starte. Wenn ich es aus der shell mit /usr/local/bin/start_vdr.sh starte dann funktioniert alles.


    Im dump file ist leider nichts zu sehen.

    Code
    Program terminated with signal SIGABRT, Aborted.
    #0  0x0000007f98dfb3b4 in ?? ()
    (gdb) bt
    #0  0x0000007f98dfb3b4 in ?? ()
    #1  0x0000007f99227ea8 in ?? ()
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)
  • Jetzt habe ich einen seltsamen Fehler. Mit der aktuellen GIT Version stürzt der VDR mit SIGABRT ab wenn ich das live plugin aktiviere.

    Allerdings nur wenn ich es mit systemctl start vdropt starte. Wenn ich es aus der shell mit /usr/local/bin/start_vdr.sh starte dann funktioniert alles.

    Aus der Shell heraus funktioniert es, aber über systemd beim Start nicht? Seltsam.

    Welche Version willst du denn starten? 20, 21, 22? ng, ne, no?

  • Ich starte 21-ne. Könnte es sein das für live aus systemd heraus irgendwie etwas im Environment fehlt.

    Das live Plugin ist eben auch nur ein Plugin und warum gerade das Probleme machen sollte, verstehe ich nicht.

    Aber war live nicht das Plugin, das bei fehlendem oder nicht konfiguriertem locale abgestürzt ist?

    Code
    # needed for locale / OSD language
    . /storage/.profile
    export LOCPATH=/storage/.kodi/addons/service.locale/locpath

    Das ist auch nur Teil des Startscripts und somit eigentlich unabhängig von systemd und manuellem Aufruf.

  • Nun mal zu einem neuen Problem. Ich habe eine installation mit Satip und 4 Tunern. Dort kommt es immer wieder vor das Aufnahmen nicht

    funktionieren und die Aufnahme leer ist. Nun habe ich mal ein umfangreiches Log eingerichtet und da sind mir 2 Dinge aufgefallen:


    Erstens wird immer wieder die Zeit über den NTP für mehrere Sekunden 1 bis 5 zurück gesetzt. Das könnte daran liegen das der Zugang zum Internet über WLAN erfolgt und es etwas dauert bis die NTP Antwort zurückkommt. Dann passiert im Log folgendes:

    Code
    Okt 25 13:00:28 CoraVDR connmand[3574]: ntp: adjust (jump): -5.708094 sec
    Okt 25 13:00:22 CoraVDR connmand[3574]: ntp: adjust (jump): -3.807258 sec
    Okt 25 13:00:18 CoraVDR systemd-journald[2231]: Time jumped backwards, rotating.
    Okt 25 13:00:18 CoraVDR kernel: asoc-aml-card auge_sound: TDM[2] Playback stop
    Okt 25 13:00:28 CoraVDR vdr[3878]: [8463] ERROR: driver buffer overflow on device 1
    Okt 25 13:00:28 CoraVDR vdr[3878]: [3954] CAM 1: module ready
    Okt 25 13:00:28 CoraVDR vdr[3878]: [3954] CAM 2: module ready
    Okt 25 13:00:28 CoraVDR vdr[3878]: [3954] CAM 3: module ready
    Okt 25 13:00:28 CoraVDR vdr[3878]: [3954] CAM 4: module ready

    D.h. es tritt ein buffer overflow auf Device 1 auf und das ist wohl das DVB Device. Nun möchte ich erstmal den NTP Server auf einen lokalen Rechner umleiten, aber die connman config ist leider nicht schreibbar. Geht das irgendwie doch den NTP Server einzustellen ?

    Das ganze passiert nahezu bei jedem NTP update.


    Zweitens sehe ich im Log folgendes:

    Ist da etwas faul mit der Verwaltung der Demux Devices ?? Das ganze läuft mit den vtuner-ng devices.

  • Das wird ihm nicht helfen, da VDRCoreELEC nach dem Booten in der Regel nicht Kodi, sondern vdr startet. Kodi wird erst ausgeführt, wenn man es über das VDR-Menü startet.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • jojo61 Lässt du zeitgleich auch VDR die Systemzeit setzen? Das hat bei mir Probleme verursacht.

  • Das wird ihm nicht helfen, da VDRCoreELEC nach dem Booten in der Regel nicht Kodi, sondern vdr startet.

    Das ist nicht unbedingt richtig für alle Einstellungen. Auch das Setup von Kodi speichert die Einstellungen lokal im Filesystem, die nicht von Kodi sondern häufig von systemd Scripts oder den Programmen gelesen und verarbeitet werden.


    CE nutzt conman für die NTP Server und die Einstellungen kann man ändern, in dem eine Datei

    Code
    /storage/.config/connman_main.conf

    angelegt wird. Diese hat dann eine höhere Priorität, als der Default

    Code
    /etc/connman/main.conf
    Code
    # set variable for connman main.conf location
    if [ -f /storage/.config/connman_main.conf ]; then
      export CONNMAN_MAIN="--config=/storage/.config/connman_main.conf"
    else
      export CONNMAN_MAIN="--config=/etc/connman/main.conf"
    fi


    Und darin gibt es dann die interessanten Einstellungen, wie z.B.

    Code
    # Assume that service gateways also function as timeservers.
    UseGatewaysAsTimeservers = false
    
    # List of Fallback timeservers separated by ",".
    # These timeservers are used for NTP sync when there are
    # no timeservers set by the user or by the service, and
    # when UseGatewaysAsTimeservers = false. These can contain
    # mixed combination of fully qualified domain names, IPv4
    # and IPv6 addresses.
    FallbackTimeservers = 0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org


    In meinem Netz lasse ich allerdings die NTP Server vom DHCP Server liefern und muss mich soweit nicht um die NTP Einstellungen der Clients kümmern.

  • Ich habe nun mal auf einen lokalen NTP Server umgestellt. Damit ist das verhalten zwar immer noch falsch aber anders. Nun springt die Zeit mal 1 bis 3 Sekunden vor und dann auch mal wieder zurück. Der lokale NTP ist zwar im Netz aber ich denke das eth auf dem Odroid ist mit den SatIP Daten so überlastet, das die anderen Daten mal früher und mal später durchkommen. Evtl. sollte ich die NTP ganz abklemmen und die Zeit über den VDR setzen lassen. Derzeit ist das ausgeschaltet.


    Zum zweiten Problem habe ich mal die open files angeschaut und gesehen das /dev/dvb/adapter0/demux0 25 mal vom vdr offen ist, obwohl nur ein Stream aktiv ist. Da frage ich mich wozu die alle offen gehalten werden.

  • Da müßte ein ordentliches chrony oder ein guter alter ntpd/ntpc rein. Da springt nix bei 1-3 Sekunden. Außerdem, wenn die RTC des VDR so falsch liegt, mal die CMOS-Batterie kontrollieren ...

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!