vnsiserver / kodi - (nur) Aufnahmen stocken bei Wiedergabe über VPN

  • Vielleicht kennt dies jemand und hat eine Lösung - oder bestätigt das Verhalten?

    Im lokalen Netz läuft alles (seit Jahren) bestens, sowohl Live-TV als auch Aufnahmen von SD und HD Sendern laufen flüssig über vnsiserver / Kodi, auch bei mehreren (i.d.R. zwei, manchmal auch drei) Clients gleichzeitig.
    Gleiches Szenario über Client via VPN (OpenVPN, auch Wireguard getestet), Live-TV immer noch einwandfrei, aber(!) die Aufnahmen ruckeln, laufen ein paar Sekunden, dann sieht man wie der Buffer (Kreis mit Prozentangabe) gefüllt wird, wiederholt sich immer wieder.
    Die Internet-Anbindung ist es nicht - auf beiden Seiten mehrere 100 MBit Down/Upload (Glasfaserzugänge). Live-TV läuft ja problemlos auch auf den HD-Sendern mit mehr Bandbreite, dagegen ruckeln selbst die SD-Aufnahmen.
    Ich glaube zwar nicht, dass es von da kommt, aber der Vollständigkeit halber: die Aufnahmen des virtualisierten VDR-Servers sind in einer nfs-Freigabe, allerdings auf einer VM des gleichen Hosts abgelegt (Zugriff geht also über internes Netz des VMWare-ESXi).
    Mit top sind keine Auffälligkeiten auf beiden Seiten zu sehen, wenig CPU-Last, kein Wait. Latenzen (mit ping) zwischen den Systemen über den Tunnel bei konstanten 40ms.


    VDR-Server:
    vdr:~ # vdr -V

    vdr (2.6.4/2.6.3) - The Video Disk Recorder

    conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu

    devstatus (0.5.0) - Status of dvb devices

    epgsearch (2.4.1) - search the EPG for repeats and more

    epgsearchonly (0.0.1) - Direct access to epgsearch's search menu

    epgtableid0 (2.4.0) - EPG handler for events with table id 0x00

    femon (2.4.0) - DVB Signal Information Monitor (OSD)

    hello (2.4.0) - A friendly greeting

    live (3.2.1) - Live Interactive VDR Environment

    osddemo (2.4.1) - Demo of arbitrary OSD setup

    pictures (2.6.1) - A simple picture viewer

    quickepgsearch (0.0.1) - Quick search for broadcasts

    satip (2.4.1) - SAT>IP Devices

    skincurses (2.4.3) - A text only skin

    status (2.4.0) - Status monitor test

    streamdev-server (0.6.3) - VDR Streaming Server

    svccli (2.4.0) - Service demo client

    svcsvr (2.4.0) - Service demo server

    svdrpdemo (2.4.0) - How to add SVDRP support to a plugin

    vnsiserver (1.8.0) - VDR-Network-Streaming-Interface (VNSI) Server


    Kodi Client:
    20.2 (oder auch 18.4 gleiches Verhalten)

  • Ich glaube zwar nicht, dass es von da kommt, aber der Vollständigkeit halber: die Aufnahmen des virtualisierten VDR-Servers sind in einer nfs-Freigabe, allerdings auf einer VM des gleichen Hosts abgelegt (Zugriff geht also über internes Netz des VMWare-ESXi).

    Hast du mal probiert die Block Size anzupassen und dann den Durchsatz im Vergleich gemessen (https://nfs.sourceforge.net/nfs-howto/ar01s05.html)? Da wo das ein Flaschenhals war, hat es oft geholfen rsize=8192,wsize=8192 zu setzen, also z.B. so in der fstab:

    Code
    servername:/srv/nfs /video0 nfs rsize=8192,wsize=8192 0 0

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke für den Vorschlag, habe es (leider) erfolglos getestet, standard sah dies so aus:

    vdr:/export/vdr # mount | grep vdr

    storage1.laub.intra:/export/vdr on /export/vdr type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.111.101,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.111.101)
    Die Änderung auf 8192 oder 1024 bewirkt aber nichts.

    Aber, ich habe mal getestet, was passiert, wenn ich den nfs-Mount am vdr durch einen lokalen ersetze und darin eine HD-Aufnahme platziere - es ändert nichts, ruckelt genauso am fernen KODI/vnsiclient. (Wie erwähnt im lokalen Netz funktioniert es einwandfrei)
    Also muss dies im Zusammenspiel vdr/vnsiserver - VPN - kodi/vnsiclient liegen!

    Kann dies jemand bestätigen oder funktioniert dies bei jemand?

  • Nein, die Verschlüsselung ist nicht das Problem, bitte den ersten Beitrag genau (nach)lesen.
    Der Beweis, wie oben beschrieben: Live-TV von HD-Sendern geht problemlos, aber Aufnahmen, selbst von SD-Sendern stocken

  • Die meisten dürften die Kombination VDR mit Kodi ausschließlich im eigenen LAN verwenden. Da bleibt dir nichts anderes übrig als selbst Ausschlussverfahren zu betreiben.


    Ich würde zumindest mal zum Test den Faktor "NFS" komplett rausnehmen. Eine einzelne Aufnahme direkt auf den VDR packen und dann das Aufnahmen-Verzeichnis testhalber auf "lokal" umkonfigurieren.

  • Ich würde zumindest mal zum Test den Faktor "NFS" komplett rausnehmen. Eine einzelne Aufnahme direkt auf den VDR packen und dann das Aufnahmen-Verzeichnis testhalber auf "lokal" umkonfigurieren.

    Das hatte ich vergessen zu berichten, habe ich gemacht - NFS kann man somit ausschliessen.

    vnsi selber scheint mit den Aufnahmen über VPN das Problem zu sein, wahrscheinlich irgendwo ein unabsichtlicher Flaschenhals programmiert.

  • Hi,

    Die Datenrate von SD ist nicht zwingend geringer wie HD. SD ist in MPEG 2 codiert und somit viel weniger effizient wie h264 bei HD. H265 bei DVB-T2 ist noch effizienter...

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Kürzlich hatten wie hier einen Fall, da gab es Probleme wegen "to many open files" bei einem NFS-Mount und das im lokalen LAN.

    Ich würde NFS als Ursache also nicht so schnell ausschliessen. Zumal das Probem timing-abhängig war.

    Gruss
    SHF


  • Ich dachte bislang, Kodi zieht die Aufnahmen, am VDR vorbei, direkt von NFS-Server.

    Das hatte ich dann wohl falsch in Erinnerung...


    Wenn es ähnlich wie bei Xineliboutput funktioniert, wundert es mich nicht, dass es über VPN Probleme gibt.

    Xineliboutput mag bei mir schon über WLAN nicht mehr so recht und wird instabil. Am gleichen Computer geht es ganz gut, über LAN-Kabel geht es auch noch, aber mit WLAN hab ich es bislang nicht wirklich stabil hin bekommen.

    Die Übertragungsrate scheint da auch nicht das Problem zu sein, eher die Latenz. Und mein WLAN liegt weit unter 40ms.


    Wenn ich es richtig verstanden habe, gibt es zwischen Live-TV und Wiedergabe einen entscheidenden Unterschied.

    Bei Live-TV sendet der VDR die Datenpakete und der Player muss damit zurecht kommen.

    Bei einer Wiedergabe macht der Player das Timing und muss die Daten rechtzeitig anfordern.

    (Man möge mich bitte korrigieren, falls ich da Quatsch geschrieben habe!)

    Meine Vermutung wäre jetzt, dass das Anfordern schlicht nicht rechtzeitig passiert und deshalb der Puffer am Client leer läuft.

    Evtl. gibt es eine Möglichkeit auf Puffergröße und Füllstand Einfluss zu nehmen?

    Gruss
    SHF


  • Ich denke auch, dass die SW (vdr/vnsiserver/vnsiclient?) beim Abspielen von Aufnahmen mit der Latenz nicht klarkommt, sonst sehe ich keinen Unterschied bei der Bandbreite, die mir zum Testen zur Verfügung steht.
    Leider bin ich kein Programmierer, grundsätzlich habe ich aber Ahnung davon, bin Systemingenieur, gerade im Bereich Netzwerke mit einiger Erfahrung.

  • Ich habe mir heute die Sache noch mal näher angesehen und scheine mit meiner Vermutung zumindest einigermaßen richtig zu liegen:

    Der vnsiclient behandelt Aufnahmen und LiveTV getrennt:

    pvr.vdr.vnsi/src/ClientInstance.h at Omega · kodi-pvr/pvr.vdr.vnsi
    Kodi PVR addon VNSI. Contribute to kodi-pvr/pvr.vdr.vnsi development by creating an account on GitHub.
    github.com

    Die Funktionen open, close, ... sind jeweils einmal für LiveTV und Recordings vorhanden.

    Aufgerufen werden die wohl irgendwo aus KODI selber heraus.


    Eingelesen werden die Aufnahmen in Blöcken einer gewissen Größe, gesteuert vom vnsiclient:

    pvr.vdr.vnsi/src/InputstreamRecording.cpp at Omega · kodi-pvr/pvr.vdr.vnsi
    Kodi PVR addon VNSI. Contribute to kodi-pvr/pvr.vdr.vnsi development by creating an account on GitHub.
    github.com


    Für Optimierungen müsste man also am sinnvollsten wohl auf dem Client beginnen.

    Als Ausgangspunkt drängt sich dieses HOWTO förmlich auf: HOW-TO:Modify the video cache

    Eventuell löst schon buffermode 1 das Problem.

    Der readfactor könnte aber auch was verändern.

    Ich denke, da wirst Du etwas probieren müssen.

    Gruss
    SHF


Jetzt mitmachen!

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