Aufnahmen ruckeln beim Abspielen

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

    • KarlHintern schrieb:

      grep pvr /proc/mounts
      192.168.1.1:/srv/share/pvr /media/net/pvr nfs rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=70,retrans=3,sec=sys,local_lock=all,addr=192.168.1.1 0 0

      KarlHintern schrieb:

      Lustigerweise hatte ich keine explizite {r,w}size angegeben, das sind bei mir also die Standardwerte.
      Beim Mounten wird standardmäßig die maximal mögliche Geschwindigkeit zwischen Client und Server ausgehandelt.
      Wenn das ohne Einschränkung deine Standardwerte sind, würde ich auf ein defektes LAN Kabel oder nicht richtig funktionierenden Switch Port tippen.
      Rechtschreibfehler sind beabsichtigt, sie fördern ein genaueres Lesen
      Debug Log aktivieren Putty Telnet Screenshots erstellen

    • Danke für die Antworten! :thumbsup:

      hajeku123 schrieb:

      Beim Mounten wird standardmäßig die maximal mögliche Geschwindigkeit zwischen Client und Server ausgehandelt.Wenn das ohne Einschränkung deine Standardwerte sind, würde ich auf ein defektes LAN Kabel oder nicht richtig funktionierenden Switch Port tippen.
      Hättest Du da eventuell genauere Informationen zu? Die maximal möglich blocksize (rtmax, wtmax) gibt der Server über den FSINFO-reply vor, was in meinem Fall über für tcp 512k und für udp 32k sind (was sich aus RPCSVC_MAXPAYLOAD_TCP bzw. RPCSVC_MAXPAYLOAD_UDP ergibt).
      Auf Clientseite sehe ich, daß die letztlich gewählte rsize bzw. wsize von NFS_MAX_FILE_IO_SIZE oder der rpc payload size abhängt. Bei dem Punkt, wie das ermittelt wird, hänge ich jedoch. Denn im Traffic konnte ich nichts erkennen, was nach einer Art probing aussieht (sende Paket in Größe xy → reduziere Größe, wenn es Fehler gab → wiederhole), was also auf das Ausloten der Leitungsqualität schließen würde; Auch im RFC1813 wurde ich nicht fündig. Wäre echt klasse, wenn Du mir da weiterhelfen könntest :) .

      Ich klemme aber gleich mal meinen Schleppi an das Kabel, an dem momentan der Vu+ hängt und gucke, ob da etwas im Argen liegt.

      Edit:
      Ach schau mal einer guck. Wenn ich den share über autofs einbinde (nicht klassisch), sieht's so aus:

      Quellcode

      1. root@vuuno4k:~# grep pvr /proc/mounts
      2. 192.168.1.1:/srv/share/pvr /media/net/autonet/pvr nfs ro,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=70,retrans=3,sec=sys,local_lock=all,addr=192.168.1.1 0 0

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

    • Nun, ein Netzwerkproblem scheint es nicht zu sein; es laufen keine Fehler auf den interfaces auf, die Datenrate ist mehr als ok, es gibt keine retransmissions oder dup acks. Die Last war während des Abspielens bei 1.02 bis 1.04. Fehler in den Logs: keine.
      Die Ruckler sind, wenn ich das richtig sehe, gefühlt an derselben Stelle. Mag aber auch dadurch bedingt sein, daß es häufig bei schnelleren Bildwechseln auftritt.

      Bei ÖR/HD sind mir die Ruckler bisher nicht aufgefallen. Ich teste noch ein wenig weiter.

      Dafür verhält sich die Box jetzt mehr als merkwürdig: Sehe ich mir eine Aufnahme an und beende sie über die Stop-Taste, wähle dann "Film löschen und zurück zur Filmliste", passiert gar nichts. Die Aufnahme wird weiter abgespielt und ich sehe den Spinner in der oberen Ecke. Gelöscht wird auch nichts. Ich kann nur noch über die Console "reboot" ausführen. ?(

    • Ok, jetzt gibt's neue Erkenntnisse. Es ist mir vorher nicht aufgefallen, da ich meistens Aufnahmen ansehe:
      • das Problem tritt nicht nur bei Aufnahmen, sondern auch während des Live-TV auf
      • Betroffen sind bisher nur die Privaten (Pro7Sat1, RTL-Gruppe), nicht aber bei die ÖR – wobei die ÖR nicht in Full-HD ausgestrahlt werden

      • Timeshift ist auf nfs aktiviert, die Timeshift-Aufnahme kann ich auf anderen nfs-Clients störungsfrei ansehen
      • Die Bild- und Tonfehler treten bei erneutem Abspielen der Aufnahme (oder beim Zurückscrollen während des Timeshifts) zwar an zeitlich ähnlicher, aber nicht an derselben Stelle auf
      • Es ist wohl unabhängig davon, ob die Aufnahme noch verschlüsselt ist oder bereits entschlüsselt wurden
      Vielleicht finde ich noch etwas…