VDR-Optimierungen bei größeren Aufnahmevezeichnissen

bakaroo · 4. November 2023

Hallo,

Nachdem ich nun den Plan gefasst hatte, unsere diversen VDR-Maschinen zusammenzufassen (grundsätzlich alle EPG + Aufnahmen zentral (nfs) + Nur ein Aufnahme-VDR mit dann 4+2 Eingängen, andere VDR nur noch Clients), musste ich feststellen, daß ein Laden der Aufnahmeliste ewig braucht - ca 7min) und die die Clients dann den RAM ziemlich voll nehmen.

Okay das sind dann bei mir ca 24TB mit ca 8000 Aufnahmen.

Auch schaffen die VDRs es nicht, beim Einschalten sich eine vollständige Liste zu holen. Sie benötigen mindestens 1x "Aufnahmeliste aktualisieren". Und die beiden kleinen mit nur 2GB RAM stürzen dann gelegentlich mal ab.

Meine Überlegung ist nun, die Aufnahmeliste in den SQL-Server zu packen, der schon fürs EPG rumwerkelt.

So könnte ein "SELECT * from Recordings LIMIT p,12 Order by Date" (wobei hier p ein vielfaches von 12 ist, als Seitenzähler).

sich problemlos häppchenweise die Liste holen. Die Gesamtzahl an Aufnahmen und -stunden liesse sich dabei auch einfach ablegen.

Gibt es sowas eventuell schon oder muß ich mich mal über recordings.c hermachen?

SurfaceCleanerZ · 4. November 2023

Hi,

Was für ein Dateisystem ist es denn? Ich denke auch dss hat Einfluss.

Aber ich kenne das von 5TB auch schon.

MfG Stefan

bakaroo · 5. November 2023

Auf den Festplatten sind normale ext4 und xfs Dateisysteme, je (alten) Client zw. 4-8TB brutto, basierend auf Ubuntu und Debian. Diese Platten habe ich spasseshalber mal in eine Kiste gepackt, mit einer dieser VDRs gestartet, die anderen lokal in Unterverzeicnissen unter Video hinzugemountet sowie per nfs4 exportiert. Ergo: alles ganz normal.

An einem Client dann probeweise per NFS-Client als Aufnahmeverezeichnis gemountet und auf diese Weise einem VDR mal den ganzen Stapel an Aufzeichnungen vorgehalten. Obwohl der zu messende Datendurchsatz (6,5 GB in unter zwei Minuten per cp von remote file zu local file) mehr als ausreichend ist, ist ein Verzeichnisscan in der Größe nicht wirklich was für Ungeduldige.

SHF · 5. November 2023

Der Server sollte doch eine Aufnahmeliste haben.

Mit SVDRP LSTR kann man die abrufen und müsste die dann "nur" importieren, aber ich weiss momentan nicht, ob da alle nötigen Informationen dabei sind.

Zumindest könnte man das mal in eine Datei dumpen und schauen, wie groß das überhaupt ist.

8000 Aufnahmen sind auch eigentlich nicht so viel, dass man 2GB RAM dafür brauchen würde.

Die Beschreibung ist das Einzige, was mir einfällt, was wirklich Platz brauchen könnte, wenn es im RAM vorgehalten würde.

Falls die Beschreibungen wirklich im RAM liegen, könnte man da vielleicht sparen und die bei Bedarf nach laden.

Ich als User sehe mir die Beschreibung eher selten an und wüsste auch sonst nichts, was die dauernd bräuchte. Wobei ich da durchaus was übersehen haben könnte.

(EPGserch verwendet AFAIK jedenfalls eigene Dateien für erledigte Aufnahmen und braucht nur die Beschreibung im EPG.)

msv · 5. November 2023

ja, es ist schon ein träges Geschäft. Hab auch 9Tb als raid5 am Server mit headless VDR als Aufnahmeserver. Wenn ich dann auf meinem Desktop meinen client starte mit dem nfs gemountetem Aufnahmeverzeichnis gehe ich mir immer erst mal einen Kaffee kochen, ehe ich dann die Aufnahmen schneide. Ich würde gerne die auf dem Server eingelesenen Aufnahmeinfos direkt übernehmen wollen als Dateitransfer, sowie man das ja auch mit der epg.data machen kann.

