Unterschied NFS / SMB für Aufnahmen auf NAS

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Wieso denn gleich so verärgert? Weil ich jetzt 2 Antworten aufeinander abgegeben hab?
      Sorry das habe ich auch nicht gewusst dass das hier nicht gern gesehen wird - Und ja, das hier war tatsächlich mein "erstes Doppelposting" - und dafür entschuldige ich mich gerne - normalerweise bearbeite ich den letzten Post von mir... - In den meisten Fällen geht das aber nicht mehr, da hier scheinbar eine zeitliche Begrenzung existiert um den letzten Post bearbeiten zu können...

      Nun, was das Thema betrifft kann ich verstehen wenn du keine Zeit hast längere Aufnahmen zu machen und zu prüfen. Dafür mache ich ja die Aufnahmen und prüfe sie...
      ...ob jetzt dann die 5 Minuten-Aufnahmen genügen um zu Rechtfertigen, dass das Problem im VTI auszuschließen ist, überlasse ich jetzt jedem selbst...

    • Die Bearbeitungszeit für deinen Post beträgt 3 Stunden.
      Gruß
      Databox

    • wi-tom schrieb:

      Wie sieht es bei Aufnahmen aus die z.B. 1h - 1,5h dauern?
      s. Post #13 ;-).

      Wie ich da auf das "Nur-Wiedergabe-Problem" gekommen bin kann ich jetzt auch nicht mehr sagen :-). Habe ich wahrscheinlich mit einem anderen Thread in Verbindung gebracht.....gelöscht wurde ja in diesem Thread nix

      Ps:
      Die (automatisch ausgehandelten) Mountparameter:
      192.168.0.2:/volume1/Public on /media/net/autonet/DS118 type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=70,retrans=3,sec=sys,local_lock=all,addr=192.168.0.2)
      [i][b]Kein Backup - kein Mitleid[/b][/i]

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von rolano () aus folgendem Grund: Ergänzung der Mountparameter

    • Ich habe jetzt testweise wieder die "Default-Werte" im NFS-Mount wiederhergestellt und die "SQL Filmdatenbank" deaktiviert, Box neu gestartet und neue Aufnahme durchgeführt.
      Ergebnis: erneut Fehlerhafte Aufnahme. Hier noch ergänzend, dass der erste Fehler ab ca. Minute 11 auftritt...
      zusätzlich noch das Logfile aus dem Schnittprogramm:check.log

      error1.PNGerror2.PNG

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von wi-tom ()

    • Es ist echt hartnäckig, dieses Problem.

      Ich habe jetzt keine Idee mehr, welche Stellschrauben man noch hat, um dem Thema auf die Spur zu kommen. Ich nehme an, du machst die Aufnahmen immer von den selben Sendern, da gibt es ja auch Bitratenunterschiede.

    • Die Fehler sind sowohl bei SD als auch HD Sendern / verschlüsselt oder unverschlüsselt immer gleich.
      Ich mache aus "Vergleichbarkeitsmöglichkeit" immer Aufnahmen vom gleichen Sender - und das auch um in der Community vergleichbare Tests durchführen zu können auf einem "öffentlich Rechtlichen" Sender ohne Verschlüsselung.

      Ich hab mich jetzt auch mal an die jeweiligen Kernel-Parameter gemacht...
      Hier die Unterschiede der jeweiligen Images:
      1. VTI-Image:
      sysctl.txt

      2. nicht-VTI-Image 1
      sysctl.txt

      3. nicht-VTI-Image 2
      sysctl.txt

      4. nicht-VTI-Image 3
      sysctl.txt

      Ich würde mich evtl. als nächstes an NFS Debugging machen, habe aber hier noch zu wenig Erfahrung damit. Kennt sich jemand mit NFS Debugging besser aus?
      4Debugging

      Sledge schrieb:

      Für den Fall Du willst die gleichen NFS Einstellungen probieren:
      klassisch

      rw,tcp,nolock,nocto,actimeo=600,timeo=60
      Das habe ich nun auch überprüft - gleiches Ergebnis...

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von wi-tom ()

    • @wi-tom,

      danke fürs Bereitstellen der Kernelparameter:

      Nur auf die Schnelle drüber geschaut. Diese 3 Settings sind es auf jedenfall Wert mal zu probieren:

      vm.dirty_background_ratio = 10
      vm.dirty_ratio = 20
      vm.dirty_writeback_centisecs = 500

      ändern zu :
      sysctl -w vm.dirty_background_ratio=1
      sysctl -w vm.dirty_ratio=60
      sysctl -w vm.dirty_writeback_centisecs=300

      So wie es bei den 3 anderen Images ist…

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Sledge ()

    • Nun, auch mit den geänderten Kernel-Parametern sind die Probleme noch vorhanden.

      wi-tom schrieb:

      Ich war die Antwort noch schuldig, ob die Probleme auch bei UDP Verbindung auftreten. Die Antwort ist leider "Ja"

      Und neues Testergebnis:
      - sämtlicher Traffic ausserhalb des Subnetz wurde blockiert (Firewall)
      - Server im gleichen Netz mit NFS-Verbindung zum NAS wurden ausgeschaltet (Domain-Controller mit SMB-Verbindung bleibt aber aktiv)
      -> Ergebnis: Aufnahme ohne Fehler! Somit muss es also einen "Störenfried" außerhalb des Subnetz geben oder einer der Server im gleichen Subnetz verursachen Störungen. Das wird nun mein nächster Test...
      Ich zitiere mich jetzt selbst, da ich an vielen Stellen nicht weiter komme und ich deshalb an einem letzten Punkt bei meinem Netzwerk-Test zurückgekehrt bin.
      Dazu habe ich das selbe Szenario wieder aufgebaut - und muss leider sagen, auch die "damaligen" positiven Aufnahmen (waren damals auch kürzere) sind nun "widerlegt". Eine weitere Aufnahme unter den exakt gleichen Konstellationen hat nun erneut eine Aufnahme mit vielen Fehlern erzeugt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von wi-tom ()

    • Es ist aber noch wie vor so, dass das vti mit SMB/CIFS keine Störungen in den Aufnahmen auf dem NAS erzeugt?

    • Ja genau, Aufnahmen unter exakt den gleichen Rahmenbedingungen per CIFS/SMB haben genau 0 Aufnahmefehler - nicht weniger sondern genau 0.
      Aus diesem Grund werde ich auch - sofern es keine weiteren relevanten Vorschläge gibt - an dieser Stelle auch mit meinen Tests aufhören.

    • Mir fällt nichts mehr ein, wie man da weiterkommt. Das ging nur mit mehr Ausgaben von den Aufnahmeprozessen/Threads. Diese werden wir aber nicht bekommen, da man dazu die Sourcen vom enigma beim vti ändern müsste.

    • Ich nehme immer auf einer lokalen Platte auf und kopiere dann gegebenenfalls auf das NAS.
      Zum Test habe ich jetzt auch mit dem Freigabe-Manager meine Synology per NFS und autofs eingebunden.
      In einer einstündigen Testaufnahme hat TS-Doctor in der Tat ca. 20 Fehler gefunden.

      Da gibt es möglicherweise ein Problem mit nicht passenden Puffergrößen oder etwas ähnliches.
      Beim normalen Kopieren von Dateien hatte ich da noch nie ein Problem.

      Wenn die Fehler mit SMB/CIFS nicht auftreten, würde ich das auch als naheliegende Lösung nehmen.

      Das Ergebnis ist aber wirklich interessant. Ich hätte nicht gedacht, dass eine NFS-Verbindung dieses Problem hat.

    • Das ist in der Tat interessant. Ich vermute immer noch, dass der Aufnahmeprozess/Thread Daten verwerfen muss, weil sich irgendwo etwas aufstaut.

      Aber ohne bessere Debugmöglichkeiten, werden wir das nicht rausfinden.

    • @RickX
      Schön zu sehen, dass ich scheinbar nicht "allein" mit diesem Problem bin - nicht schön, dass es dafür keine ausreichende Erklärung dazu gibt. Was deine erkannten Fehler betrifft, merkst du das auch in der Wiedergabe (egal welcher Client / welche Software)?
      Was das "debuggen" betrifft hatte ich ja schon in einer meiner ersten Posts versucht herauszufinden "was geht". Leider sind diese Debug-Ausgaben für diesen Zweck ungeeignet und schneiden das auch gar nicht mit.
      Das einzige was mir an dieser Stelle bzgl. "debuggen" noch eingefallen war, ist ein "Debuggen" auf NFS-Ebene - dazu fehlt mir aber erstens die nötigen Kenntnisse und zweitens die Tools auf der VU+. Sollte sich jemand mit NFS-debuggen besser auskennen, bitte gerne melden. Ob das dann überhaupt was bringt kann ich auch nicht sagen - wäre jetzt aber einer der letzten Ideen die mir hier noch einfallen.

      @anudanan
      Vermutlich werden wir ein Debuggen auf "Prozessebene" ohne Mithilfe des Image-Teams nicht selber hinbekommen - somit vermutlich eine Sackgasse.

      Ach ja, sollte das eine Relevanz haben: Ich habe insgesamt 4 VU+ Boxen im Einsatz, eine vusolose und drei vuzero. Der Fehler tritt bei allen Boxen auf...
      Ob das eine Rolle spielt kann ich nicht sagen, aber ggf. gibt es ja auch unterschiedliche Ergebnisse bzgl. der verwendeten Hardware? Deshalb ja auch meine Frage in meinen ersten Posts, ob das ggf. bei 4K Boxen nicht der Fall ist, bei HD Boxen vielleicht schon?

      ...und ja, bei den Tests waren die anderen Boxen immer aus dem Netz genommen...
      Bildschirmfoto 2023-05-11 um 13.22.58.pngBildschirmfoto 2023-05-11 um 13.22.51.pngBildschirmfoto 2023-05-11 um 13.22.44.pngBildschirmfoto 2023-05-11 um 13.21.52.png

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von wi-tom ()

    • @wi-tom,

      Zwischenfrage(n):

      • Auf den Boxen wo Du das Problem beim NFS hast, sind da CI-Module eingeschoben? Ich habe hier den Effekt, dass mit Modul ständig eine CPU-Load > 1 ist. Ohne, ist im Leerlauf die CPU Load bei kleiner als „0.2“.
      • Ist Dir da bei Deinen Versuchen mit den anderen Images eventuell ein Unterschied aufgefallen?

    • @RickX

      auch wenn die Frage an @wi-tom gerichtet war, danke Dir für die Info mit dem CI-Modul. Die 2. Frage war im selben Kontext zu verstehen, bei Einsatz eines CI-Moduls.

      Denn vermeintlich Volllast auf einem CPU-Kern im Idle-Zustand finde ich auffällig. Wenn die anderen Images bei Nutzung von NFS keine Fehler in den Aufnahmen verursachen, wollte ich nur wissen ob es bei der CI-Anbindung eventuell auch weniger ressourcenhungrig ist.

    • Eine Load von 1 heißt nicht, dass eine CPU unter Volllast läuft.
      Die Load gibt die Länge der CPU-Warteschlange an.
      Es gibt einen Prozess, der in der Warteschlange ist. Dieser Prozess macht aber nichts und verbraucht auch keine CPU.
      Der Prozess ist vermutlich im Hardware-Wait-Zustand und wartet darauf, auf ein Gerät zugreifen zu können.
      Dadurch wird das System nicht belastet.

    • RickX schrieb:

      Ich bekomme die Fehler bei Aufnahmen auf die Synology-NFS-Freigabe auch.
      ...sichtbar, oder durch Tools festgestellte Fehler?
      Ich kann es nur wiederholen: Hier mit 3 Vus (Uno4k-Kabel, Uno4KSe-Sat mit CI-Modul, SoloSEV2-Sat) und ausschließlicher Aufnahme auf eine Syno (incl. gelegentlichem Time-Shift) per NFS KEINERLEI sichtbare Fehler.
      [i][b]Kein Backup - kein Mitleid[/b][/i]

    • @RickX,

      ich habe auch nicht eine CPU, sondern 1 CPU-Kern geschrieben. Wenn z.B. 1 Interrupt ständig zuschlägt oder ein Treiberbug vorliegt sieht die Statistik ebenfalls nicht viel anders aus und dann hat die CPU sehr wohl etwas zu tun. Im konkreten Fall schlägt die Auslastung durch den Kernel des Betriebssystems im htop entsprechend aus.
      Auch hilft es nicht wenn an dem von Dir spekulierten Prozess noch andere Abhängigkeiten dran hängen sollten. So ein Verhalten wäre ein Indiz für einen Bug oder unsaubere Implementierung.