VDR auf RPI3 mit Raspbian stürzt ab. Wie Fehler suchen?

Asta · 20. November 2016

Hallo liebe Leute. Seit kurzem stürzt mein VDR ohne Meldung im Log einfach ab und startet neu:

Code

Nov 20 12:50:05 raspiwz vdr: [softhddev] empty video packet 115 bytes
Nov 20 12:55:09 raspiwz vdr: [softhddev] empty video packet 123 bytes
Nov 20 12:58:32 raspiwz vdr: [5694] epg data writer thread started (pid=5589, tid=5694, prio=low)
Nov 20 12:58:32 raspiwz rsyslogd-2007: action 'action 17' suspended, next retry is Sun Nov 20 12:59:32 2016 [try http://www.rsyslog.com/e/2007 ]
Nov 20 12:58:33 raspiwz vdr: [5694] epg data writer thread ended (pid=5589, tid=5694)
Nov 20 12:59:03 raspiwz vdr: [5701] VDR version 2.2.0 started

Plugins:

Code

Nov 20 12:13:53 raspiwz vdr: [5042] loading plugin: /usr/local/lib/vdr/libvdr-softhddevice.so.2.2.0
Nov 20 12:13:53 raspiwz vdr: [5042] loading plugin: /usr/local/lib/vdr/libvdr-skinenigmang.so.2.2.0
Nov 20 12:13:53 raspiwz vdr: [5042] loading plugin: /usr/local/lib/vdr/libvdr-extrecmenu.so.2.2.0
Nov 20 12:13:53 raspiwz vdr: [5042] loading plugin: /usr/local/lib/vdr/libvdr-epgsearch.so.2.2.0
Nov 20 12:13:53 raspiwz vdr: [5042] loading plugin: /usr/local/lib/vdr/libvdr-live.so.2.2.0

Wie kann ich am besten vorgehen um den Fehler zu finden??

Code

uname -a
Linux raspiwz 4.4.32-v7+ #926 SMP Fri Nov 18 13:40:49 GMT 2016 armv7l GNU/Linux

seahawk1986 · 20. November 2016

Das dürfte die softhddevice-Version mit mmal-Unterstützung von zille sein, oder? Hast du da schon den aktuellsten Git-Stand davon gebaut (idealerweise genau wie den VDR mit Debug-Symbolen) und alle Firmware-Updates für den Raspberry eingespielt?

Dann kannst du dir gdb installieren, den VDR damit starten und nachsehen, wo es kracht.

Asta · 20. November 2016

Hey Danke für die schnelle Antwort. Das SHD ist die letzte Version aus dem Git. Den RPI und habe ich mit apt-get update und apt-get dist-upgrade sowie rpi-update auf den neuesten Stand gebracht. Ich schaue mal wie ich das SHD geschwätziger machen kann. Hat du vielleicht eine kurze Anleitung was ich machen muß um den VDR zu debuggen?

seahawk1986 · 20. November 2016

Wenn man den VDR auf die ARGSDIR-Konfiguration umgestellt hat, ist das einfach, da man dann den Rattenschwanz an Start-Argumenten nicht mehr benötigt (sonst muss man mit gbd --args vdr -Psofthddevice ... arbeiten):

Code

ulimit -c
gdb -ex=run vdr

Wenn es dann gekracht hat, kann man sich mit "bt full" anzeigen lassen, was der VDR zuletzt vor dem Crash gemacht hat - dann hat man schon mal eine ungefähre Idee, an welcher Stelle es hängen könnte.

Asta · 20. November 2016

OK. Ich habe jetzt mal mit gdb gestartet.

Code

gdb -ex=run --args vdr -P "softhddevice -a iec958:AES0=0x4,CARD=0 -p iec958:AES0=0x6,CARD=0 -v mmal -w use-possible-defect-frames" -P skinenigmang -P extrecmenu -P epgsearch

Nun bekomme ich öfter mal abstürze beim Umschalten:

Code

(gdb) bt full
#0  MmalDisplayFrame () at video.c:10265
        buffer = 0x0
        decoder = 0x2c9260
        diff = <optimized out>
        rbuffer = <optimized out>
        status = <optimized out>
        frame = 0x0
        data = 0x2a6dc0
        video_clock = <optimized out>
        audio_clock = <optimized out>
#1  vsync_callback (update=<optimized out>, arg=<optimized out>) at video.c:9691
        data = 0x2a6dc0
#2  0x76670bac in dispmanx_notify_func () from /opt/vc/lib/libbcm_host.so
No symbol table info available.
#3  0x7664acc4 in vcos_thread_entry (arg=0x766878a0 <dispmanx_notify_task>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
        ret = <optimized out>
        thread = 0x766878a0 <dispmanx_notify_task>
#4  0x76f36e90 in start_thread (arg=0x716ff450) at pthread_create.c:311
        pd = 0x716ff450
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1903162552, 1, 2130702740, 338, 1986558112, 1996440768, 0, 1903161228, -1823784947, -1797799875,
                0 <repeats 54 times>}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
