In dem kurzen Sample gibt es eine hohe Anzahl, 99 von ts counter Fehlern, (fehlende TS-Pakete) die letztentlich zu den Problemen führen.
Mein ffplay (Linux) bringt dann pes packet size mismatch und Fehler in den h264 Daten, wie auch bei dhzw s Beispiel.

Ein Testsample wäre nett, ca 30-60 sec.
Vermutung:
Es werden 25fps gesendet, es wird aber 29.97 Hertz kodiert.

Ältere Fritzboxen haben Probleme, wenn der Switch in der Fritzbox von 100 auf 1000 MBit/s umsetzen muss, wegen begrenztem Pufferspeicher.
Neuere Fritzboxen sind meines Wisssens nicht betroffen. Reine 100 MBit/s oder 1000 MBit/s sind unkritisch.

@EgLe
Das Thema des Threads ist NFS, Die Fritzbox kann ftp und smbv1. Die aktuellen Laborversionen auch smbv3, kein NFS.

Bitte eine kurze Aufzeichnung erstellen (ca. 30 Sekunden).
Dann auf einem PC mit vlc prüfen ob die Aufzeichnung problemlos wiedergegeben werden kann.

Es gibt eine schöne Datei /etc/enigma2/settings
Die kann man bei gestopptem enigma2 bearbeiten.

A second look:
I have found the the the stream with pid 0x103 with the pcr values.
The dts/pts time stamps from h264 video seems to be matching with the pcr values from stream 0x103.
So i can't really say why the dm920 does not like stream.

The first look onto data:
There is a seperate pid for pcr (0x103), outside video/audio, and no packages for this pid are contained into the sample files 'Lahore Rung.ts'
Did you activate such extra pids?

the video is not displayed on a DM920, I see a message 'invalid pcr'.
Why does dream check the pcr if playing a file?
No player like vlc is doing this. the pcr is only relevant if you a playing a live stream.

smbv3 wird erst ab kernel 3.12 unterstützt. also nicht für DM500.

Ich hoffe mein Weltbild stimmt:
Fritzbox hat eine 100 Mbit/s oder 1000 Mbit/s Strecke zum TP-Link Switch.
Der TP-Link-Switch hat eine 100 MBit/s Strecke zur DM 500HD.
Betroffen ist die Wiedergabe der aufgezeichneten Sendungen. Die Aufnahmen lassen sich am PC problemlos wiedergeben.

Dann muß der TP-Link Switch Umsetzer von 1000 MBit/s auf 100 MBit/s spielen und braucht ausreichend Puffer.

Ich würde versuchsweise rsize und wsize auf 32768 setzen. Bitte mit cat /proc/mounts die effektiven Mount-Parameter prüfen.
Auch der Wechsel des TP-Link Switches wäre eine Option.

Möglicherweise gibt es einen Fehler in der Aushandlung, Die eine Seite hat 100 Mbit/s Full Duplex, die andere Seite 100 MBit/sec Half Duplex.
Dann bekommst Du derartige Probleme.

Beide Teilnehmer handeln die Geschwindigkeit aus. Es wird die höchste Geschwindigkeit verwendet die beide können bzw. erlaubt wird.
eine DM500 als höchste Geschwindigkeit 100 MBit/s kann, die Fritzbox 1000 MBit/s, ist die höchste gemeinsame Geschwindigkeit 100 MBit/s.

Einfach die Mount Optionen
x-systemd.automount,x-systemd.idle-timeout=360,noauto
hinzufügen.
noauto verhindert das normale mounten.
x-systemd.automount aktiviert den automounter.
x-systemd.idle-timeout=360 hebt den mount nach 360 Sekunden wieder auf. ist gemäß der eigenen Wünschen anzupassen.

Als alternative zu nfsstat kann man auch
grep " nfs" /proc/mounts
aufrufen (was nfsstat -m implizit auch macht).

nfs mounts funktionieren in der Regel auch ohne Parameter. Die default Parameter eines nativen mounts sind in der Regel sehr viel besser als die privaten Änderungen.
Wenn man keinen speziellen Grund hat sollte man an den defaults nichts ändern.

Protokoll: der nfs-default ist tcp. Ohne Übertragungsfehler gibt es keine Probleme mit udp. Mit Übertragungsproblemen läuft tcp besser.
rsize,wsize: der default ist 1MB, historisch wurden in Maschinen mit wenig Speicher kleinere Werte benutzt. Bei einer DM9x0 sind die 1MB unkritisch.
timeo,retry,soft/hard hier sind die defaults nicht für jeden Anwendungsfall sinnvoll.

Die Probleme handelt man sich mit rsize=8192,wsize=8192 + gelegentlichen Übetragungsfehlern ein.
Mit Standard NFS-mounts und fehlerfreier Übertragung gibt es das nicht. Die defaults für rsize/wsize liegen bei 1MB (nfs v4.x).

Die Leistungen des NAS teilen sich im Verhältnis der rsize/wsize Parameter der einzelnenen Verbindungen auf.

Derartige hänger die bei Dir mit UDP zu sehen waren lassen auf Übertragungsprobleme schließen. netstat -s und die Ethernet-statistiken helfen.
/sys/class/net/*/statistics oder auch ethtool -S <device>; ethtool <device>

Um mit der RC10 bedient zu werden braucht das Gerät eine Infrarotschnittstelle.
Ich vermute das diese Schnittstelle in der One nicht gibt. Aber das sollte Dir jemand beantworten der es weiß.

EgLe:
Habe mit einer dm920 getestet, kernel 3.14, Die dm7080 hat einen wesentlich älteren kernel 3.4. Das erklärt die Unterschiede.

Testweise auf dem Server den readonly export /export deaktivieren. Hatte mal Probleme mit verschachtelten exports.
Beim /export/Aufnahmen no_root_sqash hinzufügen, weil die Dreambox als root arbeitet

Auf der Dreambox den Server abmontieren und nur ein simples mount.nfs4 ausführen
umount 192.168.178.50:/export/Aufnahmen
mount.nfs4 192.168.178.50:/export/Aufnahmen /media/Aufnahmen

und die resultierenden mount-optionen ausgeben.
grep /media/Aufnahmen /proc/mounts

Wenn Du ohne Netzwerkbrowser arbeitest, sollte alles funktionieren.
Einfach unter /etc/enigma2/automount.xml umbenennen.

In die /etc/fstab eintragen:

192.168.178.50:/export/Aufnahmen /media/Aufnahmen nfs x-systemd.automount,x-systemd.idle-timeout=360,noauto,timeo=30,retry=0 0 2

Die Box booten, danach sollte es funktionieren...