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

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

Hallo zusammen

Danke für den Hinweis - ich muss dem mal nachgehen. Hat denn schon jemand einen Core Dump gemacht?

Gruss
Thomas

Quote

Kann das wer bestätigen?

Ja das Problem habe ich auf meinem RPI3 mit MLD5.1 auch.

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

Hallo zusammen,

gleiches bei mir.

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

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;

#0  0x76f34a40 in ?? () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x76f34af4 in sem_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2  0x767c7174 in vcos_semaphore_wait (sem=0x767d4384 <vcos_thread_main+12>) at /home/dc4/projects/staging/userland/build/inc/interface/vcos/vcos_platform.h:254
#3  _vcos_thread_sem_wait () at /home/dc4/projects/staging/userland/build/inc/interface/vcos/vcos_platform.h:613
#4  vcos_generic_event_flags_get (flags=0x10612a8, bitmask=133, op=5, suspend=4294967295, retrieved_bits=0x7ea83704)
    at /home/dc4/projects/staging/userland/interface/vcos/generic/vcos_generic_event_flags.c:223
#5  0x7681fa2c in ilclient_disable_port_buffers () from /usr/lib/vdr/libvdr-rpihddevice.so.2.2.0
#6  0x768064e4 in cOmx::StopVideo() () from /usr/lib/vdr/libvdr-rpihddevice.so.2.2.0
#7  0x7680d71c in cOmxDevice::SetPlayMode(ePlayMode) () from /usr/lib/vdr/libvdr-rpihddevice.so.2.2.0
#8  0x0008b57c in cDevice::Detach (this=0x1067a58, Player=Player@entry=0x2ae2f10) at device.c:1292
#9  0x000e4254 in cPlayer::Detach (this=this@entry=0x2ae2f10) at player.c:37
#10 0x00099e0c in cDvbPlayer::~cDvbPlayer (this=0x2ae2f10, __in_chrg=<optimized out>) at dvbplayer.c:327
#11 0x0009ab20 in ~cDvbPlayer (this=0x2ae2f10, __in_chrg=<optimized out>) at dvbplayer.c:333
#12 cDvbPlayerControl::Stop (this=this@entry=0x2a2ec70) at dvbplayer.c:998
#13 0x000c6e78 in cReplayControl::Stop (this=this@entry=0x2a2ec70) at menu.c:6317
#14 0x000c8e6c in cReplayControl::ProcessKey (this=0x2a2ec70, Key=<optimized out>) at menu.c:6789
#15 0x00071680 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1294

Hoffe es hilft.

Hallo

Quote from megalutschi

Hoffe es hilft.

Ja, das tut es, vielen Dank. Das ist ein Firmware-Problem von dem ich eigentlich dachte, dass es gefixt sei. Habt ihr eine aktuelle Firmware am laufen?

Gruss
Thomas

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

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:

MLD-RPi3-Ampi> uname -a
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ß

Quote from brötchen

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

Linux MLD 4.1.21.197.1 #1 SMP Wed Oct 26 09:26:30 CEST 2016 armv7l GNU/Linux

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.

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