2.3.8 Abstürze auf bestimmten Sendern

Taipan · October 31, 2017 at 9:19 PM

Hallo Gemeinde,

ich bin mir nicht ganz sicher ob ich hier richtig bin oder es das ddci2-Plugin betrifft (oder weder noch...) Also bitte um Nachsicht oder Verschiebung des Threads!

Folgendes Prob:

Ich habe mit Frodos VDR2.3.8, dem ddci-Plugin, dem Alphacrypt-Light und einem regulären Abo Abstürze auf mehreren Sky Sendern. Das sind DisneyXD, Heimatkanal und GoldstarTV

Die Abstürze kommen teils sofort und auch schon einmal nach längerer Zeit - aber sie kommen sicher! Aufnehmen geht somit garnicht. Ich hatte zwischenzeitig mal das EPG gelöscht um dort Fehler auszuschließen...

Im Log finde ich folgendes:

Display Spoiler

Oct 31 21:06:49 VDR vdr: [26211] [softhddev]SetVideoDisplayFormat: 1

Oct 31 21:06:49 VDR vdr: [26211] [softhddev]GetSpuDecoder:

Oct 31 21:06:49 VDR vdr: [26211] DDCI-Dbg (virtual void DdCiCamSlot::StartDecrypting())

Oct 31 21:06:49 VDR vdr: audio/alsa: start delay 336ms

Oct 31 21:06:49 VDR vdr: [26211] DDCI-Dbg (virtual void DdCiCamSlot::StopDecrypting())

Oct 31 21:06:49 VDR vdr: [26211] CAM 1: unassigned from device 1

Oct 31 21:06:49 VDR vdr: [26211] CAM 1/1: reusing MTD CAM slot

Oct 31 21:06:49 VDR vdr: [26211] DDCI-Dbg (virtual void DdCiCamSlot::StopDecrypting())

Oct 31 21:06:49 VDR vdr: [26413] device 1 TS buffer thread ended (pid=26211, tid=26413)

Oct 31 21:06:49 VDR vdr: [26412] buffer stats: 46248 (0%) used

Oct 31 21:06:49 VDR vdr: [26412] device 1 receiver thread ended (pid=26211, tid=26412)

Oct 31 21:06:49 VDR vdr: [26211] CAM 1: assigned to device 1

Oct 31 21:06:49 VDR vdr: [26421] device 1 receiver thread started (pid=26211, tid=26421, prio=high)

Oct 31 21:06:49 VDR vdr: [26422] device 1 TS buffer thread started (pid=26211, tid=26422, prio=high)

Oct 31 21:06:49 VDR vdr: [26211] DDCI-Dbg (virtual void DdCiCamSlot::StartDecrypting())

Oct 31 21:06:50 VDR vdr: SEDUATMO: Switch vertical cine bars to 8

Oct 31 21:06:50 VDR vdr: SEDUATMO: Switch horizontal cine bars to 5

Oct 31 21:06:50 VDR vdr: [26211] [softhddev]SetPlayMode: 1

Oct 31 21:06:52 VDR vdr: [softhddev] 12 invalid PES video packet(s)

Oct 31 21:06:53 VDR vdr: [26275] VNSI: Requesting clients to reload channel list

Oct 31 21:06:54 VDR vdr: SEDUATMO: Switch horizontal cine bars to 0

Oct 31 21:06:54 VDR vdr: SEDUATMO: Switch vertical cine bars to 6

Oct 31 21:06:54 VDR vdr: video: slow down video, duping frame

Oct 31 21:06:54 VDR vdr: video: 14:39:33.140 +107 861 0/\ms 24+8+4 v-buf

Oct 31 21:06:54 VDR vdr: video/vdpau: synced after 102 frames

Oct 31 21:06:55 VDR kernel: [48931.708232] init: vdr main process (26211) killed by ABRT signal

Oct 31 21:06:55 VDR kernel: [48931.711380] init: vdr-net-monitor main process (26302) killed by TERM signal

Oct 31 21:06:55 VDR vdr-crash: vdr exit with signal ABRT

Oct 31 21:06:55 VDR kernel: [48931.751268] init: vdr-dbg main process (26435) terminated with status 1

Hat von Euch jemand einen Tip wo ich hinlangen muß?

joachim-h · October 31, 2017 at 9:55 PM

Ich habe ein sehr ähnliches Setup aber bisher erst einmal ein Problem auf Disney XD bemerkt. Heute blieb der VDR dort beim Durchzappen stehen und war nicht mehr bedienbar. Ich benutze die drei Sender nie, könnte aber testen, ob ich Dein Problem reproduzieren kann, wenn Du möchtest.

Off-Topic:

Hast Du auch Aufwachprobleme bei Deinem CI? Könntest Du mal in diesen Thread schauen?

Gruß

Joachim

Taipan · October 31, 2017 at 10:12 PM

Ich habe eben mal umgestellt auf suspend2RAM und - Ja - das CI fehlt auch hier komplett nach dem Neustart...

Ich nutze aber mit der SSD keinen Suspend, sondern fahre immer komplett runter. Die Startzeiten sind auch so absolut OK...

joachim-h · November 1, 2017 at 7:22 PM

Ja, die Startzeiten sind für mich auch mit HDD kein Problem, leider kann ich mein Mainbaord nur aus dem S3 aufwecken aus Poweroff funktioniert weder ACPI noch NVRAM. Dann muss ich wohl mal nach einer Hardware-Einschalter-Lösung mit Timerünterstützung gucken.

So, nun aber genug den Thread gekapert.

Soll ich mal gucken, ob ich Deine Abstürze reproduzieren kann? Was passiert genau? Der VDR bleibt stehen, wie bei mir oder startet er neu?

