[gelöst] rpihddevice - Absturz nach Beenden des Abspielens einer Aufzeichnung

  • Auf meinem RPI3 + MLD5.1 testing + skindesigner/estuary4vdr kommt es reproduzierbar zum Absturz des VDRs, wenn ich das Abspielen einer Aufzeichnung mit Stop/Back/ESC Taste beende. Nach Beenden des Abspielens wird kein Livebild mehr angezeigt, der Watchdog des VDRs springt an und startet den VDR neu. User aus dem MLD Forum berichten, dass der Fehler auch auf einem plain vanilla VDR mit LCARS Skin reproduzierbar ist und zwar nur auf dem RPI3. Steckt man die SD-Karte mit dem gleichen System in einen RPI2 funktioniert es einwandfrei ohne Absturz!


    Kann das wer bestätigen? Mit dem Problem bin ich scheints nicht alleine...

    The post was edited 1 time, last by iNOB ().

  • Hi,


    ich habe noch ein paar Anmerkungen bzw. Korrekturen.
    - getestet wurde nicht mit einem Vanilla VDR, jedoch mit einem VDR mit nur den nötigsten Plugins, der beim RPI2 bei vielen Usern ohne Probleme läuft.
    - der Fehler tritt wohl reproduzierbar immer dann auf, wenn bei der Wiedergabe gespult wurde (fast forward, fast rewind).
    - es wurde von mindestens zwei Usern gegen getestet das der Fehler mit der Selben SD-Karte in einem RPI2 nicht auftritt.


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • Mahlzeit,


    habe ein Raspberry Pi 3 mit MLD 5.1 testing laufen.
    Gleiches Verhalten hier.


    Munter bleiben, Rossi

  • 3 x RPi 3, alle unter MLD 5.1, gleiches Verhalten.
    Beim markieren der Schnittpunkte springe ich mit den Farbtasten in den Aufzeichnungen rum (Grün und Gelb),
    dabei passiert es eigentlich immer. Nach spätestens den 3. Sprung friert das Bild ein und der Watchdog schlägt zu.
    Vielleicht hängt das ja zusammen.
    Einen Fehler im Log konnte ich bis jetzt noch nicht ausmachen, weder am Server noch am Client.


    Gozar

    No Brain => No Pain
    ---
    VDR Server:
    HP ML110, Xeon 2,4Ghz, 3x2TB im RAID5, 1x2TB für video0, MLD Server, 2 x Satix Mystique DVB-S2 Dual, 1 DVB-T für ORF
    VDR Clients:
    3 x RPi 3 Client MLD Ver. 5.1
    1 x RPi 2 Client MLD Ver. 5.1

  • Hallo zusammen,


    gleiches bei mir.

    Clients
    VDR1: yaVDR 0.5 stable auf ZOTAC ION A 4Gbyte RAM / mit ATRIC - IR - Einschalter softhddevice per streamdev am Server
    VDR2 / VDR3: MLD 5.1 auf Raspberry pi3
    2 x VOMP 0.4 auf mediamvp
    Server
    Cubietruck, Lubuntu Trusty, vdr aus yaVDR - sourcen, 1 x TT S2-3600, 1 x TT S2-3650 CI, 1 x sundtek SkyTV III, 1 x sundtek SkyTV IV

  • Ich kann das derzeit auf meine RPI3 nicht testen, aber reufer hat nach einem coredump gefragt, das erleichtert schon viel Arbeit (für die die daraus was lesen können, ich bin nicht ein davon)..

  • Hallo zusammen,


    zumindest bei mir gibt es keinen Segfault vom VDR. Nur der Watchdog schlägt zu. Mit dem gdb, wie im MLD-Wiki beschrieben, hatte ich keinen Erfolg. Wenn es noch eine andere Möglichkeit gibt, einen Speicherabzug zu erstelllen, bitte ich um eine kleine Anleitung.


    Viele Grüße skippy

  • skippy : wenn der VDR in einem Deadlock oder in einer Endlosschleife hängt, musst du ihn (bevor der Watchdog zuschlägt) mit


    Code
    1. killall -SIGSEGV vdr


    abschießen...dann sollte ein Coredump erstellt werden.


    Ciao Louis

  • Guten Morgen,


    Mein erster Coredump, hoffe ich habs richtig gemacht (gem. MLD Wiki).
    RPi3 Client; Hängt an Octopus Net DVB-C über SatIP-Plugin; Aufnahmen liegen auf einem Server; Aufnahme gestartet und ein paar mal wild mit grün und gelb gesprungen und gespult;mit Exit die Aufnahme verlassen; kein Bild mehr;killall -SIGSEGV vdr;



    Hoffe es hilft.

  • Ja, die Firmware sollte bei den Usern, die alles aktuell haben, vom 12.10. sein.
    Ich habe aber gerade eben noch mal die neuste Firmware bereit gestellt. Das sollte aber keinen Unterschied machen, da der genannte Firmware Fehler ja schon lange behoben ist.


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • louis : Vielen Dank, für die Info - wollte jetzt gerade anfangen, aber ist ja nun nicht mehr notwendig. Ich werde den Wiki-Eintrag entsprechend ergänzen.


    megalutschi : Schön, dass du schneller warst und es Thomas geholfen hast - danke!


    Thomas :

    Code
    1. MLD-RPi3-Ampi> uname -a
    2. Linux MLD-RPi3-Ampi 4.1.21.197.1 #1 SMP Wed Oct 26 09:26:30 CEST 2016 armv7l GNU/Linux


    und aus den Systeminformationen: rpi-firmware 2016.10.12-2


    Viele Grüße skippy

  • Hi,


    der Claus war anscheinend schon wieder fix tätig . In den Paketen gibt es jetzt 2016.10.29-2.


    Gruß

    MLD 5.1 - Server - testing - ASROCK Q1900m - SSD 128 GB - HDD 4TB - Max S8
    MLD 5.1 -SZ - testing - SatIp-Client - Raspi 3
    MLD 5.1 -WZ - testing - SatIp-Client-Squeezplayer 7" RPI-Display - Raspi 3
    MLD 5.3 -WZ - unstable - SatIp-Client - ASROCK980DE3 - SSD128 GB - Athlon64 XII 240 - GT 730

  • Hi,
    der Claus war anscheinend schon wieder fix tätig . In den Paketen gibt es jetzt 2016.10.29-2.


    Gerade das neue Firmware Paket installiert und neu gestartet. Dann gleiches Prozedere wie beim Backtrace oben, Fehler immer noch da.


    EDIT:
    Wenn ich die Diskussion im Link von reufer richtig verstehe hat es was mit dem Kernel zu tun. Bei meinem MLD 5.1 testing läuft:


    uname -a

    Code
    1. Linux MLD 4.1.21.197.1 #1 SMP Wed Oct 26 09:26:30 CEST 2016 armv7l GNU/Linux
  • Nach Aktualisierung auf die neue Firmware 2016.10.29-2 (Kernel: 4.1.21.197.1) sehe ich da keinen Unterschied zu vorher. Der Fehler ist nach wie vor vorhanden.


    [EDIT] Backtrace [/EDIT]

    The post was edited 1 time, last by iNOB ().

  • Mir ist da was aufgefallen:


    Wenn ich die RPi3 boote, wobei im rpihd-plugin die GPU Unterstützung fürs OSD auf nein ist, funktioniert alles super.
    Schalte ist die GPU Unterstützung ein, stürzt der VDR ab. Es bringt auch nichts, nachträglich die GPU-Unterstützung wieder auszuschalten, die RPi3 muss mit NEIN booten.


    Aufgefallen ist es mir, weil für den Opa ein weiters System baue und der Ihm gewohnte Flatskinplus nur ohne GPU Unterstützung richtig funktioniert.


    Testsystem: RPi3, MLD5.1 Testing


    Fr.

  • Grad mal ausprobiert mit gleicher Hard- und Software wie Frounts. Kann das soweit bestätigen, dass nach Abschalten der GPU Unterstützung der Wechsel von Aufzeichnung zu Live-TV funktioniert. Allerdings ist das für skins mit skindesigner unbrauchbar, da das ohne GPU doch recht träge wird.


    Der Fehler hängt definitiv mit der GPU-Unterstützung zusammen.

  • Danke für die Hinweise. Beim verlinkten Firmware-Issue wurde ein Lock gefixt, welcher bei vielen Zugriffen auf die GPU für Probleme gesorgt hat. Da es vermutlich wieder ein ähnliches Problem ist, wird das Abschalten des High-Level-OSDs dieses auch beseitigen. Ich muss mal verschiedene Firmware-/Kernel-Versionen durchprobieren um eingrenzen zu können, seit wann das Problem auftritt - erst dann macht es wohl Sinn, das Issue wieder zu öffnen. Leider hatte ich bisher keine Zeit dazu...


    Gruss
    Thomas