Also meine c++ Kenntnisse sind dafür nicht ausreichend, aber vielleicht hat ja jemand Lust und Zeit sowas zu entwickeln. Ich würde dann gerne beim testen mithelfen.

Gruß

msv

bakaroo · 5. November 2023

Ich denke auch nicht, daß das 2GB Ram ausmacht, aber Pi mal Daumen 0,5-1KB Ram je Aufzeichnung kann man rechnen:

Verzeichnisbaum je Aufzeichnung (beinhaltet Name und Auzeichnungsdatum), Beschreibung aus info.vdr, etc.

Aber wenn eine Maschine nur zusammen 2GB hat, muß dort das gesante OS, alle aktiven Dienste und Buffer, der VDR ansich und ggf noch Dinge wie VDRadmin, Lighthttpd, Samba, etc rein. Ein normaler x86-Ubuntu-VDR braucht schon ca 1,5GB. Dann noch va 16-256MB für Grafikspeicherfenster und andere IO-Ranges abziehen, schon füllt sich Swap.

Der Server hat eine Aufnahmeliste in seinem VDR liegend. Von daher kein Unterschied zum Client-VDR.

Richtig ist, daß das scheibenweise Importieren womöglich die Lösung ist. Von daher ja das "SELECT ... LIMIT 12", es liefert dann die Liste seitenweise an den VDR.

Dazu müsste aber recordings.c so umgebaut werden, daß die Liste nicht per "full Directoryscan to Ram", sondern OnDemand in Scheiben geliefert werden. Damit hat aber der VDR keinen Überblick mehr über die Gesamtheit der Aufzeichnungen, was wiedrum Änderungen an der Gesamtanzeige "xxx Minuten Frei" oder der Verwaltung alter Aufnahmen bei begrenzten Platz notwendig macht. Ein ziemlicher Rattenschwanz.

MarkusE · 5. November 2023

Einen 8 GB Server kaufen?

Swap nutzen zum Auslagern?

> Die Beschreibung ist das Einzige, was mir einfällt, was wirklich Platz brauchen könnte, wenn es im RAM vorgehalten würde.

> Falls die Beschreibungen wirklich im RAM liegen, könnte man da vielleicht sparen und die bei Bedarf nach laden.

Die Beschreibung liegt im RAM. Und ja, es müsste möglich sein VDR so zu patchen, dass VDR die Beschreibung beim Einlesen der Aufnahmen in eine DB schreibt, und dann von dort bei Bedarf holt.

Oder VDR ignoriert die Beschreibung beim Einlesen der Aufnahmen, und holt sie bei Bedarf aus der Info Datei.

~ Markus

kamel5 · 5. November 2023

Zitat von bakaroo

Diese Platten habe ich spasseshalber mal in eine Kiste gepackt, mit einer dieser VDRs gestartet, die anderen lokal in Unterverzeicnissen unter Video hinzugemountet sowie per nfs4 exportiert. Ergo: alles ganz normal.

Heist das jetzt, wen Du die Platten direkt an einen von den VDR's anschließt, die sonst nicht richtig funktionieren oder langsam sind, geht es dann ohne Probleme. Das würde dann doch eher auf ein Konfigurationsproblem hinweisen.

Apropos Ladedauer: bei mir dauert das einlesen vom Server (ca.11000 Aufnahmen) etwa 1min (nach einem Server Neustart). Wenn der Server Cache befüllt ist, weniger als die Hälfte der Zeit.

Zitat von bakaroo

Auch schaffen die VDRs es nicht, beim Einschalten sich eine vollständige Liste zu holen.

Das Einlesen hat einen Timeout. Wenn die Daten vom Server nicht mehr kommen, wird lokal weiter gemacht. Ich nutze das z.B. um den VDR auch ohne aktivem Server zu starten.

Zitat von bakaroo

Sie benötigen mindestens 1x "Aufnahmeliste aktualisieren".

Das deutet doch darauf hin, das der Server die Daten nicht schnell genug liefert.

Zitat von bakaroo

Und die beiden kleinen mit nur 2GB RAM stürzen dann gelegentlich mal ab.

Was läuft den da noch so drauf? Wenn es nur der VDR ist, sollte das eigentlich reichen.

Zitat von bakaroo

Dazu müsste aber recordings.c so umgebaut werden, daß die Liste nicht per "full Directoryscan to Ram", sondern OnDemand in Scheiben geliefert werden.

Man könnte da sicher einiges optimieren, die Frage ist allerdings, mit welchem Aufwand und ob es dann auch hilft.

Grüße

kamel5

bakaroo · 5. November 2023

Richtig, man kann natürlich einen neuen Server kaufen. (hier war ein älterer AthlonX4 mit DDR2-Board am Start. Leider waren und sind DDR2-RAMs >1GB eher ungebräuchlich gewesen).

Aber in der jetzigen Fassung vonRecordings.c wird sowohl beim Server als auch bei den Clients dieselbe Strategie zum Erstellen der Aufnahmeliste gemacht. Demzufolge benötigen auch die Clients entsprechend RAM und Zeit. Bei X86-PCs geht das nachzurüsten, aber was passiert mit ClientVDRs auf Raspi oder CoreELEC-Basis?

Lediglich die Beschreibung auszulagern sollte zumindest die RAM-Last drücken, aber ich sehe das nur als halben Weg. Ein VDR muß immer noch durch den vollständigen Verzeichnisbaum durch und sich per 'stat' die Dateigröße der .ts-Dateien holen, das Aufnahmedatum aus dem darüberliegenden "xxx.rec/del"Verzeichnisnamen holen und dann zum nächsten Eintrag in der Verzeichnisliste gehen.

Worst Case:

Wenn dann noch der VDR nicht nur die Aufnahmen bereithält, sondern gleichzeitig noch als NAS dient (was zwar nichts mit den Aufgaben des VDR-Servers zu tun hat, ich aber nicht für abwegig halte), liegen dort auch Verzeichnisse und Dateien anderer Art, wobei der VDR diese Verzeichnisse ebenfalls erfolglos aber zeitraubend) durchkämmt.

Klar kann man in so einem Fall empfehlen, ein getrenntes Samba-Share bzw ein extra-NFS-Export zu machen, aber das bedarf auf Clientseite ein extra mount (= Extra Unterverzeichnis) bzw einen extra Laufwerksbuchstaben.

Mal die Hand hoch: wer betreibt den VDR als Server für andere Clients (VDR, Kodi oder Sonstwas) und hat _nicht_ auch andere Archive im gleichen Share?

Klar kann man in so einem Fall empfehlen, ein getrenntes Samba-Share bzw ein extra-NFS-Export zu machen. aber das bedarf auf Clientseite ein extra mount (= Extra Unterverzeichnis) bzw einen extra Laufwerksbuchstaben.

kamel5: nein die Platten laufen ohne Probleme, sie haben allesamt keine nennenswerten Fehler (im Sinne von im syslog eingetragenen Fehlermeldungen; lediglich smartmon gibt schon Zahlen Richtung Null gehend raus - die neuesten sind es nicht).

Die Dateisysteme sind fehlerfrei und der Datendurchsatz selbst ist auch okay. Es ist auch nicht das Problem der Platten, Dateisysteme, oder Konfig, sondern einfach nur die Summe der zu bearbeitenden Datenverzeichnisse.

Auf den beiden kleinen VDRs läuft normalerweise ein einfaches EasyVdr5 mit 1x streamvdr-Client bzw einer alten ein-Kanal-Terratec (?) und einer lokalen 4TB bzw 6TB-Platte. Damit gibt es auch keine Probleme. Auf den kleinen läuft auch nichts anderes, selbst Cups, avahi und NetworkManager samt all seiner sinnlosen Helferlein sind dort raus.

Ich hatte unter der Woche nur alle mal zusammengesteckt in eine Kiste und dabei obiges beobachtet.

Ich gehe also mal von euren Infos aus, daß es dahingehend noch nichts gibt, aber es ein paar vergleichbare Erfahrungen gibt.

Dann werde ich wohl mal den Quelltext lesen müssen, einen Plan machen und schauen, ob ich das dann auch umgesetzt krieg.

Nachtrag:

> Apropos Ladedauer: bei mir dauert das einlesen vom Server (ca.11000 Aufnahmen) etwa 1min (nach einem Server Neustart). Wenn der Server Cache befüllt ist, weniger als die Hälfte der Zeit.

Ähm, nach meinen Verständnis lädt ein VDR-Client die Aufnahmeliste nicht vom vom VDR-Server (hier als Programm gemeint), sondern holt sie sich aus dem Verzeichnisbaum des angebotenen Share, quasi per opendir(). Daß ein VDR-Server den kompletten Verzeichnisbaum im Filesystem-Buffer hat, würde ich mal optimistisch als "Zufall" betrachten.

M-Reimer · 5. November 2023

Eigentlich ist das hier angesprochene Problem meiner Meinung nach nur Bestandteil einer größeren Baustelle.

Ich hatte das vor, ich glaube mittlerweile schon Jahren, schonmal irgendwo angemerkt, dass ich eigentlich liebend gerne für Kodi ein PVR-Addon schreiben würde, das direkt auf VDR-Schnittstellen verbindet. Die ganze VNSI-Schnittstelle wurde vor Jahren vom ursprünglichen Entwickler aufgegeben. Plugins für den VDR haben leider so eine Tendenz irgendwann keinen Maintainer mehr zu haben (vnsiserver, streamdev). Auch wenn ich tvheadend nicht für besonders gut halte (meiner Meinung nach tendentiell ein totes Projekt) haben die doch einen Vorteil: Ein Protokoll direkt zum "Server" in dem alles kommuniziert werden kann.

Klaus hat da mal einen ersten Schritt gemacht und eine Lösung erarbeitet wie sich VDR-Systeme untereinander finden können. Leider wurde das nie "zu Ende geführt". Mehr wie Timer sharen geht damit nicht.

Eigentlich sollte das Ziel sein das der VDR irgendwann mal komplett netzwerktransparent wird. Also nicht nur Timer über die bereits vorbereiteten Schnittstellen übertragen, sondern im Idealfall verbinde ich von meinem Client einfach mit dem Server. Mehr nicht. Nur der Server muss wissen wie die Aufnahmen heißen und wo sie liegen. Und wenn ich vom Client eine Aufnahme wiedergeben will, dann sagt mein Client das dem Server und der Server streamt mir das Video rüber. Ich will da gar nicht noch mit NFS oder wasweißich rumfummeln müssen. Gleiches mit Live-TV. Für das Streaming sollte der VDR sorgen. Zusätzliche Plugins sollten da gar nicht nötig sein.

kamel5 · 5. November 2023

Zitat von bakaroo

Ähm, nach meinen Verständnis lädt ein VDR-Client die Aufnahmeliste nicht vom vom VDR-Server (hier als Programm gemeint), sondern holt sie sich aus dem Verzeichnisbaum des angebotenen Share, quasi per opendir().

Ich meinte, rein über nfs. Auf meinem Server läuft kein VDR.

Zitat von bakaroo

Daß ein VDR-Server den kompletten Verzeichnisbaum im Filesystem-Buffer hat, würde ich mal optimistisch als "Zufall" betrachten.

Ich habe mich vor Jahren, genau aus diesem Grunde (hohe Anzahl von Aufnahmen auf dem Server auf HDD ist natürlich beim Einlesen langsam) für zfs als Filesystem entschieden. Dadurch kann ich als Dateisystem-Cache eine SSD verwenden. Aber auch nach einem Server-Neustart, da ist der SSD-Cache noch leer, dauert es bei dieser Menge nur ca. 1min.

Was ich damit auch nur sagen will, bevor man am VDR selbst etwas ändert, sollte man sich sicher sein, alle anderen Möglichkeiten ausgeschöpft zu haben.

Zitat von bakaroo

Obwohl der zu messende Datendurchsatz (6,5 GB in unter zwei Minuten per cp von remote file zu local file) mehr als ausreichend ist, ist ein Verzeichnisscan in der Größe nicht wirklich was für Ungeduldige.

