Video Treiber für Odroid-N2+ (softhdodroid)

Ich habe zuerst die Version von beta getestet, allerdings gleich die festen pip-Zuweisungen auf 0 rückgängig gemacht. Damit traten keine Probleme auf, auch nicht, nachdem ich den Aufruf von VideoThreadExit in VideoExit generell machen ließ. Inzwischen trudelte die Version von jojo rein, und auch mit der habe ich bei meinen ersten Tests (Umschalten auf Kodi in chroot mittels Aufruf  /usr/bin/killall looper in der commands.conf und dadurch getriggert Start von Kodi per softoggle-Script) keine Probleme. Das crashte vorher mit VideoThreadExit nahezu immer.

Auch das Beenden von vdr scheint nun sauberer zu gehen. Ich hatte bisher immer das Problem, das bei einem "killall -9 vdr runvdr" das letzte Bild auf dem TV-Schirm eingefroren sichtbar blieb. Jetzt wird der Schirm schwarz.

So, nun kommt leider der nächste Fehlerbericht von beta. Crasht es denn auch, wenn Du die von jojo entfernten Checks if (OdroidDecoders[pip] != NULL)  sowie das

    if (hwdecoder == NULL)
    {
      return;
    }

in void InternalOpen wieder einbaust?

Quote from beta

Vielleicht erklärt das ja auch die Probleme mit externalplayer/Wechsel zu KODI per commands.conf, die einige hier hatten.

Das externalplayer-Plugin ist für den Wechsel zu Kodi m.E. ungeeignet: Wenn damit ein externes Programm aufgerufen wird, bleibt vdr solange im Playmode pmExtern_THIS_SHOULD_BE_AVOIDED, bis das in der externalplayer.conf definierte externe Programm beendet wird. In einer chroot-Umgebung ist das der Befehl (/usr/bin/killall looper) , ansonsten wäre es zumindest ein vorgeschaltetes Script, das für den DETA sorgt. In beiden Fällen ist aus Sicht des externalplayer-Plugins das extern gestartete Programm mit der Ausführung des Befehls bzw. Scripts damit beendet und es setzt vdr zurück auf Playmode 0 pmNone), obwohl Kodi noch nicht mal richtig gestartet ist. Der Weg über die commands.conf ist definitiv besser.

Ich hatte übrigens auch mal eine Phase, wo ich die Crashes allein durch DETA/ATTA in der Konsole auslösen konnte, ohne dass Kodi im Spiel war. Das ließ sich aber irgendwann nicht mehr reproduzieren und trat dann nur noch in Verbindung mit dem Wechsel zu Kodi auf.

Dr. Seltsam Das doktort ja nur an den Symptomen rum. behebt aber nicht die Ursache. Es gibt zudem einige Stellen, wo der Pointer abgefragt werden muss. Die müsste man ALLE "sauber" machen durch Abfrage des Pointers und entsprechende Debug-Ausgaben.

Vermutlich wird es dann laufen (und das PIP aus dem Tritt bringen). Erst dann sieht man, was in welcher Reihenfolge falsch aufgerufen wird und kann die verschiedenen Threads locken und richtig freigeben.

Mit der von Dir vorgeschlagenen Änderung habe ich gestern Abend angefangen und bin dann auf die nächsten Crashes gelaufen, die ich dann analog Stück für Stück behoben habe.

Da es meiner Meinung nach eine race-condition ist (eben nicht thread-safe), hängt es natürlich vom Kernel und dem Prozessor ab, auf dem das läuft. Auf meinem Odroid hatte ich nie Probleme, bei der Ugoos tauchen sie nun auf. Das habe ich aber analog bei vielen meiner Programme schon erlebt...