---Type <return> to continue, or q <return> to quit---
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x76c24598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
No locals.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Alles anzeigen

Komisch ist nur das es eigentlich ohne GDB nie zu abstürzen beim Umschalten kommt sondern eigentlich wenn man nix tut und einfach einen Film schaut und keine Taste anfässt. Auch nicht so häufig.
Leider kann ich rpihddevice wegen Audio Drops nicht nutzen.

Asta · 20. November 2016

Jetzt ist er mitten im Betrieb abgestürzt:

Code

bt full
#0  MmalDisplayFrame () at video.c:10265
        buffer = 0x0
        decoder = 0x2c9240
        diff = <optimized out>
        rbuffer = <optimized out>
        status = <optimized out>
        frame = 0x0
        data = 0x2a6dc0
        video_clock = <optimized out>
        audio_clock = <optimized out>
#1  vsync_callback (update=<optimized out>, arg=<optimized out>) at video.c:9691
        data = 0x2a6dc0
#2  0x7666ebac in dispmanx_notify_func () from /opt/vc/lib/libbcm_host.so
No symbol table info available.
#3  0x76648cc4 in vcos_thread_entry (arg=0x766858a0 <dispmanx_notify_task>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
        ret = <optimized out>
        thread = 0x766858a0 <dispmanx_notify_task>
#4  0x76f35e90 in start_thread (arg=0x716ff450) at pthread_create.c:311
        pd = 0x716ff450
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1903162552, 1, 2130702740, 338, 1986549920, 1996440768, 0, 1903161228, -938078857, -812991161,
                0 <repeats 54 times>}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x76c23598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6

Alles anzeigen

Kann ich also davon ausgehen das es am SHD liegt??

seahawk1986 · 20. November 2016

Das wäre eine Arbeitshypothese - welches Signal kommt denn beim Crash vom VDR? Ist das ein Segfault (SIGSEV) oder etwas anderes?

Eventuell wird das durch höhere Last bzw. steigende Latenzen begünstigt, wenn das mit gdb schneller auftritt - hast du mal über mehrere Crashes hinweg geschaut, ob es da Auffälligkeiten (I/O beim schreiben der epg.data, CPU-Last beim Suchtimerupdate durch epgsearch usw.) zeitnah vor dem Crash gab?

Asta · 20. November 2016

Im Moment des Absturzes schalte ich den Sender um:

Code

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7167e450 (LWP 1793)]
MmalDisplayFrame () at video.c:10265
10265           frame = (AVFrame *)buffer->user_data;

CPU Last mit Htop unter 5% bei allen Kernen.
Kein EPG schreiben aktiv.

zillerbaer · 20. November 2016

Hallo Asta,