Das ist ja z.B. nur die halbe Miete. Das Einlesen der Aufnahmen bedeutet Lesen vieler kleiner Dateien (random seek).

Die Platten in meinem VDR sind z.B. älter als die Platten in meinem Server, da dauert das Einlesen gefühlt auch deutlich länger.

Und klar, solche Probleme sind auch manchmal schwierig zu beheben.

Grüße

kamel5

bakaroo · 5. November 2023

Okay das wäre natürlich auch ein Weg, aber vermutlich keiner, der bei mir erste Wahl wäre. ZFS das zugrundeliegendes Filesystem zu nutzen, wäre schon eine einfache und pragmatische Lösung, wirft dann aber andere Hürden auf die ich persönlich nicht nehmen möchte. ZFS bedingt FreeBSD. Gibts als NAS schon sogar zum "zusammenklicken", schließt aber den VDR aus. Demzufolge brauchst du ein NAS und entweder einen weiteren Server-VDR oder die VDRs als full-Device.

Von den vielen Geräten wollte ich eigentlich weg, ohne den Komfort der lokalen VDRs einzubüßen. Ein extra NAS wäre eine weitere ausgewachsene Maschine.

Auch behandelt das auch nur die Symptome und nicht die Ursache.

Richtig ist: Die Angabe der Kopiergeschwindigkeit hat wenig mit der Leseleistung der Aufnahmeverzeichnisse zu tun. Da hilft tatsächlich ein großer Cache fürs Filesystem. Aber die Kopiergeschwindigkeit zeigt, daß es eine normale 1000BaseT-Verbindung ist, die ihren heimüblichen Nettodurchsatz schafft, hier also nicht das Nadelöhr ist.

Wenn aber von den Clients gar kein DirectoryScan notwendig ist, sondern, wie M-Reiner beschrieb, ein Serverdienst (ich lege mich mal nicht auf den VDR selbst fest) diese Liste hält, und den Clients seitenweise vorgekaut gibt, ist der Arbeits- und Speicheraufwand auf der Clientseite fast gleich null. (Okay, Seitenabfrage per SQL o.ä. senden, Ergebnis anzeigen.. das sind schon ein paar Millisekunden). Und es ist skalierbar.

Beim Essen habe ich ein wenig darüber gegrübelt.

-recordings.c bekommt einen Umschalter, um zwischen herkömmlichen dirScan und Verzeichnisdienstabfrage umzukonfigurieren.

-der neue Codebereich bekommt eine Funktion zur Abfrage je Bildschirmseite. Dazu muß er wissen, wieviele Zeilen je OSD-Menuseite bei eingestellter Schriftgröße er darstellen kann. (daraus wird beim VDR-Start Schrittweite und Abfragelimit errechnet). Er braucht dann auch nur Speicher für diese eine Seite. (ggf drei für ein Prefetch in jede Richtung).

-Er bekommt per gesonderter Abfage Infos über Gesamtkapazität in MB und Minuten.

-Noch nicht ganz klar ist, wo überall Änderungen wg Dateioperationen notwendig werden (Umbenennen, Schneiden, Aufnahmeliste aktualisieren, weil ein anderer VDR Operationen durchführt etc). Hier sehe ich eine riesen Rattenschwanz an Kleinständerungen auf mich zukommen - von Änderungen in Plugins will ich noch nichtmal reden.

-Auf Serverseite könnte entweder der VDRserver das via SVDRP übermitteln und selbst verwalten (womit das Problem aber nur hierher verschoben wird) oder aber ein extra Dienst/Plugin schruppt über das Aufnahmeverzeichnis und legt alles in SQL oder LDAP ab. Damit wäre auch ein unabhängiger Zugriffsweg für Kodi und Konsorten offen.

Hab ich was übersehen?

kamel5 · 5. November 2023

Zitat von bakaroo

ZFS bedingt FreeBSD.

Nicht unbedingt. Das kann man auch in normalen Linux-Distributionen nachinstallieren...

Zitat von bakaroo

Beim Essen habe ich ein wenig darüber gegrübelt.

