ring buffer overflows -> cDevice::Detach() blockiert...

    Start() und Cancel() müssen auch aus dem mutexReceiver-block raus, das war der Grund für die blackscreens.
    Anbei der hoffentlich finale Patch.
    Bitte überprüfen, ausgiebig testen und rückmelden.

    @jire, kann zwar nicht testen, aber langsam gefällt mir die Lösung. Der mutexReceiver-Block sollte nur das receivers Array schützen. Was ich nur in der Detach-Funktion betrachtet habe, hast du nun auch in der anderen Funktion umgesetzt, daher gefällt mir die Lösung.

    Noch zur Erklärung:
    Wenn Start() im mutexReceiver-Block ist, kann Folgendes passieren.
    Attach() hat den mutexReceiver, Action() wartet auf den mutexReceiver, Start() wird in Attach() aufgerufen, Start() wartet darauf dass Action() fertig wird. Das führt zum THREAD_STOP_TIMEOUT in Start() und der neue Receiver Thread wird nicht gestartet => Black Screen.
    Wenn jedoch der mutexReceiver vor Start() freigegeben wird, dann wird Action() fertig und der Thread rechtzeitig beendet und kann von Start() neu gestartet werden.


    Diese Verschachtelungen sind ganz schön kompliziert.


    Den deadlock gab es übrigens schon seit über 11 Jahren (seit mutexReceiver in vdr-1.3.18 eingeführt wurde).


    Meiner Meinung nach kann der Patch so in die nächste VDR Version übernommen werden.
    Dann kann man wieder sorglos Plugins wie osdteletext etc. benutzen.

    Wenn ich mir das so durchlese, ist doch inzwischen ein Thema für VDR Core, oder? Gibt es Einsprüche gegen eine Verschiebung des Threads?


    [EDIT] Nach "VDR Core" verschoben.


    ===


    Werde den Patch auch mal testen und dann berichten ...


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Für mich funktioniert der Patch perfekt. Auch mit Plugin-Vollaustattung gab es bisher keinen einzigen derartigen Hänger mehr. Vielen Dank an jrie.


    Gruss, Xcoder

    VDR: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Bookworm, vdr-2.4.1, softhdcuvid, satip

    Kann auch nicht klagen. Weder Nebeneffekte noch Hänger feststellbar :tup

    Patched 2.1.6, so far no VDR crashes like I had before. Fast zapping with the motorola streamdev clients killed VDR, I've even build in a delay in my script to slow down zapping. But it looks like it is cured.


    Thanx!! :tup :tup :tup

    I'm sorry for the English postings but I can't write German, reading isn't a problem.


    VDR server: P4 with vdr 2.1.6 / streamdev / SmartTVweb / vipclient Javascript
    Clients : Motorola Vip1903/1963

    Kannst du auch bestätigen, dass mein Patch (wie bei tv-user) hilft?
    Denn darum geht es hier.


    Oder wolltest du sagen, dass er bei dir NICHT hilft?

    Danke Jungs, bin zwar "nur" Anwender, aber dieses Ei stinkt mir schon seit langem!
    Endlich läuft die Kiste beim zappen sauber durch, wenn diverse Aufnahmen laufen!
    Vielen Dank :tup! :applaus !


    astra.

    [haupt-vdr] .. Odroid N2+, VDRSternELEC, SatIP

    [haupt-vdr] .. Gen2vdr-V60, vdr-2.4.4, AsRock H77 Pro4-M, Zotac GeForce GT 1030 ZONE Edition, V4L-Cine-S2-V6.5, TT-FF-S2-6400 (Tuners only), URC 7140 @ CIR
    [vdr-2] ......... Gen2vdr-V51, vdr-2.2.0, AsRock AM1B-ITX, AMD 3850 APU, Sundtek SkyTV Ultimate IV, URC 7140 (LIRC)

    Super Patch. Macht vdr noch stabiler.


    Mein vdr-2.2.0 läuft mit 3 usb dvb-c tunern und mit der 4er digibox satip. 24h7Tg.


    Ergänzend fand ich kürzlich diesen thread.


    https://www.linuxtv.org/pipermail/vdr/2016-May/029056.html.


    Dieser Patch schaltet unbenutzte reciever idele um Energie zu sparen. Bei meinen 3 dvb-c
    receivern sind dies ca. 6-8W. Der Power saving patch und dieser deadlock Patch hakeln ein wenig
    beim patchen. ich habe das manuell nach meinen Gutdünken zusammen gebastelt. Aber vielleicht
    sieht sich ein Profi dieses mal an.
    Die Energieeinsparung durch bedarfsgerechtes aktivieren/dektivieren von Recievern
    und das dann deadlockfrei, wäre ideal.


    Gruß

    jrie


    Ich hatte eine bestimmte Situation wo es immer wieder zu dem Vorfall kam, den das Patch beheben soll. Am WE war es wieder soweit, was soll ich sagen, super, scheint gelöst und VDR ist stabil wie vorher auch bzw. nun noch etwas stabiler ...


    Vielen Dank.


    Regards
    fnu

    HowTo: APT pinning

    Grrr, doch wieder ein Deadlock:



    Gruss, Xcoder

    VDR: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Bookworm, vdr-2.4.1, softhdcuvid, satip

    Interessant wäre da noch die Information, welcher Mutex welchem Thread gehört, so wie in Post #29, zweiter Block.
    Dann könnte man eventuell besser aufdröseln, welche der 4 sich gegenseitig blockieren.

    Gerade habe ich ihn wieder erwischt. Wenn ich das richtig sehe verhängen sich die Threads 1 + 19 (LWP 5424 + 5444):


    VDR: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Bookworm, vdr-2.4.1, softhdcuvid, satip

    Ein Schnellschuss, probier den mal.
    Da ist beim Detach() die camSlot Sache noch im mutexReceiver drin gelassen.
    Auf die Schnelle sieht es mir so aus, als ob es da her kommen könnte.
    Gerade keine Zeit tiefer zu gucken.

    OK, danke. Patch ist drin. Da die Deadlocks nun wirklich sehr sporadisch auftreten, könnte es etwas dauern bis ich einen erwische, wenn es den nun überhaupt noch welche geben kann... ;)


    Gruss, Xcoder

    VDR: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Bookworm, vdr-2.4.1, softhdcuvid, satip

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden