Posts by beta

    horchi Es ist sehr aufwendig, den Hardkernel-Kernel zu fixen/adaptieren. Ohne ein Update der Umgebung läuft es bei mir mit der Ubuntu 20.04-Version sehr gut. Ich hatte damals versucht, den Kernel so zu ändern, dass auch KODI beschleunigt läuft. Das hat zwar funktioniert, ich musste KODI dann aber in einer CHROOT-Umgebung laufen lassen, damit die Beschleunigung funktionierte (das typische libMali-Problem). Das ist das Problem, wenn man nicht für alles den Source-Code hat.


    Was einwandfrei funktioniert, ist CoreElec zu installieren und dann alles in einer chroot-Umgebung laufen zu lassen. Da kann man zumindest sicher sein, dass der Kernel OK ist. Und wenn man den 5.4-Kernel braucht, kann man die -NO-Version nehmen, die läuft auch ganz gut. Über Skripte kann man leicht einstellen, was zuerst booten soll (VDR, KODI oder sogar X11). Ich habe in meinem Github auch ein install.sh-Skript, das eine komplette chroot-Umgebung mit allen Updates installiert (https://github.com/beta68). Für mich ist das immer noch die einfachste Methode. Man kann dann mit einem apt update/upgrade alle Pakete aktualisieren oder mit apt-get nachinstallierten, was man braucht. Man merkt gar nicht, dass man in einer chroot-Umgebung ist. Und sollte Hardkernel den Kernel updaten (zu was, was nicht kompatibel ist), ist das völlig egal für die CHROOT-Umgebung. So hat man die volle Funktionalität und verliert sie bei einem Kernel-Update nicht. Alles andere ist wie gesagt sehr aufwendig und mühsam, nachzuhalten (siehe mein Github und den Kernel darin).


    Das sind aber nur meine Erfahrungen und ich will Dich zu nichts überreden. Richtig kompliziert wird es dann, wenn noch Ambilight dazu kommt. Das lief dann irgendwann mit meinem Kernel, aber es gab Mikro-Ruckler. Da sowieso entweder KODI oder VDR in einer CHROOT-Umgebung laufen muss, damit beides beschleunigt läuft, habe ich es irgendwann aufgegeben, den alten 4.9-Kernel für alles aktuell zu halten. Wenn man KODI nicht braucht, muss man es ja nicht starten...


    P.S.: Die ganze Story kannst hier nachlesen: https://forum.odroid.com/viewtopic.php?f=177&t=43593

    Das VDR-Log sieht so aus:


    Code
    Jan 02 20:31:28 CoreELEC vdr[1083]: [1083] [vdrweb
    Jan 02 20:31:28 CoreELEC vdr[1083]: [1083] [vdrweb] Start Http Server on :0
    Jan 02 20:31:31 CoreELEC vdr[1083]: [1083] [vdrweb] HTTP error (InsertChannel): Could not establish connection
    Jan 02 20:31:31 CoreELEC vdr[1083]: [1083] [vdrweb] Attached HbbTV ait filter to device 1, vdrDev=2 actDev=1, Sid=0x2b66
    Jan 02 20:31:33 CoreELEC vdr[1083]: [1087] [vdrweb] InsertHbbtv, browser is not available


    Edit: Der Test mit 0.0.0.0 liefert auch


    Code
    [2024-01-02 20:42:11.803] [cefbrowser] [error] [vdrremoteclient.cpp:226] HTTP error (SendHello): Could not establish connection
    [2024-01-02 20:42:12.339] [cefbrowser] [error] [vdrremoteclient.cpp:226] HTTP error (SendHello): Could not establish connection

    VDR läuft korrekt, WLAN IP siehe unten (Ethernet IP geht auch nicht):

    Dr. Seltsam : Ich habe das ATTA mit einem Skript gelöst, das beim booten mit gestartet wird, falls das Plugin DETA ist (nutzt FLIRC, geht sicher aber auch mit IR):



    Der Part in der runvdr sieht so aus:



    Das Problem mit dem Audio habe ich ebenfalls gelöst. Ich speichere einmal eine Datei namens also.dat, die meine Konfiguration für VDR Audio enthält:


    alsactl store -f /home/user/alsa.dat


    Bevor das Plugin dann wieder attached wird, mache ich ein


    alsactl restore -f /home/user/alsa.dat


    Den externalplayer habe ich aufgegeben. Als noch keine Plugins installiert waren in KODI, lief das einwandfrei mit meinem sleep 3 (siehe vorher). Danach dann nicht mehr. Über die commands.conf funktioniert es aber.


    Das letzte Problem ist das web Plugin von Zabrimus. Der cefbrowser kann keine Kommunikation zum web Plugin aufbauen. Ich weiß noch nicht warum (siehe Thread von Zabrimus ).

    Zabrimus Wenn ich Dein Plugin unter dem neuen Kernel CE-no laufen lasse, erhalte ich im cefbrwoser folgende Fehlermeldung:



    [2024-01-02 17:20:12.057] [cefbrowser] [error] [vdrremoteclient.cpp:226] HTTP error (SendHello): Could not establish connection

    [2024-01-02 17:20:12.073] [cefbrowser] [error] [vdrremoteclient.cpp:226] HTTP error (SendHello): Could not establish connection


    Sagt Dir das etwas? Das Plugin meldet dann, dass der Browser nicht gestartet ist. Die IP-Adresse in sockets.ini ist korrekt.

    Auch 127.0.0.1 geht nicht.

    Ich nutze es ja noch gar nicht produktiv, ich möchte nur ein wenig basteln.


    Der Tipp mit dem KODI zu früh starten war Gold wert. Mit einem kleinen sleep funktioniert es, auch per externalplayer, egal mit welcher libMali.


    Ich schaue mir das mit dem Audio-Device mal selbst an. Vielleicht finde ich ja etwas.

    Die Parameter spielen keine Rolle. Das Verhalten scheint zufällig zu sein: Mal gibt es nach Rückkehr von KODI zu VDR DD-Ton, mal nicht. Wenn ich dann ein paar Mal das Plugin DETA und wieder ATTA, dann geht es irgendwann wieder. Irgendwas scheint mit der Initialisierung von DD-Audio von DETA -> ATTA nicht mehr zu funktionieren mit dem 5-Kernel.


    2. Problem: VDR -> KODI und zurück. Das ist abhängig vom Skin, der in Skindesigner eingestellt ist, ob es funktioniert oder ob nicht. Hier scheint irgendeine OpenGL-Ressource noch nicht richtig freigegeben zu werden. Nehme ich die KODI libMali.so für softhdodroid, funktioniert der Wechsel z.B. mit shady_kiss. Nehme ich ich r12 aus dem CoreElec Repro, geht das nicht. Dafür geht es mit der CE libMali nicht bei anderen Skins.


    Edit: Was mir noch auffällt: Wenn der Wechsel VDR->KODI ohne crash KODI funktioniert, ist für kurze Zeit ein Teil des OSDs sehr groß auf dem Bildschirm zu sehen. Erscheint das nicht, crasht KODI bei mir.

    jojo61 Jetzt, wo die TBS5580 läuft, ist mir ein weiteres Problem aufgefallen. Nach Rückkehr von KODI zu VDR funktioniert Dolby Digital nicht mehr. Statt eines vernünftigen Tons kommt nur ein Geknatter. Nach einem Reboot funktioniert es wieder, so lange, bis man zu KODI wechselt und zurück.


    Das mit dem Crash bei ausgeschaltetem TV ist echt nervig, da VDR dann munter coredumps schreibt und zwar so lange, bis das filesystem voll ist.


    Sonst läuft es rund und flüssig.

    Hallo Dr. Seltsam und frohe Weihnachten. Es knallt bei VDR->KODI (Kodi Crash) mit dem Externalplayer. Commands.conf funktioniert. Beide killen eigentlich nur den looper, und unter 4.9 funktioniert das auch. Leider habe ich die Sourcen des Kernels nicht, so dass ich an dieser Stelle nicht Debugger kann. Ich habe ja auch noch das Problem, dass VDR Crash, wenn der TV nicht beim Booten an ist (ich arbeite hier gerade an einem Skript, das Softhdodroid in dem Fall suspended startet und erst attached, wenn der TV an ist.

    Hier ist der BT:

    Edit: Vielleicht muss ich noch dazu sagen, dass der DVB-Empfänger noch nicht funktioniert. Evtl will er ein Video abspielen und hat keines?


    Starting program: /usr/local/bin/vdr -v /video -c /var/lib/vdr -Psofthdodroid\ -a\ hw:CARD=AMLAUGESOUND,DEV=1\ -r50\ -g3840x2160

    [Thread debugging using libthread_db enabled]

    Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

    [New Thread 0x7fecb13170 (LWP 1033)]

    [New Thread 0x7fe7fff170 (LWP 1034)]

    [Thread 0x7fe7fff170 (LWP 1034) exited]

    [New Thread 0x7fe7fff170 (LWP 1038)]

    [New Thread 0x7fe695b170 (LWP 1039)]

    FindDevice: open /dev/dri/card0: meson

    Connector >HDMI-A-1< is not connected

    Requested Connector not found or not connected


    Thread 1 "vdr" received signal SIGABRT, Aborted.

    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

    50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

    (gdb) bt

    #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

    #1 0x0000007ff79e9aac in __GI_abort () at abort.c:79

    #2 0x0000007ff57f9cfc in VideoInit (i=<optimized out>) at video.c:1827

    #3 0x0000007ff57fd150 in StartVideo () at softhddev.c:2974

    #4 Start () at softhddev.c:2974

    #5 0x0000007ff57e5b90 in cPluginSoftHdDevice::Start() (this=<optimized out>) at softhdodroid.cpp:2880

    #6 0x000000555567127c in cPluginManager::StartPlugins() (this=<optimized out>) at plugin.c:384

    #7 0x00000055555eb52c in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at vdr.c:868

    Das Problem ist, dass der Kernel zu crashen scheint, jedenfalls schreibe CoreElec fleißig in .cache/cores.

    Die Kernelmeldungen sind:


    Dec 24 13:48:36 CoreELEC kernel: frddrs[0] registered by device ff642000.audiobus:tdmb

    Dec 24 13:48:36 CoreELEC vdr.sh[1184]: FindDevice: open /dev/dri/card0: meson

    Dec 24 13:48:36 CoreELEC vdr[1184]: [FindDevice] DRM have 1 connectors, 1 crtcs, 2 encoders

    Dec 24 13:48:36 CoreELEC vdr[1184]: Connector >HDMI-A-1< is not connected

    Dec 24 13:48:36 CoreELEC vdr[1184]: Requested Connector not found or not connected

    Dec 24 13:48:36 CoreELEC vdr[1184]: VideoInit: FindDevice() failed

    Dec 24 13:48:36 CoreELEC vdr[1184]: amlGetString: error reading /sys/class/graphics/fb0/modes

    Dec 24 13:48:36 CoreELEC vdr[1184]: Initial Screen 0-0 set to 1920-1080

    Dec 24 13:48:36 CoreELEC vdr[1184]: Unable to get DMABUF

    Dec 24 13:48:36 CoreELEC kernel: frddrs[0] released by device ff642000.audiobus:tdmb

    Dec 24 13:48:42 CoreELEC vdr.sh[943]: Aborted (core dumped)


    Danach ist meine chroot-shell leider abgehängt, so dass ich nicht mit dem gdb daran komme. Ich muss da erst was umbauen, oder kannst du schon etwas erkennen?