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

  • Hallo,


    Mein VDR 2.2.0 mit satip, softhddevice, permashift klemmt sich noch recht oft mit ring buffer overflows ab. So richtig eingrenzen konnte ich das Problem noch nicht, da es nicht wirklich reproduzierbar ist... Ich ben etwas ratlos in welche Richtung ich da suchen soll. Der ring buffer overflow scheint ja von recorder.c zu kommen. Bei dieser Gelegenheit lief aber gar keine Aufnahme, sonder es wurde nur der Kanal umgeschaltet. In welche Richtung muss ich da suchen?


    Gruss, Xcoder


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

    Einmal editiert, zuletzt von Xcoder ()

  • Hmm, das bringt mich leider nicht weiter:


    1. es ist gar keine Aufnahme aktiv gewesen
    2. kann es kaum an der Festplatte liegen, ich kann auch problemlos ab allen 6 Tuner zig Aufnahmen parallel laufen lassen, ohne dass es klemmt.


    Kann es mit dem permashift Plugin zusammenhängen?


    Gruss, Xcoder

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

  • Deaktivier es mal. Mal sehen was das Log dann sagt.

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

  • Grrr. Auch ohne permashift und ungepatchtem 2.2.0 vdr konnte ich das gleiche Verhalten mit wildem zappen provozieren...

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

  • Ich habe den Eindruck, dass es nun ohne permashift seltener passiert. Das ist ja schon etwas sehr komisch. Wieso zum Geier kommt dieser Fehler, obwohl doch gar keine Aufnahme aktiv ist???


    Gruss, Xcoder

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

  • Oder dann doch das poese-plugin... Jedenfalls hat es dort auch Code der mit dem Ringbuffer spielt:


    C
    #ifndef ___FRAME_H
    #define ___FRAME_H
    
    
    #include <vdr/ringbuffer.h>


    Könnte gut sein, dass es oft beim Zappen von/zu SRF Sendern passiert.


    Gruss, Xcoder

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

    Einmal editiert, zuletzt von Xcoder ()

  • Habe jetzt zwar erfolglos versucht zu verstehen inwiefern mein Beitrag gegen Art. 2 der Boardregeln verstossen soll, aber man muss ja nicht alles verstehen. Nun den.
    Gruss, Xcoder

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

  • Permashift hat eine eigene Ringbuffer-Implementierung, von der diese Fehlermeldung nicht kommt.
    (Alte Daten werden da bei Bedarf verworfen, dadurch kann es eigentlich keinen Overflow geben.)
    Natürlich verbraucht es Ressourcen, die woanders dann fehlen könnten. Aber wenn es auch ohne auftritt...

  • Danke @Eike, habe ich gesehen. Als alter REELboxler könnte ich logischweise ja auch kaum auf das schöne permashift verzichten...


    Ich konnte es mittlerweile eindeutig auf cSatipDevice::WriteData() eingrenzen. Mal schauen ob es hilft wenn ich da die Grösse von tsBufferM auf 10 * SATIP_BUFFER_SIZE vergrössere. Ich kratze da aber immer noch etwas an der Oberfläche und habe den Durchblick noch nicht wirklich wie die Dinge im Detail zusammenhängen...


    Gruss, Xcoder

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

  • Hallo,


    Hmm, der Fehler wird zwar im Code vom satip-plugin erzeugt, aber satip ist nicht die Ursache. Unregelmässig wird nach dem Umschalten cSatipDevice::GetTSPacket() einfach nicht mehr aufgerufen. Dann läuft dort der tsBufferM voll und cSatipDevice::WriteData() kann keine TS Daten mehr schreiben.


    Dann muss es wohl am VDR selber liegen. Etwas erstaunlich ist, dass vom VDR, trotz log level 3, selber kein Fehler kommt...


    Gruss, Xcoder

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

  • Habe nun meine gdb Kenntnisse etwas aufgefrischt und siehe da, der Recevier Thread bleibt in einem cDevice::Detach() stecken:


    Code
    #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
    #1  0x00007f5c05017b05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x1171f70) at ../nptl/pthread_mutex_lock.c:81
    #2  0x000000000050ad09 in cMutex::Lock (this=0x1171f70) at thread.c:193
    #3  0x000000000050b2af in cMutexLock::Lock (this=0x7f5b537fdbd0, Mutex=<optimized out>) at thread.c:373
    #4  0x00000000004845b8 in cDevice::Detach (this=this@entry=0x116f690, Receiver=Receiver@entry=0x125c400) at device.c:1690
    #5  0x0000000000474411 in cCaPidReceiver::Receive (this=0x125c400, Data=<optimized out>, Length=<optimized out>) at ci.c:213
    #6  0x000000000048648b in cDevice::Action (this=0x116f690) at device.c:1614
    #7  0x000000000050b119 in cThread::StartThread (Thread=0x116f690) at thread.c:262
    #8  0x00007f5c05015454 in start_thread (arg=0x7f5b537fe700) at pthread_create.c:334
    #9  0x00007f5c039c4eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109


    Kann sich da jemand einen Reim drauf machen?



    Gruss, Xcoder

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

    Einmal editiert, zuletzt von Xcoder ()

  • Ja und ohne osdteletext passiert es dann nicht mehr...


    Mal schauen ob ich da mehr herausfinde. Die Kompetenzdichte lässt hier aber schon etwas zu wünschen übrig.

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

  • Davon bin ich durchaus überzeugt... Aber schau Dir mal den Thread an, es gibt eigentlich 0 sachdienliche Hinweise oder konkrete Empfehlungen wie das Problem näher Eingegrenzt werden kann. Hätte ich nicht selber die notwendigen Programmierkenntnisse um zumindest zusätzlichen Debug-Code einzufügen, stände ich noch am gleichen Punkt wie am ersten Tag.

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

  • Naja, es gibt halt nicht viele hier, die so tief in der Problematik drin stecken. Die meisten sind hier nur "Anwender" und wenn die Kiste mal abschmiert ist das halt so. Von daher bin ich froh und dankbar, wenn sich Leute wie du mal hinstellen und solche "Effekte" abstellen.

Jetzt mitmachen!

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