vdr-2.2.0 mit graphtftng und remotetimers hängt bei Öffnen der Aufzeichungen

Jarod · 22. November 2015

Hi,

auf meinem RPI2 habe ich den vdr-2.2.0 mit folgenden Plugins installiert
* vdr-eepg Patch
* graphtftng (git)
* remotetimers 1.0.2
* rpihddevice (git)
* svdrpservice (1.0.0)
* streamdev-client (git)
Das /video0 Verzeichnis ist per NFSv4 eingebunden.

Sobald grapftftng und remotetimers gemeinsam geladen werden tritt das Problem auf:
Wenn ich gleich nach dem Start auf Menü -> Aufzeichnungen(4) klicke, hängt sich der VDR in 9 von 10 Fällen auf. Lasse ich den vdr eine Weile laufen und öffne dann das Menü, dann klappt es in 9 von 10 Fällen. Im Log vom VDR findet sich trotz "-l 3" in beiden Fällen nichts Auffälliges.

Code

Nov 22 18:45:46 pi-vdr vdr: [graphTFT] Mode is set to (0x30), menu section to 'MenuRecording'
Nov 22 18:45:46 pi-vdr vdr: [graphTFT] Section changed from 'MenuMain' to 'MenuRecording'
Nov 22 18:45:46 pi-vdr vdr: [graphTFT] Missing 'recording' info, can't lookup variable
Nov 22 18:45:46 pi-vdr vdr: [graphTFT] Missing 'recording' info, can't lookup variable
Nov 22 18:45:46 pi-vdr vdr: [graphTFT] Missing 'recording' info, can't lookup variable
Nov 22 18:45:46 pi-vdr vdr: [graphTFT] Missing 'recording' info, can't lookup variable
Nov 22 18:45:46 pi-vdr vdr: [graphTFT] OsdClear
Nov 22 18:46:01 pi-vdr rsyslogd-2007: action 'action 17' suspended, next retry is Sun Nov 22 18:47:31 2015 [try http://www.rsyslog.com/e/2007 ]
Nov 22 18:46:01 pi-vdr CRON[4301]: (root) CMD (if test -x /usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi)
Nov 22 18:46:39 pi-vdr vdr: [824] creating new channel 'Channel 4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9211-0
Nov 22 18:46:39 pi-vdr vdr: [824] creating new channel 'Channel 4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9212-0
Nov 22 18:46:39 pi-vdr vdr: [824] creating new channel 'Channel 4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9213-0
Nov 22 18:46:39 pi-vdr vdr: [824] creating new channel 'Channel 4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9214-0
Nov 22 18:46:40 pi-vdr vdr: [824] creating new channel 'Channel 4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9215-0
Nov 22 18:46:40 pi-vdr vdr: [824] creating new channel 'Channel 4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9216-0
Nov 22 18:46:40 pi-vdr vdr: [824] changing pids of channel 4345 (Channel 4) from 0+0=0:0:0:0 to 2347+2347=2:2348=eng@4:2350=eng:2349
Nov 22 18:46:41 pi-vdr vdr: [824] creating new channel 'Film4,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9220-0
Nov 22 18:46:41 pi-vdr vdr: [824] creating new channel 'Film4 +1,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9225-0
Nov 22 18:46:41 pi-vdr vdr: [824] creating new channel 'More4 +1,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9230-0
Nov 22 18:46:41 pi-vdr vdr: [824] creating new channel 'c4 l,;BSkyB' on S28.2E transponder 112603 with id 2-2041-9281-0
Nov 22 18:46:41 pi-vdr vdr: [824] changing pids of channel 4347 (Film4 +1) from 0+0=0:0:0:0 to 2359+2359=2:2360=eng@4,2361=NAR@4:2363=eng:2362
Nov 22 18:46:45 pi-vdr vdr: [810] PANIC: watchdog timer expired - exiting!

Alles anzeigen

Nach 60 Sekunden schlägt der Watchdog Timer zu und der VDR startet neu.

Code

/usr/local/src/vdr-2.2.0-eepg/vdr --no-kbd -v /video0 -l 3 -w 60 -c /etc/vdr -L /usr/vdr/lib --lirc=/dev/lircd \
-P 'rpihddevice --display=5' -P 'graphtftng -d /dev/fb0' -Psvdrpservice -Premotetimers -Pstreamdev-client

Sobald ich entweder das graphtftng oder remotetimers Plugin nicht lade, läuft der VDR fehlerfrei. Ich möchte aber gern beide zusammen benutzen...

Falls jemand eine Idee warum es klemmt, wäre ich sehr dankbar.

Jarod

Jarod · 23. November 2015

Ich hab mich da mal mit dem gdb ans Werk gemacht und mir einen Backtrace gezogen, sobald der VDR hängen bleibt bem Öffnen des Aufzeichnungsmenüs.
Der letzte Aufruf auf dem Stack ist ein Mutex. Der letzte Aufruf eines Mutex kommt beim graphTFT dann aus der Fuktion OsdClear...

Ich bin kein Held, was Programmierung angeht, aber kann es sein, dass das remotetimers Plugin sich ein Ressource schnappt, die das GraphTFTng gern hätte? Das würde das Ganze erklären. So wie ich das sehe, verwendet das remotetimers Plugin nirgendwo einen Mutex.
Ach ja. Wenn das Aufrufen des Aufnahmemenus geklappt hat, dann kam der letzte Mutex aus OsdCurrentItem vom GraphTFTng... (Ich hoffe zumindest, dass ich mich hier nicht irre.)

Hier der Stacktrace:

Code

Program received signal SIGINT, Interrupt.
0x76f22780 in __lll_lock_wait (futex=futex@entry=0x14e6394,
    private=<optimized out>)
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c:46
46      ../ports/sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c: No such file or directory.
(gdb) bt
#0  0x76f22780 in __lll_lock_wait (futex=futex@entry=0x14e6394,
    private=<optimized out>)
    at ../ports/sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c:46