Noch ein Nachtrag zum Thema Test: Je nachdem, was vorher gelaufen ist, braucht es 10-20 DETA/ATTA, bis das ganze crasht. Ich teste daher immer im gdb, also ein systemctl stop vdr.service und unter chroot killall vdr. Dann in der chroot gdb --> file /usr/local/bin/vdr RETURN --> run -Psofthdodroid. Dann ist man auch sicher, dass nichts anderes läuft. Von einer anderen Konsole aus kann man dann einfach ein vdrpsend PLUG softhdodroid DETA und ATTA machen, beliebig schnell und beliebig oft. Ich habe das in eine for-Schleife gepackt (while geht auch) und ein Script daraus gemacht. Dann sieht man schön an einem Counter, wie oft es läuft. Und wie gesagt, manchmal ist es 10-15 Mal gelaufen, bevor es gecrasht ist.

Kann es ein Optimier-Problem bzgl. der Compiler-directive sein? Vielleicht ist die -O3 hier kritisch und sollte nach -O2 oder -O1 geändert werden? Das Problem hatte ich auch schon...

Was hat es denn mit dem "close handle failed PIP 0" auf sich, kann das das Problem verursachen?

close handle failed PIP 0 Ungültiger Dateideskriptor

Damit crasht es nicht mehr, aber:

Es kommen einige

Internal Close pip 0 mit Handle -1

[Thread 0x7fe943f0a0 (LWP 5488) exited]

[Thread 0x7feac6f0a0 (LWP 5487) exited]

[Thread 0x7fe9c4f0a0 (LWP 5485) exited]

[Thread 0x7fea45f0a0 (LWP 5484) exited]

Internal Close pip 0 mit Handle -1

[Thread 0x7fe8c2f0a0 (LWP 5490) exited]

[New Thread 0x7fe8c2f0a0 (LWP 5496)]

[New Thread 0x7fea45f0a0 (LWP 5497)]

AmlCodec open failed.

[New Thread 0x7fe9c4f0a0 (LWP 5499)]

[New Thread 0x7feac6f0a0 (LWP 5500)]

[New Thread 0x7fe943f0a0 (LWP 5501)]

Internal Close pip 0 mit Handle -1

Internal Close pip 0 mit Handle -1

[Thread 0x7feac6f0a0 (LWP 5500) exited]

[Thread 0x7fe9c4f0a0 (LWP 5499) exited]

Internal Close pip 0 mit Handle -1

no decoder

und irgendwann AmlCodec open failed und no decoder. Was Du oben siehst sind die Threads im gdb. Ich sitze nicht vor dem TV, daher kann ich nur raten, dass ich kein Bild mehr hätte? Ich hatte wieder zwischen DETA/ATTA getogglet.

Das sieht gut aus. Falls Du die Reihenfolge der calls noch benötigst, die sehen bei mir so aus:

odecvideoclose

vor Internal close

tid = 9265

Internal Close pip 0 mit Handle -1

amlReset

amlReset

vor Internal close

tid = 9286

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9300

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9313

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9328

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9342

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9360

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9374

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

amlReset

vor Internal close

tid = 9387

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

nach Internal close

vor Internal close

tid = 9398

Internal Close pip 0 mit Handle -1

amlReset

vor Internal close

tid = 9398

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

nach Internal close

vor Internal close

tid = 9412

Internal Close pip 0 mit Handle -1

amlReset

vor Internal close

tid = 9412

nach Internal close

codecvideoclose

vor Internal close

tid = 9265

nach Internal close

vor Internal close

tid = 9426

Ansonsten glaube ich, dass Du es einchecken kannst. Nochmal lieben Dank, jojo61 für Deinen unermüdlichen Einsatz an diesem tollen Plugin und für das ganze Debugging.

Quote from jojo61

Ja das ist mir schon bekannt. Nur leider kann ich mangels Hardware nicht mit dem Kernel 5.4 testen.

Ich habe hier nur Odroid-N2+ und wie du schon sagst, da läuft es mit Kernel 4.9 und 5.15. Wobei der Kernel 5.15 eh noch nicht für produktiven Einsatz geeignet ist. Da hat Dr. Seltsam schon recht ein SK1 würde da sicher helfen

