Posts by hape60

    Einschalten per IR kann man im Coreelec Menü von Kodi einstellen. Mit meiner One4All im mce-Modus funktioniert das gut. Die Umschaltgeschwindigkeit ergibt sich aus dem Zuspieler (USB-Tuner oder Sat>IP) und dem softhd-Plugin und ist von CPU-Leistung weitestgehend unabhängig. Mit den Umschaltzeiten kann man leben, auf X64-Hardware habe ich da schon schnellere Umschaltzeiten gehabt.

    acpi-Wakeup funktioniert wohl eher nicht, da fehlt eine Echtzeituhr. WOL funktioniert, USB Wakeup sollte auch gehen. Für einen VDR mit Aufnahmefunktion würde ich eher den N2+ einsetzen. Ich nutze die TV-Boxen nur als Client, die Aufnahmen erledigt ein eigenständiger Server auf X64-Basis.

    Wie Paulaner bereits schrieb ist Coreelec die einzige Möglichkeit für eine volle Unterstützung von Amlogic.


    Für Allwinner und Rockchip kann (muss) man Libreelec mit vdr-plugin-softhddevice-drm verwenden. Das funktioniert auch mit Amlogic dann aber mit den Einschränkungen.


    Für eine Tanix TX6 und QBox+ habe ich das schon mal ausprobiert. Bis auf Wakeup per Remote funktioniert das auch brauchbar.

    jojo61


    In der chroot-Umgebung gibt es keine Einschränkungen bezüglich der Nutzung von irgendwelchen devices. Entscheidend ist nur, dass in der chroot die passenden /dev Einträge da sind. Also unter /dev/dvb sollten die adapter-Einträge da sein. 32 Bit oder 64 Bit spielen keine Rolle, da der Kernel komplett 64 Bit ist. Wie beta geschrieben hat, müssen die dvb-latest (oder crazy cat) Treiber als CE addon eingebunden sein. Damit habe ich meine DVBSky USB Box in Betrieb nehmen können. Da sind wohl wichtige Backports drin.

    jojo61


    das könnte man vielleicht versuchen. chroot ist aber einfacher. Das einzige was in chroot fehlt, ist systemctl das könnte man vielleicht sogar nachbilden. Das Problem ist ja, dass viele Plugins des VDR umfangreiche Abhängigkeiten von Bibliotheken haben, die CE nicht zur Verfügung hat oder in einer anderen Version bereitstellt. Ich würde das Debian-chroot einfach als so eine Art flatpack betrachten oder als Docker für Arme. :)

    jojo61


    Die Idee als Kodi addon finde ich durchaus bestechend. Aber wie du ja schreibst, spätestens bei dem Bau von einigen Plugins hat man diverse Abhängigkeiten von libs, die dann unter CE aufwendig nachgebaut werden müssten.


    Ich würde da eine Abwandlung des Ansatzes chroot vorschlagen:

    • Minimalsystem auf Basis von Debian 11 (Bullseye, armhf) als chroot. Ubuntu gibt es nur noch als armhf für RaspPi. Debian ist aber für CE aktuell genug. Das Minimalsystem kann mit debbootstrap unter Debian oder Ubuntu egal welche Version erzeugt werden. Auf der arm-Box kann man dann das Minimalsystem per apt vervollständigen.
    • CE Entwicklungssystem (coreelec 19) mit den Patches von Durchflieger. Ein komplettes Build inklusive vdr-addons. In dem Build muss die glibc 2.32 gegen 2.31 ausgetauscht sein.
    • Das Debian-System wird mit den relevanten libs, includes und pkgconfig (libdrm, ffmpeg, alsa, GLES usw.) aus dem CE Build versorgt. Einfach aus install_pkg und ggfls. aus toolchain in das Debian-System kopieren. Damit kann man schon softhdodroid im Debian chroot kompilieren.
    • vdr selber und alle anderen Plugins kann man als Quellpakete vom ppa von seahawk1986 holen und dann als normale .deb-Pakete im Debian chroot bauen. Die meisten Ubuntu-Abhängigkeiten kann man leicht umschiffen.
    • Die Pakete kann man dann mit dpkg -i installieren
    • kodi kann man nach /storage kopieren und dort patchen (für das Umschaltmenü), wenn man ein originales Image verwendet.
    • Für das gepatchte kodi muss kodi.service angepasst werden.
    • Jetzt braucht man noch ein bisschen systemd-Geraffel

    Man kann auch einen aarch64-build erzeugen und dann ein Ubuntu-chroot einsetzen. Das funktioniert genauso. Dann ist wohl das erzeugte image nicht richtig funktionsfähig und man muss dann auf ein originales armhf-Image als Wirt zurückgreifen. Funktioniert aber auch. Durch chroot hat jede Komponente alles was es braucht.


    Da ist viel Handarbeit dabei, die sich natürlich auch in ein paar Skripten abbilden lässt. Die Debian-Variante läuft inzwischen bei mir und steht kurz vor dem WAF Test.


    Vielleicht kann man die so erzeugten .debs irgendwo (in einem ppa?) als CE-Variante ablegen.

    JoeBar


    4.9 verwendet proprietäre Erweiterungen. Da hat man bei Android ein paar Anleihen gemacht. Das ist aber nicht portabel. Es funktioniert dank des CoreElec-Teams aber gut und durch jojo61 mit VDR und Kodi im Wechsel.


    Libreelec hat inzwischen die Arbeit für Amlogic wieder aufgenommen. Die verwenden einen 5.17er Releasekandidaten. Das Ergebnis ist aber noch nicht wirklich überzeugend. UHD und hevc funktionieren nicht. Die Fortentwicklung verläuft mangels Unterstützung nur sehr schleppend. Es ist nicht abzusehen wann das wirklich nutzbar wird.

    Das war etwas missverständlich ausgedrückt. mpeg2-Streams werden schon ausgegeben, sie sind nur in der Breite gestaucht. Das kann vielleicht an dem seltsamen Mix der ffmpeg-Bibliotheken (lbav...) liegen, den ich mir wahrscheinlich durch die Nutzung vom ppa von seahawk1986 und dem odroid-Ubuntu von Hardkernel zugezogen habe.


    Deshalb teste ich gerade ein sauberes Debian (armhf) in der chroot Umgebung. Das OSD läuft, es kommt nur kein Bild (

    echo 0 > /sys/class/video/disable_video hilft nicht). Kodi zeigt danach das gleiche Verhalten.

    Docker ist mir bei CE auch schon über den Weg gelaufen. Da gibt es etwas im Repository.


    Ich habe inzwischen vdr unter CE am laufen. Es gibt da noch ein paar Probleme aber grundsätzlich läuft vdr und Kodi.

    • CE auf sdcard kopiert
    • CE gebootet
    • Setup durchlaufen, ssh konfiguriert
    • In /storage Verzeichnis UBUNTU eingerichtet
    • Hardkernel Ubuntu Minimal C4-Image in UBUNTU ausgepackt
    • per ssh auf die Box
    • chroot Umgebung mit ubuntu.sh eingerichtet
    • $PATH gesetzt (siehe ubuntu.sh)
    • in UBUNTU chroot . /bin/bash
    • ppa von Seahawk eingebunden
    • Bionic Hardkernel Repository auf focal umgestellt
    • apt update / upgrade
    • mali_fbdev installiert
    • apt install vdr satip
    • softhdodroid kompiliert, es ging auch das vom Odroid N2+
    • Kodi ausserhalb von chroot mit systemctl stop kodi beendet
    • vdr innerhalb von chroot gestartet:
      vdr --lirc -P 'softhdodroid -a hw:CARD=AMLAUGESOUND,DEV=0' -P satip

    Läuft

    Es gibt noch ein paar Darstellungsprobleme bei mpeg2-Sendern: kein 16:9. Nach dem einmaligen Aufruf von vdr bleibt bei Kodi beim abspielen von Videos der Bildschirm dunkel.


    Hans-Peter

    Aus meiner Sicht macht es Sinn corelec als Boot Loader zu verwenden, da es ein perfekt laufendes Ökosystem mitbringt. CE ist nämlich ein hybrides System bestehend aus einem 64Bit Kernel und 32Bit Userland Programmen. Denkbar wäre es die SYSTEM-Datei durch eine Initrd im gleichen Format zu ersetzten, die dann das Ubuntu in der Hardkernel-Variante startet.


    Einfacher wäre aber das Vorgehen, wie es beta68 mit Kodi vorgeführt hat. Nur dass statt CE in einer chroot-Umgebung das Ubuntu von Hardkernel zum Einsatz kommt. Dann hätte man auch Kodi zur Verfügung.


    Hans-Peter

    jojo61


    kls hat die Funktion in 2.4.0 eingeführt:


    C
    1. virtual const cSize &MaxPixmapSize(void) const;
    2. ///< Returns the maximum possible size of a pixmap this OSD can create.
    3. ///< Derived classes can reimplement this function if their implementation
    4. ///< of cPixmap can only provide pixmaps up to a certain size.
    5. ///< The default implementation returns a cSize object of maximal size
    6. ///< (INT_MAX). However, memory restrictions may still apply.

    In seiner Implementation wird INT_MAX zurückgeliefert. Das ist erst einmal nur eine einfache Festlegung, damit ein Plugin, das Pixmaps der cOsd-Klasse nutzen möchte, weiß wie groß sie werden dürfen. Also entweder gibt es eine Hardwarebegrenzung für die Pixmaps oder der Hauptspeicher ist der limitierende Faktor oder eine sinvolle Größe in Bezug auf die Bildschirmauflösung.

    Hi jojo61,


    Es fehlt noch die Funktion MaxPixmapSize. Ohne diese Funktion gibt es zumindestens bei einem Skin (ElchiHD) Ausfallerscheinungen. Ich habe da mal einen Vorschlag angehängt.


    Die Anpassungen von seahawk1986 habe ich auch in softhdodroid übernommen. Dann sind die schwarzen Balken verschwunden.


    Ein Problem ist dann aber noch vorhanden. Zentrierter Text erscheint nicht zentriert, bzw. ist gar nicht vorhanden (z.b. bei der poweroff-Meldung). Das betrifft neben softhdodroid auch softhdvaapi. Mindestens ein Ausgabe-Plugin hat dafür eine Sonderbehandlung. Die habe ich mal in skinElchi eingebaut:


    ich nutze das Plugin auf dem odroid n2+ mit dem Plugin softhdodroid.


    Da gibt es ein paar Fehldarstellungen:



    Es werden einige Zeilen nur schwarz dargestellt. Das gilt z.B. auch für die Auswahlzeile in den Menüs. Gleichzeitig gibt es Fehlermeldungen:



    Hans-Peter

    Ich habe das Ausgangsproblem ebenfalls.


    Es liegt an den mesa-vulkan-drivers_21 in Kombination mit libplacebo-4.156.0+git20210801-196-fa1b558 und vdr-plugin-softhdvaapi-3.3.1+git20210416-11-2562c4e.


    Ich habe auf folgende Versionen zurückgestellt:


    libplacebo127_3.120.1+git20210416-40-52bbecc-0yavdr1~focal_amd64

    libplacebo-dev_3.120.1+git20210416-40-52bbecc-0yavdr1~focal_amd64

    mesa-vulkan-drivers_20.2.6-0ubuntu0.20.04.1_amd64

    vdr-plugin-softhdvaapi_3.3.1+git20210416-11-2562c4e-0yavdr2~focal_amd64 (mit obigen libplacebo-dev kompiliert)


    Damit gibt es eine Ausgabe und keine Fehlermeldungen.


    Hans-Peter