Hi,

mein Problem ist nicht identisch mit diesem hier.

Ich habe eine Uno4k/DVB-C mit einem CI-Modul von Unitymedia und einer UM02-Karte. Die Aufnahmen werden über GE auf einem NFS-share (Linuxserver) abgelegt, das von der Leistung her mehr als ausreichend ist. Die GE-Verbindung wird nicht anderweitig belastet, kein broadcast-storm, kein multicast auf der Leitung, nada.

Der Softwarestand ist 14.0.3 ohne zusätzliche Updates, relativ frisch aufgesetzt. Keine Updates, da mir zwei voneinander unabhängige Updates letztens die Box zerschossen haben, daß ich um eine Neuinstallation nicht drumrum kam. Das Problem der ruckelnden Aufnahmen trat unter 14.0.1, die vor der Neuinstallation drauf war, nicht, oder zumindest nicht spürbar auf. Die Settings sind identisch – allerdings nicht aus dem Backup wiederhergestellt, sondern vorher aufgeschrieben und nach der Neuinstallation manuell nachgepflegt.

Also: Die Aufnahmen landen vollkommen störungsfrei auf dem NFS. Nach einer Weile werden sie entschlüsselt, so weit, so gut.
Diese entschlüsselten Aufnahmen zeigen jedoch, wenn ich sie über die Vu+ abspiele, starke Bildruckler bei schnelleren Kameraschwenks, teilweise aber auch schon, wenn sich bei sonst konstantem Bild nur ein Element ändert (z.B. eine Diskussionsrunde: alle sitzen steif rum, einer bewegt sich – der sich Bewegende besteht dann nur noch aus Klötzchen), begleitet von Tonaussetzern.
Auf anderen Endgeräten, z.B. einem Linux-Laptop, welcher über Wifi am NFS-Server hängt, wird die Aufnahme komplett fehlerfrei abgespielt. vnc zeigt hierbei nichtmal irgendwelche Warnungen von kaputten frames etc., die Aufnahme ist also in Ordnung.
Meiner Meinung nach kann die Vu+ die Aufnahme mit ausreichender Geschwindigkeit lesen, hier mal ein Beispiel einer anderen Datei (die nicht im filesystemcache und damit "frisch" ist):
Woran könnte es liegen – und viel wichtiger: Wie läßt sich das beheben?

Danke für die Antwort.
Die mount-Optionen sind bereits so gesetzt:
Auf meinem Schleppi (allerdings per nfs4 eingebunden) ist die r/w chunk size bei 512k.
Samba probiere ich morgen mal

hajeku123 schrieb:

Ich habe angenommen, du benutzt die Standardoptionen.

Lustigerweise hatte ich keine explizite {r,w}size angegeben, das sind bei mir also die Standardwerte.
Habe jetzt alles zwischen 8k und 512k durchprobiert – keine Besserung.
Auch cifs probiert – keine Besserung.
Allerdings betrifft das Problem auch nicht jeden Sender. Die ÖR/HD funktionieren bisher problemlos. Ich werde noch ein paar Stichproben machen, vielleicht kann ich das Problem eingrenzen:

1. HD-Sender der Pro7Sat1-Gruppe, noch nicht entschlüsselt
   
2. HD-Sender der Pro7Sat1-Gruppe, über Nacht entschlüsselt
   
3. HD-Sender der RTL-Gruppe, noch nicht entschlüsselt
   
4. HD-Sender der RTL-Gruppe, über Nacht entschlüsselt
   
5. HD-Sender des ÖR
   

Die Netzwerkverbindung zumindest server- und switchseitig entspannt. Auf der Vu+ schaue ich mal über /proc, wieviele Daten da im Mittel unterwegs sind. Interfacefehler laufen jedenfalls keine relevanten auf.
Die Load beim Abspielen der Aufnahme liegt auf der Vu+ so bei 1.2, ist also eigentlich noch Luft nach oben.

Ja, danke für den Hinweis . Während des Abspielens laufen weder andere Aufnahmen noch epgrefresh oder ähnliche Dinge. Da sich die Aufnahme auf anderen Endgeräten problemlos, fehler- und warnungsfrei abspielen läßt, ist m.E. weder der Aufnahmepfad noch der Entschlüsselungsvorgang das Problem.

Quasi vielleicht. Aus meinen letzten Erfahrungen mache ich erstmal einen großen Bogen um Updates, solange es einigermaßen läuft. Reproduzierbar startete enigma2 nach Neuflashen am 25.05. nicht mehr, nachdem ich die Updates eingespielt hatte. Und die Python-Geschichte vor kurzem hat auch nicht gerade zu meinem Vertrauen in Updates beigetragen.
fwiw:

Bitte versteh mich nicht falsch. Ich bin durchaus dankbar[1] für die hier geleistet Arbeit und weiß, wie es ist, daß ehrenamtlich geleistete Arbeit von der Community kommentarlos hingenommen und/oder nicht gewürdigt wird – bin auch in der Branche unterwegs. Wäre VTi opensource, würde ich auch gern selbst beitragen.
Ich habe lediglich erwähnt, daß und weshalb ich vorsichtig mit Updates bin. Die Vu+ hängt nicht in einem öffentlichen Netz, ich surfe damit nicht, Sicherheitsupdates werden afaik nicht als solche gekennzeichnet. Never change a running system, ein Motto, das bis heute zumindest für diejenigen Gültigkeit hat, die einen stabilen Stand neuen Features vorziehen.

Wie auch immer. Ich habe die Aufnahmen nochmal gegen einen DuneHD-player älteren Datums mit langsamerem Chipsatz gegengeprüft, während die Vu+ fröhlich eine Aufnahme getätigt hat und ich das Netz mit ein wenig iperf3 gequält habe. No problemo. Ich teste dann heute abend auch nochmal, ob und wieweit die Bildfehler auf der Vu+ sich verstärken, wenn ich das Netz unter Last setze. Aber die 12-15 Mbps, die so eine Aufnahme im peak erreicht, fallen bei GE nicht wirklich ins Gewicht. Könnte noch jumboframes testen, wobei mich etwas irritiert, daß die Vu+ extrem hohe, nicht konforme MTUs erlaubt:



[1] an dieser Stelle nochmal ein explizites Dankeschön

Clientseitig habe ich mangels geeigneter Tools (tcpdump, wireshark) noch keinen Einblick in die Netzwerkkommunikation genommen. Ich könnte noch auf dem switch einen mirrorport ansetzen und dort abschnorcheln, aber ich rechne mir hier insgesamt wenig Chancen aus, da nfs über tcp eingebunden ist und ich keine retransmissions sehe (auch keine dup acks) – also alles ok zu sein scheint.
Die Kernellogs sind, bis auf vereinzelte dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff) unauffällig.

Thx, ich schaue mal. Snmp hat die Vu+ nicht, oder? Zumindest keine Prozesse/Pakete diesbezüglich gefunden. Alle anderen meiner Geräte werden minütlich von einer Monitoringlösung (icinga2) abgefragt: cpu usage, memory usage, swap usage, load avg, page faults, swapin/swapout, disk i/o, network i/o, network errors, Temperatur, etc. pp. Nicht spannendes aufgefallen .
Bei der Vu+ habe ich mich während des Abspielens mit top/htop begnügt, dann aber eigentlich nur den enigma2-Prozess gesehen, der die Load auf 1.2 trieb. iostat bringt imho mangels Involvierung des lokalen Flashmediums nichts, /proc/net/dev hatte ich bisher noch nicht angesehen. Vielleicht bastel ich mir mal einen agent fürs Monitoring .