Taipan · November 2, 2017 at 6:37 AM

...der VDR startet sporadisch neu!

crow · November 2, 2017 at 7:36 AM

vor ein paar tagen habe ich auch so was gehabt (seit lange Zeit nicht), bei mir wurde ein coredump erstellt, vielleicht sagt das etwas zu devs. Zur Info ich habe keinen Hardware CAM.

log 30 Tage gültig:

Code

url: https://defuse.ca/b/grJQXnfZ
pass: media

Frodo · November 2, 2017 at 9:58 AM

Mein VDR startet auch sporadisch neu aber nur wenn ich neue Timer erstelle oder im Menü nach Aufnahmen suche.

Einen Zusammenhang zu den oben genannten Sendern sehe ich nicht.

Taipan · November 2, 2017 at 10:51 AM

Frodo

Nutzen wir ffmpeg >=3.3.0 ?

seahawk1986 · November 2, 2017 at 11:06 AM

Laut https://github.com/FernetMenta/vd…rver/issues/102 könnte ein mit DEBUG_LOCKSEQ gebauter VDR einen Einfluss auf den Deadlock haben - ggf. mal ohne Probieren: https://github.com/FernetMenta/VD…18b13c080b7374a

Frodo · November 2, 2017 at 11:25 AM

Taipan

Ja nutzen wir, seit 26.10. haben wir ffmpeg = 3.3.4, zuvor war es auch eine Version >= 3.3

Wir hatten zuvor eine kleinere Version welche, einige Plugins mit segfaults quitiert hatten.

crow · November 2, 2017 at 12:10 PM

Bei mir ist es headless. Ein Client (signature) ist Kodi mit vinsi addon.

Taipan · November 2, 2017 at 12:22 PM

Frodo

Ist der von seahawk1986 beschriebene Parameter bei uns aktiv?

Frodo · November 2, 2017 at 12:45 PM

Taipan

Laut den Sourcen ist der Parameter aktiv:

Code

thread.c:#define DEBUG_LOCKSEQ

Für Trusty baut der VDR gerade neu ohne DEBUG_LOCKSEQ

kls · November 2, 2017 at 1:08 PM

Das hier...

Code

Thread 1 (Thread 0x7f922612e7c0 (LWP 4708)):
 ...
 #8  0x00007f9223e8e4da in exit () from /usr/lib/libc.so.6
 #9  0x000055831f6db45c in Watchdog (signum=<optimized out>) at vdr.c:177
 #10 <signal handler called>
 #11 0x00007f92258a270a in __lll_lock_wait () from /usr/lib/libpthread.so.0
 #12 0x00007f922589ba25 in pthread_mutex_lock () from /usr/lib/libpthread.so.0
 #13 0x000055831f6cc809 in cMutex::Lock (this=0x558320a0e9a8) at thread.c:224
 #14 0x000055831f6ccf7f in cMutexLock::Lock (this=0x7ffc937aaac0, Mutex=<optimized out>) at thread.c:404
 #15 0x000055831f61ad48 in cCamSlot::HasUserIO (this=0x558320a0e990) at ci.c:2395

...sieht für mich so aus, als würde cCamSlot::HasUserIO() auf den Mutex warten, den aber ein anderer Thread hält und anscheinend nicht freigibt. Dadurch schlägt der Watchdog zu und bricht VDR ab. Das mit "double free or corruption" passiert erst danach und ist wohl die Folge des "brutalen" Abbruchs. Dürfte aber mit dem eigentlichen Problem nichts zu tun haben.

Warum der Mutex nicht freigegeben wird kann ich leider nicht erkennen.

Klaus

Frodo · November 2, 2017 at 3:21 PM

Ich habe das streamdev Plugin im Verdacht.

Wenn ein streamdev-client einen verschlüsselten Sender vom VDR Server nutzt, kann der Server nicht mehr auf diesen Kanal umschalten. Alle anderen verschlüsselten Kanäle sind auch auf dem Server oder anderen streamdev-clients gleichzeitig nutzbar.

Mit dem vnsiserver Plugin tritt dieses Verhalten nicht auf.

Taipan · November 2, 2017 at 5:56 PM

So mit dem neuen VDR getestet (thread.c:#define DEBUG_LOCKSEQ) und auf DisneyXD, sowie komplett ohne Plugins (Ausser: ddci2, softhddevice, restfulapi und dbus2vdr) stürzt er noch immer ab...

Taipan · November 2, 2017 at 6:41 PM

Ich habe auch ein crashlog! Meine unerfahrenen Augen sehen aber nur softhddevice und ffmpeg sich wiederholend...

Vielleicht kann von Euch jemand drüberschaun?

pastebin

Frodo · November 2, 2017 at 8:26 PM

Welches softhddevice Plugin verwendest Du?

Ich verwende softhddevice-openglosd und habe auch nur dieses auf ffmpeg 3.3.4 angepasst. ~~Bei den anderen Versionen muss ich mir die control Datei erst einmal anschauen.~~

Das sind die verwendeten Versionen:

vdr-plugin-softhddevice-openglosd = ffmpeg 3.3.4

vdr-plugin-softhddevice = ffmpeg 2.7.2

vdr-plugin-softhddevice-pesintta = ffmpeg 3.3.4

vdr-plugin-softhddevice-vpp = ffmpeg 3.3.4

Taipan · November 2, 2017 at 8:36 PM

Ja ich nutze auch softhddevice-openglosd...

Frodo · November 2, 2017 at 8:42 PM

Ok, in meinen crash Logs gibt es auch ffmpeg3 Zeilen, seit des entfernen der DEBUG_LOCKSEQ Ausgaben ist aber kein crash mehr aufgetreten.

Participate now!