der Pointer buffer ist NULL. Es sind keine decodierten bzw. deinterlaceten Bilder in der Queue. (Das sollte ich eigentlich abfangen!) Wie ist die Empfangssituation? Passiert das bei Aufnahmen oder und live? Kommt es vor dem Absturz zu Bildrucklern?

Gruss zille

Edit: Bitte teste mal die neue git Version und schau ob die verlorenen Frames hochzählen.
Edit2: Welche FFmpeg Version benutzt Du?

Asta · 21. November 2016

Hallo Zille. Der Absturz kommt unregelmäßig. Entweder beim umschalten oder im laufendem Programm. Cpu Last normal. Kein Wechsel von Sendung zur Werbung oder umgekehrt. Kein Format- oder Audio wechsel.

Code

ffmpeg version N-81723-g6d9a46e Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.9.2 (Raspbian 4.9.2-10)
  configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib --docdir=/usr/share/doc/ffmpeg-9999/html --mandir=/usr/share/man --enable-shared --enable-omx-rpi --enable-mmal
  libavutil      55. 30.100 / 55. 30.100
  libavcodec     57. 57.101 / 57. 57.101
  libavformat    57. 50.100 / 57. 50.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 62.100 /  6. 62.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100

zillerbaer · 21. November 2016

Hallo Asta,

ffmpeg kann wohl ausgeschlossen werden. Das aktuelle git habe ich eben getestet. Dabei habe ich festgestellt das ffmpeg-3.2 meinen Patch enthält und gut funktioniert. Kommen wir zurück zum Problem. Der buffer Pointer ist NULL. Wie ist die Empfangssituation? Können Aufnahmen abgespielt werden die auf anderer VDR Hardware funktioniert? Werden mit meinem aktuellem git Stand verlorene Frames hochzählt?

Ich habe hier noch ein 4.1er Kernel mit älterer Firmware. Das werde ich in den nächsten Tagen mal auf neuesten Stand bringen und testen.

Gruss zille

Asta · 22. November 2016

Hallo Zille.

Zitat

Können Aufnahmen abgespielt werden die auf anderer VDR Hardware funktioniert?

Ja, der VDR ist komplett funktionstüchtig. Es gibt keine Einschränkungen. Alle Aufnahmen können abgespielt werden. Menü funktioniert, u.s.w.
Die Abstürze kommen sporadisch.

Zitat

Wie ist die Empfangssituation?

Ich habe keine Anzeige für Pegel. ich werde Femon nachinstallieren. (Aber, rpihddevice läuft ohne Probleme - außer Audiodrops: Audiodrops über HDMI mit rpihddevice)

Zitat

Werden mit meinem aktuellem git Stand verlorene Frames hochzählt?

Wo kann ich das sehen? Mein syslog ist still im Moment des Absturzes.

Viele Grüße
Andy

PS: noch ne Frage: Um das SHD zu kompilieren muß ich immer folgende Sachen deinstallieren: "libavcodec-dev libavformat-dev libavutil-dev libavresample-dev libavresample2", sonst kompiliert das SHD nicht.

Gerade nochmal getestet. Direkt beim umschalten. Das Bild des neuen Senders ist noch nicht da:

Code

gdb -ex=run --args vdr -P "softhddevice -a hw:0,0 -c Master -v mmal" -P skinenigmang -P extrecmenu -P epgsearch

Code

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x71827450 (LWP 1194)]
MmalDisplayFrame () at video.c:10265
10265           frame = (AVFrame *)buffer->user_data;
(gdb) bt full
#0  MmalDisplayFrame () at video.c:10265
        buffer = 0x0
        decoder = 0x2a42d0
        diff = <optimized out>
        rbuffer = <optimized out>
        status = <optimized out>
        frame = 0x0
        data = 0x2bed70
        video_clock = <optimized out>
        audio_clock = <optimized out>
#1  vsync_callback (update=<optimized out>, arg=<optimized out>)
    at video.c:9691
        data = 0x2bed70
