Beiträge von 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.

Dr. Seltsam

Wenn das CE Startlogo weiter läuft, dann muss mit killall (ggfls. in der chroot Umgebung per apt installieren) der splash-Prozess gekillt werden. Ein ps aux zeigt das Kommando.

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.

jojo61

Das ist ja super. Funktioniert wirklich gut.

Nur bei Pro 7 Maxx und Sixx stimmt das Seitenverhältnis noch nicht.

Jetzt fehlt nur noch ein Umschaltscript und die Box kann eingesetzt werden

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.

Dieter

Tanix TX3 4GB/64GB

Hans-Peter

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

Hallo Dieter,

kennst du eigentlich

openwrt Hub

Da ist ein armbian für TV-Boxen.

Grüße, Hans-Peter

Hallo Dieter,

danke erst einmal für die die Dateien.

Leider kann ich dir kein jungfräuliches printenv log zur Verfügung stellen. Coreelec war schon auf der Box.

Grüße, Hans-Peter

Dieter

kannst du den BOOT-Teil der sd-Card für die Tanix-TX3 irgendwie zur Verfügung stellen.

Ich bekomme das irgendwie nicht ans laufen.

Danke Hans-Peter

jojo61

kls hat die Funktion in 2.4.0 eingeführt:

virtual const cSize &MaxPixmapSize(void) const;
       ///< Returns the maximum possible size of a pixmap this OSD can create.
       ///< Derived classes can reimplement this function if their implementation
       ///< of cPixmap can only provide pixmaps up to a certain size.
       ///< The default implementation returns a cSize object of maximal size
       ///< (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.

--- openglosd.h.orig    2022-02-21 12:35:53.887624588 +0100
+++ openglosd.h 2022-02-21 16:28:19.553909253 +0100
@@ -706,6 +706,7 @@
     std::shared_ptr < cOglThread > oglThread;
     cVector < cOglPixmap * >oglPixmaps;
     bool isSubtitleOsd;
+    static cSize maxPixmapSize_ODROID;
   protected:
   public:
      cOglOsd(int Left, int Top, uint Level, std::shared_ptr < cOglThread > oglThread);
@@ -716,6 +717,7 @@
     virtual void Flush(void);
     virtual void DrawScaledBitmap(int x, int y, const cBitmap & Bitmap, double FactorX, double FactorY,
         bool AntiAlias = false);
+    virtual const cSize &MaxPixmapSize(void) const;
     static cOglOutputFb *oFb;
 };

--- openglosd.cpp.orig  2022-02-19 00:57:00.367157962 +0100
+++ openglosd.cpp       2022-02-21 14:55:21.449060595 +0100
@@ -2536,6 +2536,7 @@
 * cOglOsd
 ******************************************************************************/
 cOglOutputFb *cOglOsd::oFb = NULL;
+cSize cOglOsd::maxPixmapSize_ODROID(8192,8192);

 cOglOsd::cOglOsd(int Left, int Top, uint Level, std::shared_ptr < cOglThread > oglThread):cOsd(Left, Top, Level)
 {
@@ -2597,6 +2598,11 @@
     return cOsd::SetAreas(&area, 1);
 }

+const cSize &cOglOsd::MaxPixmapSize(void) const
+{
+  return maxPixmapSize_ODROID;
+}
+
 cPixmap *cOglOsd::CreatePixmap(int Layer, const cRect & ViewPort, const cRect & DrawPort)
 {   
     if (!oglThread->Active())

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:

--- ../tmp/vdr-plugin-skinelchihd-1.0.0+git20220213-1-5c392fd/background.c      2022-02-13 14:58:12.000000000 +0100
+++ background.c        2022-02-21 15:26:38.821347924 +0100
@@ -182,6 +182,12 @@
       direction = 0; // no scrolling
    }
 
+   // if (centered && textWidth <= vPort.Width())
+   // see vdr-plugin-softhddevice openglosd.cpp
+   int x = 0;
+   int w = Font->Width(*text);
+   if (maxwidth > vPort.Width() && !x) x = vPort.Width() - w; //For skinelchihd, but other skins not need this...
+   
    if (centered && textWidth <= vPort.Width())
    {
       LOCK_PIXMAPS;
@@ -189,7 +195,8 @@
       if (isempty(text))
          pixmap->Fill(colorBg);
       else
-         pixmap->DrawText(cPoint(0, 0), *text, colorFg, colorBg, Font, maxwidth, Font->Height(), taDefault);
+//         pixmap->DrawText(cPoint(0, 0), *text, colorFg, colorBg, Font, maxwidth, Font->Height(), taDefault);
+         pixmap->DrawText(cPoint(x, 0), *text, colorFg, colorBg, Font, maxwidth, Font->Height(), taDefault);
 
       pixmap->SetDrawPortPoint(cPoint((vPort.Width() - textWidth)/2 , 0));
    }

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