#1  0x76f1d1a4 in __GI___pthread_mutex_lock (mutex=0x14e6394)
    at pthread_mutex_lock.c:79
#2  0x00113094 in cMutex::Lock() ()
#3  0x00113738 in cMutexLock::Lock(cMutex*) ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Alles anzeigen

Jarod

Jarod · 24. November 2015

Also...
nachdem ich jede Menge isyslog Aufrufe in den Quelltext vom graphtftng geschrieben hatte und mir das Ergebnis lange betrachtet habe, glaube ich, dass es ein Timing Problem ist.
Ich vermute, dass der Mutex nicht gelöscht wird bevor das Plugin versucht ihn erneut zu setzen.
Ich konnte im gesamten Code vom graphTFTng Plugin keine einzige Stelle finden, an welcher der Lock entfernt wurde.
Ich vermute es geschieht über den

Code

wait(updateIn);

in Zeile 557 in der status.c. Das ruft, so vermute ich die Funktion "cGraphTFTDisplay::wait" auf, in der es den Aufruf

Code

_doUpdate.TimedWait(_mutex, waitStep);

gibt. ... und ich vermute weiter, dass dieser aus der thread.c des VDR vererbt wurde.

Alles in Allem hat bei mir dann Folgendes (vorerst) geholfen:

Diff

diff --git a/display.c b/display.c
index d44c789..574c139 100644
--- a/display.c
+++ b/display.c
@@ -553,8 +553,8 @@ void cGraphTFTDisplay::Action()
          }
       }


-      if (updateIn < 10)     // 10ms -> the minimum
-         updateIn = 10;
+      if (updateIn < 650)     // 10ms -> the minimum
+         updateIn = 650;


       // can't calc this inline, due to a format string problem ... ?

Alles anzeigen

Der Wert scheint im ersten Moment recht hoch. Er funktioniert aber.
Ich habe keine Ahnung, ob das remotetimers Plugin mit dazu beiträgt, dass das Einlesen der OsdItems im graphTFTng so lange dauert, denn es liest sie auch alle ein.
Ich habe auch nicht ganz verstanden, wie das graphTFTng Plugin den updateIn Wert berechnet. Es scheint mit der Zeit zu tun zu haben, die es benötigt das OSD zu zeichnen.

Ich würde mich freuen, wenn mir jemand erklären könnte, ob das was ich hier vermute völliger Blödsinn ist, oder ob ich wenigstens teilweise richtig liege.

Liebe Grüße
Jarod.

horchi · 30. November 2015

Hi,

ja genau ein TimedWait gibt den Mutex frei, dass passiert in wait da dort die Haupt-schliefe nichts macht dadurch die Ressourcen 'frei' sind und von Status Interface geändert werden können.

Wie das mit dem Remotetimer Plug zusammenhängt sehe ich gerade noch nicht. Interessant wäre zu sehen wo die anderen Threads in dem Moment stehen.
Kann du den VDR mal mit SIGSEG abschießen sobald er hängt und den BT aller Threads posten?

Jörg

louis · 30. November 2015

Zitat von horchi

Kann du den VDR mal mit SIGSEG abschießen

Bevor der angesprochene suchen muss...SIGSEGV meint der Kollege

Ciao Louis

vdr-2.2.0 mit graphtftng und remotetimers hängt bei Öffnen der Aufzeichungen

Jetzt mitmachen!

Teilen

Tags

Benutzer online in diesem Thema