VDR, CPU Last bei Aufnahmen reduzieren?

  • Hallo,


    wäre es möglich, die CPU Last des VDR bei Aufnahmen zu reduzieren?

    z.B. indem der Index erst nach der Aufnahme generiert wird?


    Oder Code / Compiler -Optimierungen?


    Wozu braucht der VDR denn die CPU beim Aufnehmen?


    Grund der Frage: Mein sheevaplug mit VDR 2.4 hat folgende CPU Lasten:



    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Klingt nach unpassender Hardware Auswahl.


    Zu viele Geräte am USB beispielsweise.

  • Wozu braucht der VDR denn die CPU beim Aufnehmen?

    Hast du mal mit top geschaut, wie viel davon I/O bedingte Zwangspausen sind (wa Feld)?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Also, TOP sieht so aus:



    0.0 wa sieht eigentlich gut aus.

    Und ja, die Festplatten hängen an dem USB, an dem auch die Empfänger hängen.


    Aber: Wenn der USB das Bottleneck ist, warum geht dann die CPU Last vom VDR hoch?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich schreibe jetzt mal testweise die Daten auf einen anderen Server. Damit gehen über USB nur noch die 2 DVB Sticks. Die Last sieht etwas besser aus:



    Trotzdem bin ich mit 69.4 (vdr) + 26.3 (mediasrv) an der oberen Grenze

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Was für Plugins laufen auf dem Server?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • und so'n Sheeva Plug ist ja auch kein Performancewunder, meinen hab' ich schon vor einiger Zeit in den Ruhestand geschickt...

    Zum Guggen: yavdr0.6 + Silverstone GD04 + Intel DH57DD + Intel G6950 + Nvidia GT630 + Unicable/Jess-Sat (JPS0501-12) mit DD/L4M Max8 + 4TB WD-red + bequiet SFX300W
    Zum Testen : yavdr-Ansible + GMC Toast + B365M+i3-8100+ Nvidia GT1030 + L4M CineS2v6 o. SAT>IP Plugin mit DD-O'net
    VaaS (VDR-as-a-Service): yavdr06 + ML03+DH67BL+G530+2GB RAM + 2TB WD-EARX + Zotac GT610 + L4M v5.4 + bequiet SFX300W
    Squeezeboxserver: DN2800ML im Streacom F1CS NAS: HP ProLiant MicroServer NL36+ Smart Array P212

  • Hallo,


    Ich habe epgsearch und live. Denke jetzt mal nicht, dass die mehr Last während einer Aufnahme verursachen als ohne Aufnahme.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • epgsearch kann während der Suchtimer-Updates ziemliche Lastspitzen erzeugen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    ich habe mal einen Patch geschrieben. Damit schreibt VDR die PMT nur noch einmal (am Anfang), außerdem wird index nicht generiert. Außerdem können die TS Dateien nicht mehr gesplittet werden.


    Dafür kann ich jetzt 2 HD Aufnahmen gleichzeitig machen, ohne Pufferüberlauf :) .


    Den index generiere ich jetzt, wenn die Aufzeichnung beendet ist.


    ~ Markus

  • Hallo,


    Ich habe jetzt noch einen 2. Patch, der die Puffer vergrößert.

    Damit kann ich 4 HD Aufzeichnungen von 2 verschiedenen Transpondern machen (ich habe 2 USB DVB-S Sticks).

    Auch, wenn ich gleichzeitig noch VDR kompiliere, epgsearch einen Suchlauf macht, ... bekomme ich 4 fehlerfreie HD Aufnahmen :) .


    Und jetzt der Nachteil: VDR kann die Aufnahmen nur von vorne abspielen. Springen in der Aufnahme funktioniert, aber beim Resume bleibt das Bild schwarz. Geschnittene Aufnahmen, bei denen der Anfang rausgeschnitten wurde, gehen auch nicht :( .


    Liegt wohl daran, dass die PMT nur am Anfang jeder Datei ist. Kodi hat damit keine Probleme, da geht auch resume .


    ~ Markus

  • Hi,


    noch 2 weitere Patches:

    add_patpam_cut.diff fügt beim Schneiden die fehlende PMT in die geschnittene Aufnahme ein.

    play_patpmt_start.diff sorgt dafür, dass VDR zum Abspielen von Aufnahmen nur am Anfang der Aufnahme die PMT braucht.


    ~ Markus

  • Ich würde das nicht überbewerten, diese Sheeva Plug Geräte waren mit die ersten kommerziellen Geräte auf ARM Basis gewesen, so vor ca. 10 Jahren ... 8|


    Vmtl. hat heute jedes €200 Smartphone mehr Rechenleistung und schnellere Schnittstellen, ein RPi3 erscheint daneben geradezu wie ein Numbercruncher ... :evil:

    Klingt nach unpassender Hardware Auswahl.

    FullAck!


    Regards

    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Der Performanceunterschied besteht nicht im Schreiben der PAT/PMT.

    Sondern darin, dass der Stream nicht analysiert werden muss sondern einfach auf die Festplatte gedumpt wird.


    Ob das für RPI Systeme noch relevant ist, kann ich nicht sagen. Und natürlich ist jedem freigestellt, ein schnelleres System zu kaufen. Ist aber für einen VDR Server nicht notwendig.


    ~Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Einen nicht-konformen mpeg Stream auf die Platte zu schreiben macht doch am Ende keinen Sinn.

    Und wenn das selbst ein simples ARM-Himbeerchen schafft..

  • Also, natürlich kann das jeder so machen, wie er möchte.


    Spannend finde ich jedenfalls, dass mögliche Probleme beim gleichzeitigen Aufzeichnen vieler Sendungen nicht durch fehlende I/O Performance verursacht werden (zumindest nicht, wenn die Festplatte an einem 10 Jahre alten USB hängt, an dem auch zwei DVB-Sticks hängen), sondern durch mangelnde CPU Leistung.


    Von wegen nicht-konformen mpeg Stream: Der Original VDR beendet sich bei einem nicht-konformen mpeg Stream mit dem VDSB. Dann können die Treiber neu geladen werden, und VDR versucht, mit der Aufzeichnung weiterzumachen. Der von mir gepätchte VDR beendet sich mit dem VDSB nur noch, wenn gar keine Daten mehr kommen. In der Praxis macht das für mich keinen Unterschied, seit ich meine alten FF Karten rausgeschmissen habe, hatte ich keinen VDSB Fehler mehr.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Sehr guter Ansatz, ich benutze eine schwachbrüstige energiesparende CPU (Celeron J1900) und sehe das gleiche Verhalten, auch noch in anderen Konstellationen. Werde das gleich mal testen. :thumbup:

    Server: CPU J1900 | 1x CineS2 | Debian Bullseye headless| VDR 2.6.3
    Client: 2x Himbeere mit vdr

Jetzt mitmachen!

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