2.3.8 Abstürze auf bestimmten Sendern

  • 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:


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

  • 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

    Registrieter VDR User Nr. 1237


  • 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...

  • 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?

    Registrieter VDR User Nr. 1237


  • 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
    1. url: https://defuse.ca/b/grJQXnfZ
    2. pass: media

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von crow ()

  • 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.

    Gruß
    Frodo

  • Laut https://github.com/FernetMenta…gin-vnsiserver/issues/102 könnte ein mit DEBUG_LOCKSEQ gebauter VDR einen Einfluss auf den Deadlock haben - ggf. mal ohne Probieren: https://github.com/FernetMenta…3d074a4f0c18b13c080b7374a

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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.

    Gruß
    Frodo

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

  • Taipan

    Laut den Sourcen ist der Parameter aktiv:

    Code
    1. thread.c:#define DEBUG_LOCKSEQ


    Für Trusty baut der VDR gerade neu ohne DEBUG_LOCKSEQ

    Gruß
    Frodo

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Frodo ()

  • Das hier...

    Code
    1. Thread 1 (Thread 0x7f922612e7c0 (LWP 4708)):
    2. ...
    3. #8 0x00007f9223e8e4da in exit () from /usr/lib/libc.so.6
    4. #9 0x000055831f6db45c in Watchdog (signum=<optimized out>) at vdr.c:177
    5. #10 <signal handler called>
    6. #11 0x00007f92258a270a in __lll_lock_wait () from /usr/lib/libpthread.so.0
    7. #12 0x00007f922589ba25 in pthread_mutex_lock () from /usr/lib/libpthread.so.0
    8. #13 0x000055831f6cc809 in cMutex::Lock (this=0x558320a0e9a8) at thread.c:224
    9. #14 0x000055831f6ccf7f in cMutexLock::Lock (this=0x7ffc937aaac0, Mutex=<optimized out>) at thread.c:404
    10. #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

  • 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.

    Gruß
    Frodo

  • 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...

  • 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

    Gruß
    Frodo

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Frodo ()

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

    Gruß
    Frodo