NAS Recording Ringbuffer Overflows ( VDR gebaut aus git auf neustem Stand )

  • Hallo,
    ich habe Probleme mit Aufnahmeverzeichnissen auf Netzwerk Shares seit einigen VDR Versionen.
    Nachdem es mit einem NAS auf der Fritzbox 7390 zu Problemen kam habe ich es auf den recht
    schwachen Durchsatz der Box um die 4MB/s geschoben. Nun nutze ich ein WD Cloud NAS System.
    Hier erreiche ich vom VDR mit kopieren aus dem /dev/zero auf den Share zwischen 30 und 50MB/s.
    Jedoch kommt es auch hier nach einigen Sekunden zum Ringbuffer Overflow und unbrauchbaren Aufnahmen.
    Ich habe die Puffergröße in recoder.c von 20MB auf 200MB hochgesetzt.
    Die einzige Auswirkung war, daß es etwa 10x länger dauerte bis es zum o.g. Problem kam.
    Testweise eingebrachte esyslog Ausgaben zeigen, daß mehr Daten in den Puffer reingeschrieben werden als
    herausgenommen und weggeschrieben werden.
    Sobald ich /video auf ein lokales Drive mappe, läuft es wunderbar.
    Ich fasse zusammen: Durchsatz vom NAS ist im Mittel hoch genug, Ringpuffer vergrößern beseitigt das Problem nicht.
    Daraus schließe ich, daß die Daten nicht häufig genug abgeholt werden, bzw. dort irgendwas bremst.
    Ich habe bereits viele ähnliche Meldungen gefunden, aber leider keine wirkliche Lösung.
    Hat jemand einen Hinweis bzw. was mag die Ursache sein ?
    Zur Zeit helfe ich mir damit, daß ich auf die lokale Platte aufnehme und am Ende der Aufnahme die Dateien auf das NAS verschiebe.


    Mfg.
    Tom


    Mein System: VDR mit SoftHDDevice aus dem git gebaut unter Debian x64 testing
    Shuttle Barebone Atom DualCore 1.8GHz, 4GB DDR3, ION Graphik und 64GB SSD
    2 x TeVii 660 USB DVB-S2 und 1 x Technisat SkyStar USB
    1 x Gigabit Ethernet zum 1GB -Switch und von dort 1GB Ethernet zum WD My Cloud 4TB NAS

  • Ist der Ringbuffer nicht eigentlich für Timeshift gedacht? Hatte ich zumindest so für mich interpretiert.


  • Das wäre dann ja nur ein 20MB entsprechend 10s Timeshift und fest einkompiliert.
    Kann ich mir eigentlich nicht vorstellen.
    Hängt es evtl. mit der Indizierung der Videodaten zusammen ?
    Die Abläufe dort habe ich noch nicht verstanden.
    Gruß
    Tom

  • Hallo Tom,


    Welches Protokoll nutzt du für das Videoshare?
    NFS, CIFS ?


    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • Ist der Ringbuffer nicht eigentlich für Timeshift gedacht? Hatte ich zumindest so für mich interpretiert.


    Ein Ringbuffer ist nur eine Datenstruktur für diverse Zwecke. Natürlich ist es sinnvoll, so einen für Timeshift zu benutzen. Aber man kann sowas auch an anderer Stelle benutzen.
    Dieser Ringbuffer ist für die Kommunikation vom Thread, der vom DVB-Device liest und dem/die anderen Thread/s, der/die die Daten weiterverarbeiten (Live-TV, Aufnahme usw.).
    Wenn hinten dran irgend jemand nicht schnell genug aus dem Ringbuffer liest und damit Platz für den Thread schafft, der da Daten ablegen soll, hat man ein Problem. Wo es aber hier im speziellen liegt, kann ich nicht sagen.


    In welcher Blockgröße schreibt der vdr denn in die Aufnahmedatei? Vielleicht muss man damit ein wenig herumspielen, damit es besser zum Netzwerk passt.


    Lars.

  • Ein Ringbuffer ist nur eine Datenstruktur für diverse Zwecke. Natürlich ist es sinnvoll, so einen für Timeshift zu benutzen. Aber man kann sowas auch an anderer Stelle benutzen.
    Dieser Ringbuffer ist für die Kommunikation vom Thread, der vom DVB-Device liest und dem/die anderen Thread/s, der/die die Daten weiterverarbeiten (Live-TV, Aufnahme usw.).
    Wenn hinten dran irgend jemand nicht schnell genug aus dem Ringbuffer liest und damit Platz für den Thread schafft, der da Daten ablegen soll, hat man ein Problem.


    Besten Dank für die Erklärung, man wird hier jedenfalls nicht dümmer wenn man aufpasst :).


  • Ich habe ebenfalls Platten über NFS eingebunden.
    An dem NFS server hängen auch externe USB Platten.


    Schiebe ich da z.B. mit krusader (MC für Mausklicker) mehrere Dateien a 200MB rüber, dann
    werden die Dateien selbst schnell übertragen, aber am Ende jeder Datei, wenn diese geschlossen wird,
    hakt es z.T. mehrere Sekunden. In diesen Sekunden friert krusader praktisch ein und reagiert weder auf
    Maus noch Tastatur.


    Sollte der VDR nach dem Schreiben von Videodaten die Datei ebenfalls schließen, kommt es
    wahrscheinlich ebenfalls zu dieser Pause und der Puffer läuft über.


    Ersetze mal bei der NFS Serverfreigaben die Option sync durch async.


    Das ist natürlich ein Risiko, also nur zum Testen

    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)

  • Hallo,
    das NAS ist ein fertig gekauftes System mit CIFS.
    NFS ist "out of the Box" leider nicht verfügbar.
    CIFS hat bei jedem Zugriff Latenzzeiten.
    Ich weiß jetzt nicht, in welchen Blockgrößen VDR schreibt.
    Es sind im fortlaufenden Stream ja zumindest zwei Dinge
    a) die DVB -Datenpakete
    b) der Index auf die "Bilder" im Stream
    Ob das zwischengepuffert wird oder jeder kleine Datensatz einzeln geschrieben wird wäre hier auch meine Frage.
    Wenn dem so wäre, hilft wohl nur die lokale Zwischpufferung auf Datenträger
    und Wegschreiben nach Ende der Aufnahme auf das NAS.
    Falls aber die Writes gepuffert werden, wäre meine Frage wo dies geschieht und ob man die Puffer vergrößern kann.
    Gruß
    Tom

  • Probiere mal folgenden Patch:



    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Moin!


    Das ist ja die Größe des Ringbuffers, die hat er schon hochgesetzt (so interpretiere ich seine Aussage im ersten Post).
    Interessanter ist da eher cRecorder::Action, weil da die Daten in die Datei geschrieben werden.


    So wie ich das verstehe, wird immer ein kompletter Frame mit Hilfe eines cUnbufferedFile weggeschrieben. Und alle 800KB ruft der vdr posix_fadvice auf, um dem Kernel mitzuteilen, dass die Daten nicht gecachet werden müssen, weil sie sowieso nur weggeschrieben werden.


    Ich würde testweise mal das "#define USE_FADVISE" ausklammern, um zu schauen, was dann passiert. Vielleicht kommt NFS damit ja nicht zurecht.


    Ansonsten ist es an der Stelle nicht ganz so einfach, die Blockgröße für das Schreiben der Daten zu ändern.


    Lars.

  • Hallo,
    ich habe dann mal weitergesucht und letztendlich führt das Schreiben zumindest des Indexfiles zu einem Aufruf von write().
    Die ist die ungepufferte I/O -Schnittstelle im Gegensatz zu fwrite() etc.
    Jetzt kenne ich den Grund hierfür nicht.
    Nach K&R reduziert die gepufferte I/O mit den fxxx() Funktionen ja die Systemaufrufe,
    was gerade bei Dateien "auf dem Netz" erhebliche Latenzzeiten sparen soll,
    weil eben weniger echte write() aufgerufen werden.


    Siehe auch: https://wiki.openoffice.org/wi…formance/Buffered_File_IO


    Evtl. kann KLS hier klären, warum die ungepufferte I/O Schnittstelle notwendig ist.


    Gruß
    Tom

  • Hi!


    Hat sich inder Sache noch was ergeben?


    Könnte sein, dass im Thema 121538-yavdr-0-5-headless-ard-zdf-hd-aufnahmen-error-1-ring-buffer-overflow/ eine ähnliche Ursache zugrundeliegt. Die Symptomatik passt jedenfalls.


    (konkret: yavdr 0.5, vdr 2.03, nas, puffer läuft bei Aufzeichnungen voll, aber nicht auf allen sendern)


    Danke für alle Inputs!!
    lg
    Bax

    VDR neu: AMD 64X2 4050e - 2GB Ram - 3,5TB HDs - Nexus 2.1 - Nova HD S2 - WinTV-T USB - Cinergy S2 PCI CI -
    Ubuntu 10.04 - yavdr stable ppa -
    remote - epgsearch - extrecmenu - live - skinelchi - streamdev - streamplayer - vodcatcher - xine - gallery2 - twonkymedia
    VDR2 SMT: 7020S, 80 GB - Dreambox 7000s (derzeit defekt)
    VDR3 Acer Revo 3610 mit yaVDR 0.2 - TT DVB-S2 USB

  • Hi
    Endlich mal wieder Zeit und stolpere auch über das Problem. :rolleyes:
    Das NAS via Samba eingehängt und nach und nach läuft das syslog voll. Aber: Bei zwei aufnahmen gleichzeitig ( bwm-ng meldet dennoch wenig Netzwerkrauschen)
    Ist ja schon eine weile her dieses Thema. Gibt es Lösungen oder wie habt ir es dann gelösst?
    Ich wollte gerade weg von meinem 24/7 Dauerbetrieb des Laptops und einen raspi2 anstelle benutzen.
    Aber wenn die Leitung das nicht mit macht... auf sd card schreiben wird wohl eher ein Abenteuer :] (Wobei der hängt an einem schnelleren switch und muss nicht durch den router... Ich bin mal gespannt)


    LG Florian
    :sleep now

    Community Doks: https://vdr-projects.github.io/


  • Hallo,
    ich habe die Problematik bisher dadurch umgangen, daß ich auf die lokale SSD aufgezeichnet habe
    und nach Ende der Aufnahme in rec.cmd die Daten auf die Cifs -Freigabe geschoben habe.
    Wiedergabe von Cifs war ja kein Problem, nur die Aufnahme schlug fehl.
    Letzte Woche fand ich nach einem Firmware Update meiner WD MyCloud NAS einen nfs Server vor ;)
    Ein schneller Test mit einer HD Aufnahme funktionierte gut, danach klappte es auch mit zwei und drei Aufnahmen gleichzeitig.
    Fazit: auf der gleichen Server Hardware geht mit cifs nicht ein Stream fehlerfrei, mit nfs aber sogar drei gleichzeitig.
    Nfs Puffergrößen stehen auf default, asynchrone Übertragung.

  • Danke für die Rückmeldung!


    Nun ist das nfs4 im Einsatz aber hier kann ich nur zeitlich eine Verbesserung erkennen (mehr zeit bevor Probleme kommen).
    Auffällig das es unterscheide zwischen dvb-C und T gibt ohne eine genauere Erklärung geben zu können.
    Mit dem Sundek Dongel ist die ring buffer Meldung zügiger wieder da als mit dvb-t.
    Um das weiter ein zu grenzen habe ich jetzt die test hardware (Raspberry Pi 2, rasbian testing/jessie) und nur den Sundek Dongel mit DVB-C im Einsatz (insgesamt laufen 34 Prozesse und mit oder ohne Aufnahme zeigt die cpu last ca. 5-20%. Der buffer macht sich bemerkbar aber läuft noch nicht über. Allerdings, und das nervt total: Alle aufnahmen ruckeln hier und da ohne die Erklärung zu finde :-/ (Gefühlt darf ich vdradmin-am während der Aufnahmen scheinbar gar nicht benutzen :-(.
    Der raspi müsste das doch eigentlich tun, oder? Der load bleibt unter 1, Netzwerk meldet etwa Peaks von 5MB/s ... also eigentlich alles im grünen. ?


    Demo Aufnahme:
    - drei Aufnahmen gleichzeitig
    - vdradmin-am nicht benutzt
    - 1626 - 1700 Uhr
    - bei Aktivierung des dritten Timers hat sich der vdr einfach selbst neu gestartet: syslog ohne weitere infos, nur das hier: "Sep 13 16:27:06 pi2 runvdr: restarting VDR" .. und hat dann seinen dienst getan.


    Code
    root@pi2:~# cat /var/log/syslog | grep -i buffer | less
    Sep 13 16:27:38 pi2 vdr: [29434] TS buffer on device 1 thread started (pid=29413, tid=29434, prio=high)
    Sep 13 17:00:00 pi2 vdr: [29413] buffer stats: 247784 (1%) used
    Sep 13 17:00:00 pi2 vdr: [29413] buffer stats: 216200 (1%) used
    Sep 13 17:00:00 pi2 vdr: [29413] buffer stats: 323172 (1%) used



    Das hier als Report und in den Raum geworfen. Eine Konkrete Frage kann ich nicht stellen da mir die Problem-Lokalisierung noch fehlt :) Ausser "Es wackelt und stört" und muss den raspi mit svdrpsend anschupsen da alles andere zu viel power frist.


    Freue mich auf Feedback, ideen


    LG Florian

    Community Doks: https://vdr-projects.github.io/


  • Hallo nochmal,
    wenn ich Raspberry Pi 2 lese kann ich mir schon vorstellen, daß er auf dem nfs share beim Aufnehmen so an die Grenzen kommt.
    Man könnte die Zahl der Netzwerk Schreibzugriffe "testweise" mal verringern,
    indem man die Indexdatei während der Aufnahme nicht miterzeugt.
    Das sollte dann später bei ersten Zugriff auf die Aufnahme passieren.
    Ich hab das allerdings noch nicht ausprobiert,
    da ich zwischenzeitlich die Lösung mit dem Wechsel von cifs auf nfs gefunden habe.
    In recorder.c in cRecorder::cRecorder() die Zeile "index=" auskommentieren wäre mein Plan gewesen.

  • Hallo,


    also die Abstürze bei laufenden Aufnahmen kann ich auch auf einem "richtigen" PC-VDR provozieren,
    bisweilen auch unabsichtlich:


    - Im Kernel File-Caching aktivieren
    - 2 GB oder mehr freien RAM (für max. 2 GB Dateien)
    - Aufnahme(n) starten
    - dann einen Film per SSH-Session mit vdr-checkts prüfen


    Im Log findet sich dann bald die I/O Throttle und anschließend der Emergency Exit.


    Grüße,
    42

Jetzt mitmachen!

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