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

tomtom007 · December 10, 2013 at 7:45 AM

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

meikelmoeller · December 10, 2013 at 7:59 AM

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

tomtom007 · December 10, 2013 at 8:09 AM

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

pixelpeter · December 11, 2013 at 4:53 PM

Hallo Tom,

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

Peter

mini73 · December 11, 2013 at 5:00 PM

Quote from meikelmoeller

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.

meikelmoeller · December 11, 2013 at 5:29 PM

Quote from mini73

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 :).

frithjof · December 11, 2013 at 5:36 PM

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

tomtom007 · December 12, 2013 at 8:12 PM

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

jsffm · December 12, 2013 at 9:20 PM

Probiere mal folgenden Patch:

Diff

--- recorder.c.s        2012-09-22 13:53:57.000000000 +0200
+++ recorder.c  2013-04-07 02:13:53.000000000 +0200
@@ -10,7 +10,7 @@
 #include "recorder.h"
 #include "shutdown.h"


-#define RECORDERBUFSIZE  (MEGABYTE(20) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE
+#define RECORDERBUFSIZE  (MEGABYTE(100) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE


 // The maximum time we wait before assuming that a recorded video data stream
 // is broken:

Display More

mini73 · December 12, 2013 at 10:16 PM

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.

tomtom007 · December 13, 2013 at 8:16 AM

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/wiki/Performance/Buffered_File_IO

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

Gruß
Tom

Bax · January 7, 2014 at 12:37 AM

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

flobee · September 7, 2015 at 12:49 AM

Hi
Endlich mal wieder Zeit und stolpere auch über das Problem.
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
now

tomtom007 · September 7, 2015 at 10:39 AM

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.

flobee · September 13, 2015 at 6:08 PM

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

tomtom007 · September 14, 2015 at 12:51 PM

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.

Fourty2 · September 14, 2015 at 9:31 PM

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

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

Participate now!

Users Viewing This Thread