#2  0x7666ebac in dispmanx_notify_func () from /opt/vc/lib/libbcm_host.so
No symbol table info available.
#3  0x76648cc4 in vcos_thread_entry (arg=0x766858a0 <dispmanx_notify_task>)
    at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads                                                                                        .c:144
        ret = <optimized out>
        thread = 0x766858a0 <dispmanx_notify_task>
#4  0x76f35e90 in start_thread (arg=0x71827450) at pthread_create.c:311
        pd = 0x71827450
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1904374968, 1, 2130702804,
---Type <return> to continue, or q <return> to quit---
                338, 1986549920, 1996440768, 0, 1904373644, 2051413005,
                2100765757, 0 <repeats 54 times>}, mask_was_saved = 0}},
          priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0,
              cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x76c23598 in ?? ()
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92
   from /lib/arm-linux-gnueabihf/libc.so.6
No locals.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Alles anzeigen

zillerbaer · 22. November 2016

Hallo Asta,

Zitat von Asta

Wo kann ich das sehen?

Im Haupmenu auf SoftHdDevice gehen. Da steht Statistik Zeugs drin.

Zitat von Asta

PS: noch ne Frage: Um das SHD zu kompilieren muß ich immer folgende Sachen deinstallieren: "libavcodec-dev libavformat-dev libavutil-dev libavresample-dev libavresample2", sonst kompiliert das SHD nicht.

Das sind die header Dateien von FFmpeg. Die werden beim Kompilieren gebraucht. Hast Du mehrere Versionen von FFmpeg installiert? Aus welcher Quelle stammt FFmpeg?

Passiert das bei einem bestimmten Sender, bei HD, SD, interlaced Sendern o.ä. oder ist das egal? Ich kann das Problem hier auf einem RPi2 nicht nachvollziehen. Es läuft täglich 1-2 Stunden und wird mit streamdev beliefert.

Im git habe ich einen Patch eingepflegt der einen Null buffer abfängt. Teste das mal bitte.

Gruss Zille

Asta · 23. November 2016

Hallo Zille. Neue Git Version und FFmpeg auch noch mal neu aus Git installiert.
Menüeintrag nach wilden hin und herzappen:

Code

Frames verloren(20) verdoppelt(397) übersprungen(15) Gesamt(11557)

Dann jedoch:

Code

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x70e27450 (LWP 16485)]
MmalDisplayFrame () at video.c:10265
10265           frame = (AVFrame *)buffer->user_data;
(gdb) bt full
#0  MmalDisplayFrame () at video.c:10265
        buffer = 0x0
        decoder = 0x2c6ec0
        diff = <optimized out>
        rbuffer = <optimized out>
        status = <optimized out>
        frame = 0x0
        data = 0x2a4978
        video_clock = <optimized out>
        audio_clock = <optimized out>
#1  vsync_callback (update=<optimized out>, arg=<optimized out>) at video.c:9691
        data = 0x2a4978
#2  0x76670bac in dispmanx_notify_func () from /opt/vc/lib/libbcm_host.so
No symbol table info available.
#3  0x7664acc4 in vcos_thread_entry (arg=0x766878a0 <dispmanx_notify_task>) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
        ret = <optimized out>
        thread = 0x766878a0 <dispmanx_notify_task>
#4  0x76f36e90 in start_thread (arg=0x70e27450) at pthread_create.c:311
        pd = 0x70e27450
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1893889208, 1, 2130702740, 338, 1986558112, 1996440768, 0, 1893887884, -1133503216, -1168040672,
                0 <repeats 54 times>}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x76c24598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
No locals.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Alles anzeigen

Zitat

Hast Du mehrere Versionen von FFmpeg installiert?

Nein.

Zitat

Aus welcher Quelle stammt FFmpeg?

Code

git clone https://github.com/FFmpeg/FFmpeg

Zitat

Passiert das bei einem bestimmten Sender, bei HD, SD, interlaced Sendern o.ä. oder ist das egal?

