Bildruckeln: buffer usage läuft voll

  • zum wiederholten male beobachte ich heute Abend auf ARD Ruckler und volllaufende buffer:



    Auffällig ist auch das träge OSD (STTNG-Skin).


    Auch beim ZDF taucht das Problem öfters mal auf. Mein Eindruck ist, dass Sendungen mit hoher Datenrate (laut femon heute abend bis 8 MB/s) besonders betroffen sind. Sobald eine Aufnahme startet, geht`s los.


    Die Platte läuft mit aktiviertem DMA. vdr-Version ist 1.3.34, Kernel 2.6.12.4 mit CVS-Treibern von Mitte August. Es ist kein Unterschied, ob ich Firmware 261d oder 2622 nehme.


    Wo kann ich ansetzen? ;(

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • das Problem tritt reproduzierbar (auch heute morgen) bei Livesendungen mit sehr hoher Bitrate auf. Ich kann mich entsinnen, dass ich das auch früher schon hatte - immer ARD/ZDF-Livesendungen.


    kann es sein, dass die DVB-Karten im allgemeinen oder meine FuSi im speziellen da Probleme haben?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • merkwürdig - niemand da, der dazu eine Idee hat?
    Tritt übrigens auch auf, wenn von ZDF aufgenommen wird und Live-TV von 3sat (gleicher Transponder) läuft.


    Mit Kernel 2.6.9 statt 2.6.12.4 ist es übrigens deutlich besser. Keine Ahnung, ob das am Kernel liegt oder an den dvb-Treibern.


    Das Problem an sich (ruckeln im Transfer mode, wenn eine Aufnahme gleichzeitig angesehen wird) ist ja hinlänglich bekannt und in diversen Threads beschrieben. Nur sind diese meist älter, und das Problem sollte eigentlich durch Verbesserungen am vdr doch gelöst sein, oder ?


    Woran kann es also liegen, wenn es trotz aktiviertem DMA für die Platte im transfer mode zu massivem Stottern und Aussetzern kommt? ist die C3 CPU (933 Mhz) zu schwach? ist der Chipsatz des Boards schuld? Kann man buffer-Größen im vdr patchen?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Hallo,


    ich bin von dem gleichen Problem betroffen. Mir ist ebenso aufgefallen, daß die Bitrate recht hoch ist, wenn das Problem auftritt.


    Nutze vdr-1.3.36 vanilla mit FW 80fd2621 mit einer DVB-C FF.


    An welchem Buffer sollte man denn "drehen"?


    Danke & Gruß, ollo

  • 80fd2621 -ist das die neueste aus dem 1.28-Paket ?


    Ich habe den Eindruck, dass es mit Kernel 2.6.14 besser geworden ist.


    Auch der neue Live-AC3 sollte den Transfermodus etwas entlasten (hoffe ich zumindest)

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Einmal editiert, zuletzt von Dr. Seltsam ()

  • Hi Dr. Seltsam,


    danke für den Tip, aber das kann's doch nicht alleine sein?!


    Welcher Buffer läuft eigentlich voll? Kann man den nicht größer machen?


    Übrigens FW 80fd2621 ist wohl 1.26. In 1.28 steckt wohl 80fb2621, die habe ich noch nicht probiert...


    Gruß, ollo

  • Hi Dr. Seltsam!


    Evtl. kommen wir dem mit etwas Statistik auf die Spur


    CPU 2.4 Celleron SuSE 9.2 VDR 1.3.24
    seit Erscheinen der 9.2 im Dauereinsatz
    bis zu 7 Aufnahmen gleichzeitig + eine Aufnahme ansehen
    --> kein Absturz, kein Ruckeln,
    --> KDE schläft fast ein, aber der VDR bekommt genügend Rechenzeit
    --> DVD Archiv brennen -> 25 min, VDR läuft flüssig weiter
    --> noad läuft mit voller Gewindigkeit, ohne den VDR zu bremsen


    CPU 2.4 Celleron SuSE 9.3 VDR 1.3.24
    ebenfalls Dauereinsatz
    --> mehrere Aufnahmen + eine Ansehen --> VDR läuft flüssig
    --> KDE --> schneller
    --> läuft noad oder burn Plugin und eine Aufnahme --> erste Ruckler bei
    der Wiedergabe
    --> noad sehr lansam, brennen ca. 45 min


    CPU 2.4 Celleron SuSE 10.0 VDR 1.3.24
    erste Tests
    --> mehrere Aufnahmen + eine Ansehen --> Ruckler nicht nur bei der Wiedergabe
    auch in den Aufnahmen
    --> noad und burn wieder so schnell wie unter 9.2
    --> KDE bleibt flüssig aber unser geliebter VDR bekommt etwas zuwenig Rechenzeit


    CPU 2.4 Celleron SuSE 10.0 VDR 1.3.35
    erste Tests
    --> eine Aufnahmen + eine Ansehen --> kleine Ruckler bei der Wiedergabe
    und im live Bild Blockbildung
    --> alle Programme laufen schnell und flüssig (weil der cache nicht mehr mit den
    Videodaten vollgestopft wird
    --> unser VDR bekommt aber immernoch zu wenig Rechenzeit


    In der Prozesstabelle stehen einige Prozesse die mit -5, also mit höherer Priorität als
    der VDR laufen.


    Habe also ein kleines Testprogramm geschrieben, das jede ms ein Datenpaket von
    einem thread zum andern schickt und die Zeit mißt.
    Lasse ich das Programm mit Prio 0 laufen wie der VDR:
    In 95 % der Fälle dauert es wirklich nur 1ms, aber es sind Aussetzer > 100ms dabei.
    Lasse ich das Programm mit Prio -9 laufen:
    gibt es keine Aussetzer.


    Meine Schlussfolgerung: Im VDR alle Prozesse die am Datentransport beteiligt sind
    mit hoher Priorität laufen lassen. Der VDR benötigt dann auch nicht mehr Rechenzeit
    aber er bekommt sie wenn er sie braucht oder gleich den ganzen VDR mit hoher Priorität
    starten und die Zusatzprogramme wie burn oder noad aus dem VDR heraus mit normaler
    Priorität starten.


    werde mal etwas experimentieren und melde mich dann wieder


    Viele Grüsse


    Frithjof

    vdr 1.7.23 suse 12.1 64 Bit 1xTTS2-6400 HD-USB: 24TB
    vdr 1.7.23 suse 11.3 64 Bit 1xTTS2-6400, 1xTTS2-3200 + ci HD:2TB
    vdr 2.2.0 Raspberry pi HD-USB: 2TB (Garten)

  • Zitat

    Original von frithjof
    Im VDR alle Prozesse die am Datentransport beteiligt sind
    mit hoher Priorität laufen lassen.


    aber wie macht man das ?


    Meinst Du es ist ein vdr-Problem oder ein Kernel-Problem? Du hast ja mit steigenden vdr-Versionen auch jeweils neuere Kernel genommen, so dass der Vergleich etwas schwierig zu bewerten ist.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Zitat

    Original von Pampalini
    Hallo Dr. Seltsam


    auch meine letzten Aufzeichnungen wurden durch dieses Problem unbrauchbar, weil ich kurz davor die DVB Treiber aktualisiert hatte.


    was hattest Du vorher, und womit hast Du aktualisiert?


    Zitat

    Nachdem ich testweise das Packet dvbupd20050416.tgz von MT eingespielt hatte, waren die Aufnahmen wieder OK.


    dann hast Du immer noch (oder wieder?) den alten 2.6.9er-Kernel .
    Ich glaube nicht so recht, dass die Treiber seit dem schlechter geworden sind. Da sie sich nur noch mit aktuellen Kernelversionen compilieren lassen, laufen alle aktuellen Treiber für LinVDR mindestens mit 2.6.12.x


    ach ja: von mir gibt es noch ein Treiberupdate für den 2.6.9 mit Stand Anfang Juni 2005:
    http://www.vdrportal.de/board/thread.php?sid=&postid=331444

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Einmal editiert, zuletzt von Dr. Seltsam ()

  • Hab mir die Logs nochmal angesehen, allerdings fehlen überall da wo die 'buffer overflows' vorkommen die Version der Firmware???
    Möglicherweise liegt es an der Inkompatibilität des Kernels 2.6.9 mit der installierten Firmware.
    Aber mit einem neueren Kernel hat mein VDR Probleme mit dem Ausschalten über power off. Deshalb bin ich wieder auf 2.6.9 zurück.


    Grüsse, pampalini

  • ... also wenn's wirklich am kernel liegen sollte (kernel latency), dann sollte man vielleicht mal folgende patches probieren:


    Realtime-Preempt http://redhat.com/~mingo/realtime-preempt/


    oder


    CK http://members.optusnet.com.au/ckolivas/kernel/


    Beide sollen die kernel latency senken. Der CK kernel funktioniert auf meinem Desktop prima, am VDR habe ich ihn noch nicht probiert...


    Gruß, Ollo

  • ... noch eine Info dazu, das Ruckeln & Tonaussetzer & buffer overflow kommt bei mir wiederholbar zustande, wenn ich eine Sendung (MDR) aufnehme und gleichzeitig anschaue. Interessanterweise ist die Aufnahme jedoch fehlerfrei - sagt ProjectX.


    Als DVB Treiber verwende ich aktuell die im Ubuntu Breezer 2.6.12-9-k7 mitgelieferten.


    Gruß, Ollo

  • oder vdr.


    Hast Du mal eine ältere Version ausprobiert?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • ... ja, habe es mal mit ff2621 versucht - genau das gleiche. Es dauert immer ziemlich genau 45min nach Start einer Aufnahme, bis das erste mal der buffer overflow auftritt.


    Hast Du inzwischen rausbekommen, welcher Buffer da überläuft?


    Gruss, Ollo

  • nee, ich meinte ältere vdr-Version. Nimm doch statt 1.36 mal testweise 1.23. Und danach ggf. nochmal 1.3.17

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Hi Dr. Seltsam,


    ich bin immernoch an dem Problem dran und habe vielleicht eine Lösung gefunden...


    Bei meinem 2.6.14er kernel wird der cfq I/O Scheduler verwendet (cat /sys/block/hd?/queue/scheduler), der offenbar aktuell Probelem hat.


    Nun habe ich einfach bei den kernel boot options "elevator=anticipatory" angefügt und bei einem ersten Test scheinen die buffer overflow verschwunden zu sein - ebenso die Ruckler und Tonaussetzer beim Liveview während einer Aufnahme.


    Kannst Du das bestätigen?


    Gruß, Ollo

  • ich werde das einfach mal bei mir eintragen und beobachten, allerdings habe ich schon seit geraumer Zeit keine Probleme mehr. Das Live-AC3 hat den Transfermode ja schon erheblich entlastet.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

Jetzt mitmachen!

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