jojo61 Ich habe etwas ähnliches auf meinem Radxa Zero beobachtet. Ich weiß nicht mehr, wann das aufgetaucht ist. Damals sagtest Du, dass es an meinem Empfang liegt. Mit dem SK1 habe ich das nicht. Daher ist meine Vermutung, dass es evtl. am Kernel oder einer Kombi Kernel/softhdodroid-Plugin liegt. Meine Radxa-CE-Version auf dem Radxa ist ebenfalls die ng-Version, die das Problem zeigt. Die ne-Version (SK1) zeigt das Problem nicht.
Posts by beta
-
-
Ich teste immer mit xeyes. Der X-Server framebuffer kann aber nicht mit dem s928x.
-
Eigentlich ist ein pull-Request sehr einfach. Macht einen GitHub-account und erstellt einen fork des Verzeichnisses, das ihr ändern wollt. Das geht einfach über das Web-Interface. Dann könnt ihr (ebenfalls über das Webinterface) Dateien ändern (patchen). Im Pull-Request auf CE nehmt ihr einmal das Original und einmal Euer eigenes Repo. Ihr könnt den commit-Text noch einmal separat ändern.
-
Mir ist es übrigens nicht gelungen, X11 zu starten (das startet zwar, gibt aber nichts aus). Auch mit dem Image von Khadas funktioniert das nicht...
-
Danke. Ich habe es nochmal geändert.
-
Sollte korrigiert sein - please retry....
-
Nach Rücksprache mit Portisch habe ich einen Pull-Request erstellt.
-
Nein, so:
Code
Display More#ifdef DEBUG // is device replaying? cMutex mutex; cMutexLock mutexLock(&mutex); bool control = cControl::Control(mutexLock); if (cDevice::PrimaryDevice()->Replaying() && control) { dsyslog("[softhddev]%s: replay active\n", __FUNCTION__); // FIXME: need to find PID } #endif -
jojo61 Kannst Du bitte in softhdodroid.cpp die Funktion NewPip so umschreiben
Code// is device replaying? cMutex mutex; cMutexLock mutexLock(&mutex); bool control = cControl::Control(mutexLock);Dann funktioniert das kompilieren auch wieder mit der neuen VDR-Version.
Danke,
Rudi
-
Danke sehr jojo61. Ich werde es gleich installieren und testen.
-
Danke, jojo61, ich korrigiere das und editiere die obere Datei.
-
Ich stelle hier mein neues Script zur Verfügung, das auf einer Ugoos SK1 (S928X-K mit Dolby Vision) die Installation von VDR und X11 in einer chroot-Umgebung zusammen mit CoreElec (KODI) möglich macht. Prinzipiell sollte das Script auf allen AMLOGIC-Boxen funktionieren (nur auf SK1 getestet) und ist eine Alternative zu den Files von Zabrimus mit einer kompletten Entwicklungsumgebung.
Das Script erwartet eine CE NE (getestet mit 22)-Installation entweder auf einem USB-Stick oder im internen eMMC (ceemmc -x) der SK1. Beides habe ich getestet. Andere Varianten auf anderen AMLOGIC-Boxen sollten funktionieren. Kopiert man CE auf den internen Speicher (ceemmc -x), wird das Android komplett entfernt. Man kann es aber mit Ugoos-Tools wieder aufspielen. Ich konnte einen deutlichen Geschwindigkeits-Vorteil bei der Nutzung des internen Speichers feststellen.
Was noch nicht geht:
- HEVC wird noch nicht richtig im softhdodroid dekodiert. jojo61 kennt das Problem und bekommt hoffentlich bald eine eigene SK1. Das Problem kann man aber umgehen, indem man im VDR den vnsi-Server startet und den als TV-Frontend im KODI auswählt. KODI kann das dekodieren. H264 und SD funktionieren einwandfrei.
Ich habe auf die UBUNTU-Distribution auf 22.04 upgedated. Die Paketliste installiert alles, was ich so brauche (als Payload am Ende des Scripts). Wem die zu umfangreich ist, kann sie gerne kürzen.
Bitte das angehängte Script auf die Box unter /storage kopieren, in install.sh umbenennen und ausführbar machen (chmod 775 install.sh). Das Script checkt erst, ob alle benötigten Dateien im Internet vorhanden sind, bevor es seine Arbeit startet. Es läuft relativ lange (eine knappe Stunde je nach Stick-Geschwindigkeit). Auf einigen Systemen fehlt dann noch ein systemctl mask kodi (bitte händisch eingeben) und die Box neu starten. Danach wird in den VDR gebootet und man kann mit externalplayer oder per commands.conf nach KODI wechseln. In KODI gibt es beim Ausschalten dann einen neuen Menüpunkt "Verlassen", der wieder in den VDR bootet.
Ab hier kann jeder selbst Erweiterungen/Änderungen machen. Bitte beachtet, dass alles als root läuft und sichert wichtige Daten vorher oder benutzt einen leeren Stick. Tipp: Der Reset-Knopf bei der Ugoos-SK1 versteckt sich in der Audio-Klinkenbuchse und ist mit einem Zahnstocher gut zu erreichen. Ich werde das Script in den nächsten Tagen auch noch auf mein Github packen (https://github.com/beta68).
Nachtrag: Die chroot-Umgebung kann nach dem Einloggen in CE durch ./bash.sh gestartet werden.
Viel Spaß beim Testen!
-
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.
-
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.
-
close handle failed PIP 0 Ungültiger Dateideskriptor
-
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?
-
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.
-
jojo61 Ich denke, die Programmierung ist nicht Threadsafe, daher gibt es race-conditions. Hier der neue BT:
close handle failed PIP 0
Thread 32 "device 1 receiv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fe9c4f0a0 (LWP 4284)]
0x0000007ff53c4b54 in InternalClose (pip=0) at video.c:2982
2982 OdroidDecoders[pip]->handle = -1;
(gdb) bt
#0 0x0000007ff53c4b54 in InternalClose (pip=0) at video.c:2982
#1 InternalClose (pip=<optimized out>) at video.c:2950
#2 0x0000007ff53c4f94 in amlReset () at video.c:2944
#3 amlReset () at video.c:2927
#4 0x0000007ff53c8128 in VideoPollInput (stream=0x7ff739c790 <MyVideoStream>) at softhddev.c:1839
#5 0x0000007ff53c2efc in OdroidDisplayHandlerThread () at video.c:1459
#6 0x0000007ff53c2f90 in VideoDisplayHandlerThread (dummy=<optimized out>) at video.c:1492
#7 0x0000007ff79cd5c8 in start_thread (arg=0x0) at ./nptl/pthread_create.c:442
#8 0x0000007ff7a35edc in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
Es crasht immer noch an derselben Stelle, weil der OdroidDecoders-Pointer Null ist. Wahrscheinlich müsstest Du die einzelnen Threads locken und erst nacheinander freigeben oder die Pointer auf 0x0 abfragen, bevor Du das handle setzt. Das ist aber nicht die einzige Stelle, bei der das Problem auftritt.
-
jojo61: Ich habe eine quick&dirty-Lösung.
Ich habe mir Absturz für Absturz vorgenommen und dabei erst einmal pip auskommentiert, wo es gestört hat.
Einige Variablen waren nicht static und könnten sich damit prinzipiell im Kontext ändern. Die habe ich static gemacht. Dann gab es einige Pointer, die NULL (0x0) waren (warum auch immer, jojo61 , das müsstest Du mal schauen). Den sleep(1) konnte ich komplett entfernen, ohne dass es weitere Probleme gibt, DETA ist damit deutlich schneller geworden. Die geänderte video.c hänge ich unten an. Vielleicht hilft es Dir ja, Jojo, wenn Du morgen suchst. Ich habe VDR mit softhdodroid dann im Debugger laufen lassen und in einer anderen shell mit einer for-Schleife DETA/ATTA gemacht, ohne dass jetzt irgendetwas crasht.
Ich durchblicke die PIP-Struktur noch nicht so ganz, aber hoffe, dass die Datei hilft. Vielleicht erklärt das ja auch die Probleme mit externalplayer/Wechsel zu KODI per commands.conf, die einige hier hatten.
LG,
Rudi
-
Was soll das bringen? Ich habe es trotzdem gemacht und es crashed genau so.