Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Es sollte nun so wie bei Kodi sein. Ich habe da nun eigentlich die ganze Routine abgeschrieben :)

    Aber du hast schon recht, es ist gefühlt immer noch etwas langsamer als früher. Könnte aber auch an meinem Tastendelay der Fernbedienung liegen.

    Ich teste das nochmal nach.

  • So nun habe ich noch etwas getestet und bin verwirrt :)

    Also das senden eines einzelen UP oder DOWN Kommandos dauert ca. 80ms. Egal welche Version ich nutze.Also in beiden Api Varianten.

    Wenn ich aber mehrere Kommandos hintereinander sende (also die Taste auf der Fernbedienung festhalte) dann dauert ein Kommando hin und wieder bis zu 200ms.

    Da scheint dann eine Verstopfung :) vorzuliegen und das vorherige Kommando doch noch nicht komplett abgearbeitet zu sein. Auch in allen Varianten.

    Das einzige was ich hier vermuten kann ist das dieses "Nacharbeiten" mal schneller und mal langsamer geht.

    Evtl. ist es insgesamt schneller wenn man das Repeat der Fernbedienung etwas langsamer einstellt um die "Verstopfung" zu umgehen.

    Ich werde die Version, die ich hier zum testen eingestellt habe, aber nun doch ins Git einchecken. Weil sie mir subjektiv schneller vorkommt.

  • Hi Zabrimus,

    ich habe mit dem aktuellen Stand leider ein Problem.
    Der build für CE21 läuft durch, bei CE22 bekomme ich diesen Fehler:

    Hast Du eine Idee, was da nicht passt?

    Lothar

  • Hast Du eine Idee, was da nicht passt?

    Versuch mal ein

    Code
    ./clean.sh exfatprogs
    ./clean.sh spdlog

    Es kann sein, daß noch etwas nicht baut. Ich meine, ich hätte auch Probleme mit lirc gehabt. Aber dann wieder das clean.sh geeignet aufrufen.

    Das spdlog wird für den Build von Kodi benötigt. Bei mir ist der auch schief gegangen.

  • hm gefühlt ist es besser, aber noch nicht ganz so wie früher - ist das auch dein empfinden? oder liegt das nun an mein system :)

    Hallo Zabrimus und reini-at .

    Ich habe heute das 20.5 von gestern und ein Image von reini-at ("CoreELEC-Amlogic-ng.arm-20.5-Nexus_devel_20241128230944.tar")

    gestestet.

    Beim offiziellen Release gibt es FB-hänger, d.h. manche Tasten kommen auch nach mehrfachem Drücken nicht durch. :(

    Beim Image von reini-at (ebenfalls per update eingespielt) funktionieren alle Tasten. Über Millisekunden kann man sich streiten, aber hier ist das System benutzbar.

    Eigentlich haben doch beide Varianten diesselbe Code-Basis?

    Ich werde bei Gelegenheit nochmal ein System "from scratch" aufsetzen.

    Ich weiß daß mein TV / CEC ziemlich geschwätzig ist. Im Systemlog ist mir aufgefallen, daß alle 20s ein Block CEC-Müll (ich habe keine Taste gedrückt) im VDR ankommt. Anbei ein Auszug:

    journalctl -f

    Nov 30 14:10:19 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 6 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 238 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 55 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Nov 30 14:10:40 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 35 f

    Nov 30 14:10:41 CoreELEC-2 vdr[3722]: [3738] changing pids of channel 1429 (Sky Sport F1) from 1791+1791=27:0;1794=qae@106,1796=qaf@106:0:32 to 1791+1791=27:0;1794=qae@106:0:32

    Nov 30 14:11:01 CoreELEC-2 vdr[3722]: [cecremote] Not primary device, Channel Switch 0 f

    Gruß K.

    Und bist Du nicht willig, so brauch ich Geduld!
    System: TV Philips 4k, + CEC-Remote, Octopus Net

    Odroid N2+ mit VDRSternELEC

  • Zabrimus bei mir bricht der build von vdr-plugin-radio-ng immer mit folgender Meldung ab:

    make[1]: Leaving directory '/home/reinhard/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/_vdr-plugin-radio-ng-f0c89c2c2285743bcc62ecca473b270359af8775'

    cp: cannot stat '/home/reinhard/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/_vdr-plugin-radio-468280ff7252f9504e5b3d63fcf5d277b5627541/config/scripts': No such file or directory

    hast du eine Ahnung woran das liegen könnte, und wie ich das beheben könnte?

    Danke im Voraus!

    VDR1+2: OctopusNet - Minisatip - X96 max plus 2

  • Hi Zabrimus,

    ich habe eben nochmal den aktuellen Stand abgerufen und ein build für CE22-no gemacht.

    Leider bekomme ich immer noch den gleichen Fehler wie in der letzte Woche, auch nach einem clean-package.sh für exfatprogs

    Irgend eine Idee?

  • Hast du ganz frisch gebaut? Mit dem Bump von libtool auf 2.5.4 hat sich die toolchain geändert und das könnte zu dem Problem führen...

    Ich würde ein clean-packages.sh libtool bzw. clean-packages.sh libtool:host probieren, libtool bzw. libtool:host neu bauen und wenns dann nicht klappt, build löschen.

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • Eigentlich haben doch beide Varianten diesselbe Code-Basis?


    Ich werde bei Gelegenheit nochmal ein System "from scratch" aufsetzen.

    Die Basis sollte eigentlich dieselbe sein. Vielleicht sollte ich auf dem Server auch mal ein komplettes Clean machen. Nur dauert der Build aller Varianten dann mal locker knapp 24 Stunden.

    cp: cannot stat '/home/reinhard/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/_vdr-plugin-radio-468280ff7252f9504e5b3d63fcf5d277b5627541/config/scripts': No such file or directory

    Mist. Das hat mit radio und radio-ng zu tun. Ich fixe das. Aber wenn das jetzt so sehe, dachte ich eigentlich, daß wäre schon gefixed? Egal....

    Hast du ganz frisch gebaut? Mit dem Bump von libtool auf 2.5.4 hat sich die toolchain geändert und das könnte zu dem Problem führen...

    Genau. Damit kämpfe ich auch schon eine weile. Bisher sträube ich mich, alles neu bauen zu lassen. Aber ich fürchte, daß ich nicht darum kommen werde.

  • Ich würde ein clean-packages.sh libtool bzw. clean-packages.sh libtool:host probieren, libtool bzw. libtool:host neu bauen und wenns dann nicht klappt, build löschen.

    Bin auch in die Falle getappt. Ein clean-package.sh ... reichte nicht.

    Aber ein komplett neu bauen funktionierte dann.

    :thumbup:

    Klick für meine Hardware

    vdr1: Odroid N2+ 4GB | VDR*ELEC CE21-ng 64GB eMMC | Video über USB: 4TB SATA Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | IR onboard

    vdr2: Odroid N2+ 4GB | VDR*ELEC CE22-no 256GB eMMC | Video: 1TB microSD (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | IR onboard

    vdr3: HP ProDesk 400 G3 SFF (i3) | NVidia Quadro T400 | 2x 8GB | System: Ubuntu 24.02 LTS, yavdr ansible (vdr 2.7.3) auf 30GB mSATA SSD | Video: 3TB SATA (XFS) | 1x WinTV dualHD | IRMP RP2040 KBD

    TV: Philips 55OLED805

  • Dagegen hilft nur, das Intervall der LE/CE Updates zu strecken... Wer bleeding edge sein will, muss Kompromisse eingehen :)

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

  • Dagegen hilft nur, das Intervall der LE/CE Updates zu strecken... Wer bleeding edge sein will, muss Kompromisse eingehen :)

    Ja. Das ist eine Gratwanderung. Im Moment mache ich ein Update maximal einmal pro Woche (außer es gibt z.B. in Kodi einen Fehler und es baut nicht). Die Frage wäre natürlich, wie oft ein Update wirklich sinnvoll ist. Die Updates in CE/LE sind teilweise schon ziemlich umfangreich. Ich versuche bei einem Update von CE/LE immer ein Build aller relevanten Konfigurationen um grobe Probleme zu vermeiden. Aber alles kann ich damit nicht abfangen.

    Natürlich kann man die Version in config/versions manuell downgraden oder eine andere Version eintragen.

  • Solange keine sicherheitsrelevanten Commits kommen und alles baut, würde ich persönlich das Intervall strecken.... So riesig sind die upstream Änderungen nicht. Die User schreien dann schon, wenn Kodi nachgezogen werden soll ;) Und selber kann man das ja auch machen...

    Meine VDRs

    (SatIP Server) --- Kathrein Exip 418 ---

    (Server) --- HW: RPI5 --- SW: RPiOs, VDR 2.7.2 mit streamdev, satip/vtuner-ng, vdrmanager, live, epgsearch, markad ---

    (Client 1+2) --- HW: Radxa Rock 4 Plus - RK3399 --- SW: VDR*ELEC mit softhddevice-drm-gles ---

    (WIP) --- Tanix TX6, RPi5, RPi4, Odroid N2+, WetekPlay2 --- SW: VDR*ELEC mit softhddevice-drm-gles --

    Edited once, last by rell (December 7, 2024 at 12:27 PM).

  • Solange keine sicherheitsrelevanten Commits kommen und alles baut, würde ich persönlich das Intervall strecken...

    Vielleicht sollte ich das tatsächlich machen. Ich habe halt immer noch die Hoffnung, das z.B. CE-22 irgendwann produktiv gehen kann. Das kann ich aber auch lokal testen und dann evt. ein allgemeines Update machen.

  • Hi,

    ich denke schon, dass man da relativ nah dran bleiben sollte.

    Ich hab z.B. bei meinem Odroid N2auf der eMMC CE-21, während auf der SD Card CE-22 läuft.

    Wenn da was nicht klappt, nehme ich die SD Card raus und boote dann auf das stabile CE-21.

    Lothar

  • Zabrimus Könntest du bitte noch die ntftables mit aufnehmen.

    Ich versuche gerade ein Wireguard VPN aufzubauen und da fehlt das File "nft". Das wird in wg-quick benötigt um die default route zu setzen.

    Und ja ich weiss das man connman nutzen kann aber das funktioniert leider auch nicht mit Nordvpn.

    Edit:

    Es könnte auch mit iptables-restore gehen. Aber da bekomme ich folgende Fehlermeldung:

    Code
    iptables-restore -n
    Warning: Extension CONNMARK is not supported, missing kernel module?

    Da frage ich mich welches Kernelmodul hier fehlt.

    Edit2:

    Es geht um diese Befehle:

    Code
    iptables -I POSTROUTING -t mangle -m mark --mark 57841 -p udp -j CONNMARK --save-mark
    iptables -t mangle -I PREROUTING -p udp -j CONNMARK --restore-mark

    Wenn man sich dann die Tabelle mit "iptable -t mangle -L" anschaut dann kommt die Fehler meldung von oben.

    PS: Da braucht du erstmal keine nftables einzubauen. Das liegt irgendwo in der Kernel Config.

    Edited 4 times, last by jojo61 (December 9, 2024 at 3:18 PM).

  • Ich habe das Problem mit den iptables gelöst.

    Nur musste ich nun leider feststellen das es keine lauffähige widevine Version mehr für die ng-Version gibt.

    Das was der inputstream-helper da herunterlädt funktioniert nicht mehr und es gibt einen Fehler beim ldd der lib :(

    Hat jemand noch eine lauffähige Version von widevine für den Odroid N2 ?

  • Hi Zabrimus,

    mit deinem letzten Update baut das Plugin eepg nicht mehr.

    Der Patch lässt sich nicht mehr anwenden. Möglicherweise ist der bei der neuen Version auch nicht mehr notwendig.

    Wenn ich den lösche, läuft der Build wieder durch.

    Schöne Grüße

    Lothar

Participate now!

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