Ist völlig egal. Ich glaube das es angefangen hat nachdem ich vor ca. 14Tagen den RPI auf den neuesten Stand gebracht habe. Mit apt-get update und apt-get dist-upgrade und rpi-update. Danach müssen die Abstürze angefangen haben.

Asta · 23. November 2016

Kannst du deinen PI auch mal so starten:

Code

gdb -ex=run --args vdr -P "softhddevice -a iec958:AES0=0x4,CARD=0 -p iec958:AES0=0x6,CARD=0 -v mmal -w use-possible-defect-frames"

und dann wild zappen?
Über die runvdr gestartet läuft er jetzt schon über 1Stunde ohne Absturz.

PS: Sag mal Zille, gibt es irgendwie die Möglichkeit die Bildschärfe und den Deinterlacer im SHD einzustellen?

zillerbaer · 24. November 2016

Hallo Asta,

hab mir gestern ein Raspbian aufgesetzt und getestet. Auch heute läuft es jetzt seit 3 Stunden. Mehrmals die Senderliste rauf und runter brachte es nicht aus dem Tritt. Laut Deiner Signatur hast Du auch ein RPi2. Gibt es da auch Probleme? Ich kann das auf einem RPi2 nicht nachvollziehen. Ein 3er hab ich leider nicht. Wieviel gpu_mem gibst Du?

Zitat von Asta

PS: Sag mal Zille, gibt es irgendwie die Möglichkeit die Bildschärfe und den Deinterlacer im SHD einzustellen?

Im SHD gibt es diese Möglichkeit nicht. Das Bild kann am TV angepasst werden. Als Deinterlacer ist der Advanced fest eingestellt.

Gruss zille

Edit: Auch wenn ich den Netzwerkstecker ziehe wird das letzte Bild angezeigt. Kein Absturz.

Asta · 25. November 2016

Ich habe gerade meine Karte in den RPI2 gesteckt und auch dort die Abstürze. Wenn es bei dir Tatsache auch mit gdb durchläuft werde ich wohl irgendeneinen Mist mit meiner Installation haben. Ich werde mal schauen ob ich noch ne andere sd Karte habe und mal neu installieren.

Asta · 25. November 2016

Ich habe jetzt auf einer frischen SD-Karte komplett neu installiert.: Raspbian Jessie lite, VDR-2.2.0, Softhddevice aus dem GIT. mehr nicht.
Karte im RPI3 und im RPI2. Bei beiden kommen beim Zappen die besagten Abstürze..
Ich muß dich nochmal fragen Zille: Startest du auch mal mit gdb? Starte ich es ohne gdb, also mit der runvdr, läuft der pi auch manchmal 3-10h bis zum ersten Absturz ohne Probleme.
Mit gdb dauert es meistens nur ein paar Minuten.

zillerbaer · 26. November 2016

Hallo Asta,

ob mit oder ohne debugger macht hier keinen Unterschied. Im git steht eine neue Version. Sollte der pointer buffer NULL sein wird eine Meldung ins syslog geschrieben und die Verarbeitung des buffers unterbrochen. So meine Vermutung richtig ist sollte es keine segfaults mehr geben. Teste das mal bitte und wenn Meldungen im syslog auftauchen poste die hier.

Gruss zille

PS: Jetzt wird der Zap-Daumen gekühlt.

Asta · 26. November 2016

Danke Zille das du dir so eine Arbeit machst. Ich kann mir auch nicht erklären wieso das bei dir nicht auftritt.

Zitat

Teste das mal bitte und wenn Meldungen im syslog auftauchen poste die hier.

Wie sieht denn der syslog Eintrag in etwa aus? So:

Code

[Nov 26 17:24:23 raspiwz vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'

?

VDR auf RPI3 mit Raspbian stürzt ab. Wie Fehler suchen?

Jetzt mitmachen!

Teilen