Ich hatte gestern festgestellt, dass Hardkernel zwar nicht auf ihrer Übersichtsseite, wohl aber auf dem Downloadserver eine Ubuntu 24.04-Version hat. Darin ist ein Kernel 6.6.44-118 enthalten. Beim Bauen von softhdodroid erhalte ich

/usr/bin/ld: cannot find -lMali: No such file or directory
/usr/bin/ld: cannot find -lavfilter: No such file or directory

Komischerweise gibt es libavfilter, warum er es nicht findet muss ich noch verstehen. Aber eine libMali gibt es definitiv im Gegensatz zu 20.04 (nutze ich bisher) nicht. LibreElec ist auch bei Kernel 6.6.x - werde nachher mal versuchen die libMali daraus zu nehmen. Oder gibt es eine einfachere Möglichkeit an eine passende libMali zu kommen? Hat bereits jemand erfolgreich (/-los) mit dem Ubuntu 24.04 basierendem Image softhdodroid ans Laufen gebracht?

Quote from mrjoe

LibreElec ist auch bei Kernel 6.6.x - werde nachher mal versuchen die libMali daraus zu nehmen. Oder gibt es eine einfachere Möglichkeit an eine passende libMali zu kommen? Hat bereits jemand erfolgreich (/-los) mit dem Ubuntu 24.04 basierendem Image softhdodroid ans Laufen gebracht?

LibreELEC nutzt keine libmali sondern vernünftigerweise mesa. Die libmali muss außerdem immer zum Kerneldevice kompatibel sein. Die kannst du nicht nach Belieben mischen. Gibt es eine libGLESv2.so.* ?

Quote from rell

LibreELEC nutzt keine libmali sondern vernünftigerweise mesa. Die libmali muss außerdem immer zum Kerneldevice kompatibel sein. Die kannst du nicht nach Belieben mischen. Gibt es eine libGLESv2.so.* ?

Ja, gibt es:

/usr/lib/aarch64-linux-gnu/libGLESv2.so
/usr/lib/aarch64-linux-gnu/libGLESv2.so.2
/usr/lib/aarch64-linux-gnu/libGLESv2.so.2.1.0

Du meinst alternativ mit softhddevice-drm-gles versuchen? Wäre schade, da softhdodroid unter 20.04 wirklich stabil lief.

Ich bezweifle, dass der Kernel 6.6 die von softhdodroid und CoreElec verwandten amlogic-eigenen Treiber enthält. Die sind nicht im mainline-Kernel und müssen extra in den Kernel reingepatcht werden. Der von CoreElec in der in Entwicklung befindlichen „no“ (new order) Variante verwandte 5.15 scheint der ‚höchste‘ verfügbare Kernel zu sein, der diese Patches enthält.

An einer mainline-Unterstützung wird seit Jahren gearbeitet, aber nach meiner Kenntnis kommen Funktionsumfang, Hardwareabdeckung und Stabilität noch nicht annähernd an die proprietären amlogic-Treiber ran.

Moin jojo,

nach dem update auf den neuen git-Stand hagelt es bei mir unter Kernel 4.9.269 im log endlos

Kernel: amstream_do_ioctl error :fffffffffffffdfd, c07853c3 

in int amlGetBufferFree wird die Bedingung myKernel==4 richtig erkannt. Die Ausführung des ioctl scheitert dann mit errno 25 (inappropriate ioctl for device)

Der Gegencheck mit Revision 3475e1b ergibt, dass der Fehler dort nicht auftritt.

Ich vermute das Problem in der amstream.h

alt:

#define AMSTREAM_IOC_GET_EX _IOWR((AMSTREAM_IOC_MAGIC), 0xc3, struct am_ioctl_parm_ex)

neu:

#define AMSTREAM_IOC_GET_EX       _IOWR((_A_M), 0xc3, struct am_ioctl_parm_ex)

Macht aber eigentlich keinen Unterschied

#define AMSTREAM_IOC_MAGIC 'S'

#define _A_M 'S'