Das ist natürlich ein beträchtlicher Aufwand für dieses Ziel.

Das was der VDR im Speicher von den Recordings vorhält, wird ja in einer Liste cList<cRecording> gespeichert. Vielleicht wäre es einfacher mal darüber nachzudenken, diese Liste beim Beenden des VDR lokal abzuspeichern und beim Starten wieder einzulesen und dann nur noch ein Update zu machen. Dann könnte der Rest so bleiben wie er ist.

Grüße

kamel5

msv · 5. November 2023

Zitat

Das was der VDR im Speicher von den Recordings vorhält, wird ja in einer Liste cList<cRecording> gespeichert. Vielleicht wäre es einfacher mal darüber nachzudenken, diese Liste beim Beenden des VDR lokal abzuspeichern und beim Starten wieder einzulesen und dann nur noch ein Update zu machen. Dann könnte der Rest so bleiben wie er ist.

... und stände dann auch gleich dem Client zur Verfügung

gruß

msv

SurfaceCleanerZ · 5. November 2023

Hi,

Bedenke dass easyvdr 5 eine alte VDR Version nutzt, die nicht für Client-Server Umgebungen gedacht ist.

MfG Stefan

SHF · 6. November 2023

Zitat von bakaroo

Ich denke auch nicht, daß das 2GB Ram ausmacht, aber Pi mal Daumen 0,5-1KB Ram je Aufzeichnung kann man rechnen

Ich hatte großzügig mit 2kB gerechnet und kam auf 16MB gesamt.

Das Sparpotential ist also eher begrenzt, zumal das EPG bei mir etwa das 10fache benötigt.

Das Problem wird wohl eher wo anders liegen.

Zitat von MarkusE

Die Beschreibung liegt im RAM. Und ja, es müsste möglich sein VDR so zu patchen, dass VDR die Beschreibung beim Einlesen der Aufnahmen in eine DB schreibt, und dann von dort bei Bedarf holt.
Oder VDR ignoriert die Beschreibung beim Einlesen der Aufnahmen, und holt sie bei Bedarf aus der Info Datei.

Das war auch meine Idee, wenn man unbedingt RAM sparen will.

Da kennt der VDR alle Aufnahmen, lediglich der Zugriff auf die Beschreibung wird etwas langsamer.

Das könnte gehen und der RAM-Verbrauch würde sich geschätzt halbieren.

Nur einen Teil der Aufnahmen einlesen wird nicht klappen, befürchte ich.

Spätestens wenn ein Plugin parallel zum Menü auf das Aufnahmeverzeichnis zugreifen will, wird es extrem kompliziert.

Zitat von kamel5

Vielleicht wäre es einfacher mal darüber nachzudenken, diese Liste beim Beenden des VDR lokal abzuspeichern und beim Starten wieder einzulesen und dann nur noch ein Update zu machen.

Die Idee war mir Zwischenzeitlich auch gekommen, das würde auch generell den Startvorgang beschleunigen.

Die Datenmenge kann bei der Übertragung an den Client auch nicht der Flaschenhals sein, dazu ist es einfach zu wenig.

Der Directoryscan wird durch irgend was anderes ausgebremst.

Entweder die Hardware (HDD), eine Einstellung am Server oder sonstwas.

Letztens hatte jemand Probleme beim Videodirectoryscan mit 'Too many open files' auf dem NFS-Sever.

Wobei das Durchsuchen der vielen Verzeichnisse schon anspruchsvoll ist. Aber eventuell kann man da auch noch was, durch entsprechende Optionen, optimieren?

Mein Videoverzeichnis ist übrigens zweigeteilt:

video0 ist eine kleine SSD und video1 eine große HDD.

Als Folge landen die Metadaten auf der SSD und die Videos auf der Festplatte. Ein Directoryscan ist also dementsprechend schnell.

Exportiert wird das über SAMBA, das löst die Symlinks auf.

Allerdings greift bei mir kein VDR-Client auf die Aufnahmen zu, ich kann also nicht sagen, wie gut das da funktionieren würde.

VDR-Optimierungen bei größeren Aufnahmevezeichnissen

Jetzt mitmachen!

Teilen