Posts by beta

    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

    video.c.zip

    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 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...

    Die Kernel-Meldungen, die ich beim Bildhänger habe, sind (jetzt auch beim 5-Kernel):

    Jul 25 22:50:35 CoreELEC kernel: 0: vh264_set_params active_buf_spec_num 11 dec_dpb_size 5 collocate_buf_num 8

    Jul 25 22:50:35 CoreELEC kernel: 0: num_ref_frames change from 0 to 4

    Jul 25 22:57:35 CoreELEC kernel: 0: bufmgr_h264_remove_unused_frame, unmark error frame

    Jul 25 22:57:35 CoreELEC kernel: 0: bufmgr_h264_remove_unused_frame, unmark error frame

    Jul 25 22:57:35 CoreELEC kernel: 0: error 50 B frame, reset dpb buffer

    Jul 25 22:57:35 CoreELEC kernel: 0: config_decode_buf fail (-1)

    Jul 25 22:57:35 CoreELEC kernel: 0: h264_reset_bufmgr frame count 16009 to skip 0

    Jul 25 22:57:35 CoreELEC kernel: H264 sysinfo: 0x0 duration=3840, pts_outside=0

    Jul 25 22:57:35 CoreELEC kernel: sync_outside=1, use_idr_framerate=0, is_used_v4l: 0

    Jul 25 22:57:35 CoreELEC kernel: 0: AV_SCRATCH_1 = 41fe078, AV_SCRATCH_2 12053, AV_SCRATCH_B: = 428

    Jul 25 22:57:35 CoreELEC kernel: 0: chroma_format_idc = 1 frame_mbs_only_flag 0, crop_bottom 8, frame_height 1080,

    Jul 25 22:57:35 CoreELEC kernel: 0: mb_height 68,crop_right 0, frame_width 1920, mb_width 120

    Jul 25 22:57:35 CoreELEC kernel: 0: mb height/widht/total: 44/78/1fe0 level_idc 28 max_ref_num 4

    Jul 25 22:57:35 CoreELEC kernel: 0: restriction_flag=0, max_dec_frame_buffering=0, dec_dpb_size=5 num_reorder_frames 0 used_reorder_dpb_size_margin 6

    Ich kann die Beobachtung von Dr. Seltsam bestätigen. Bei mir tritt das Problem mit dem stockenden Bild nur bei verschl* Sendern auf. Extrem ist es bei derzeit Discovery HD. Der sendet auch in DD AC3. Komischerweise ist das aber nur bei 4-Kernel der Fall, nicht mehr beim 5-Kernel.

    Fairerweise muss ich aber auch sagen, dass ich dieselben Aussetzer auch unter CE habe, wenn ich das vnsi-Plugin benutze (auch nur unter Kernel 4, nicht unter Kernel 5). Ich dachte schon, dass es ein interlaced/progressive Problem ist, aber soweit ich weiß, ist DVB-T2 progressive?