Danke, jojo61, ich korrigiere das und editiere die obere Datei.
Beiträge von beta
-
-
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.
-
Kann man das PIP irgendwie einfach deaktivieren? Wenn ich aus
void InternalClose(int pip)
direkt mit einem return; rausgehe, crashed nichts mehr (allerdings habe ich dann auch kein Bild mehr beim ATTA und den Hinweis
AmlCodec open failed.
-
Mit einem sleep von 2 wird es besser. Es geht dann 5 mal gut, und dann verabschiedet sich das Plugin so:
close handle failed PIP 0
Thread 42 "device 1 receiv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fe943f0a0 (LWP 11485)]
0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
2984 OdroidDecoders[pip]->handle = -1;
(gdb) bt
#0 0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
#1 InternalClose (pip=<optimized out>) at video.c:2952
#2 0x0000007ff53c4120 in amlReset () at video.c:2946
#3 amlReset () at video.c:2929
#4 0x0000007ff53c72c8 in VideoPollInput (stream=0x7ff739b780 <MyVideoStream>) at softhddev.c:1839
#5 0x0000007ff53c2010 in OdroidDisplayHandlerThread () at video.c:1461
#6 0x0000007ff53c20a0 in VideoDisplayHandlerThread (dummy=<optimized out>) at video.c:1494
#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
Den Text habe ich nicht im Log und ich teste nur VDR mit softhdodroid (keine anderen Plugins) und DETA/ATTA vom Terminal aus (Ugoos SK1, Kernel 5.4).
-
Leider hilft das nicht. Beim ersten DETA geht es noch gut. Nach einem ATTA kommt kein Bild und nach einem weiteren DETA das:
.Internal Close pip 0 mit Handle -1
[Thread 0x7fc51490a0 (LWP 8670) exited]
[Thread 0x7fad7af0a0 (LWP 8669) exited]
[New Thread 0x7fad7af0a0 (LWP 8690)]
[New Thread 0x7fc51490a0 (LWP 8691)]
[New Thread 0x7fe9c4f0a0 (LWP 8693)]
[Thread 0x7fc51490a0 (LWP 8691) exited]
[Thread 0x7fad7af0a0 (LWP 8690) exited]
[New Thread 0x7fad7af0a0 (LWP 8697)]
[New Thread 0x7fc51490a0 (LWP 8698)]
[Thread 0x7fe9c4f0a0 (LWP 8693) exited]
[Thread 0x7feac6f0a0 (LWP 8673) exited]
[Thread 0x7fb6ffe0a0 (LWP 8672) exited]
close handle failed PIP 0
[Thread 0x7fc51490a0 (LWP 8698) exited]
[Thread 0x7fad7af0a0 (LWP 8697) exited]
Thread 27 "device 1 receiv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fea45f0a0 (LWP 8674)]
0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
2984 OdroidDecoders[pip]->handle = -1;
(gdb) bt
#0 0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
#1 InternalClose (pip=<optimized out>) at video.c:2952
#2 0x0000007ff53c4120 in amlReset () at video.c:2946
#3 amlReset () at video.c:2929
#4 0x0000007ff53c72c8 in VideoPollInput (stream=0x7ff739b780 <MyVideoStream>) at softhddev.c:1839
#5 0x0000007ff53c2010 in OdroidDisplayHandlerThread () at video.c:1461
#6 0x0000007ff53c20a0 in VideoDisplayHandlerThread (dummy=<optimized out>) at video.c:1494
#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
-
jojo61 Ich erhalte leider häufige crashes beim DETA des Plugins:
Thread 27 "device 1 receiv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fea45f0a0 (LWP 1872)]
0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
2984 OdroidDecoders[pip]->handle = -1;
Mit dem BT:
Thread 27 "device 1 receiv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fea45f0a0 (LWP 1872)]
0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
2984 OdroidDecoders[pip]->handle = -1;
(gdb) bt
#0 0x0000007ff53c3978 in InternalClose (pip=0) at video.c:2984
#1 InternalClose (pip=<optimized out>) at video.c:2952
#2 0x0000007ff53c4130 in amlReset () at video.c:2946
#3 amlReset () at video.c:2929
#4 0x0000007ff53c72d8 in VideoPollInput (stream=0x7ff739b780 <MyVideoStream>) at softhddev.c:1839
#5 0x0000007ff53c2010 in OdroidDisplayHandlerThread () at video.c:1461
#6 0x0000007ff53c20a0 in VideoDisplayHandlerThread (dummy=<optimized out>) at video.c:1494
#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
Wenn ich das dann auskommentiere, crashed es an einer anderen Stelle. Kann es sein, dass es hier ein Problem mit PIP gibt und kann ich das prinzipiell ausschalten?
-
jojo61 Es tut mir leid, wenn ich wieder Wasser in den Wein gießen muss. Aber mit den letzten beiden Commits ist das Plugin unter meiner SK1 nicht mehr benutzbar. Es gibt ein ruckelndes Bild, so, als liege der TV auf 60 Hz. Ich bin wieder auf 16adc5385e475d90720bdcda1a4bf92e9910a0af und alles ist OK.
-
jojo61 Wenn hier einer Danke sagen muss, dann ja wohl ich. Jojo, Du hast Dir Zeit genommen und versucht, das Ganze auf meinem Rechner zu debuggen und dafür sage ich Dir herzlich Danke! Wenn Du mal in der Düsseldorfer Gegend bist, melde Dich und ich gebe einen aus
-
Das mache ich sehr gerne. Ich schreibe Dir eine PM.
-
jojo61 Ja, das ist ein HDR-fähiger TV, der auch Dolby-Vision kann. HDR2SDR steht auf no. SES UHD Demo macht kein Bild und keinen Ton, bei QVC UHD bleibt das Bild des letzten Senders stehen und es kommt nur Ton.
Unter KODI kommen Bild und Ton (VNSI Server VDR -> CE). Es ändert auch nichts, wenn der HDR2SDR auf yes steht.
-
Das Problem hängt ja nicht vom Prozessor ab. CE 5.4 läuft ja auch auf dem N2.Edit: Ich sehe gerade, dass ich Mist erzählt habe. Es gibt nur die NO (5.15) oder die NG. Die NE-Version läuft nicht auf dem N2.
-
jojo61 Ich habe von Ugoos ein SK1-Sample (S928X) erhalten. CE 22 NE (Kernel 5.4) läuft darauf ganz gut mit Dolby-Vision. Ich habe meine chroot-Umgebung so angepasst, dass da inzwischen ein UBUNTU 22.04 läuft und verwende zur Ausgabe ebenfalls Dein Plugin. Sobald alles richtig läuft, werde ich das Installations-Skript auf mein Github legen. Das sollte dann auch mit anderen Amlogic-Boxen laufen.
Allerdings habe ich bei UHD-Sendern unter Kernel 5.4 (CE) in der chroot-Umgebung kein Bild. Wenn ich KODI das ganze darstellen lasse (VNSI-Server), funktioniert die Ausgabe mit Bild und Ton. Teilweise habe ich mit Deinem Plugin auch nur Ton, aber kein Bild (QVC UHD). Hast Du eine Ahnung, woran das liegen könnte? Ich würde ungerne auf den 5.15-Kernel wechseln, weil ich dann Dolby-Vision verliere. Auf meinem Odroid N2+ (S922X) mit CE NO (Kernel 5.15) läuft es ohne Probleme...