ruckeln bei TS streams

[pantau]

und bei mir ruckelst mit suse 9.0 und nfs nach ca 10 bis 15 min mit Ts streams alex w release 17.02.04 ??????????????????????????

[wwershofen]

So, mittlerweile habe ich definitiv das Netzwerk als Grund für die Ruckler ausgemacht. Ob mich das der Lösung einen Schritt näher gebracht hat, weiß ich allerdings nicht.

Ich habe mit mittels "dd" einfach mal die ersten 10 MB eines Films, der von Anfang an ruckelt, rausgeschnitten und diese kleine Sequenz in's tmp-Verzeichnis der Box kopiert. Was soll ich sagen: das Ding spielt von dort aus wunderbar und ohne ruckeln. Der gleiche kleine Ausschnitt, diesmal über CIFS-Share vom Server abgespielt, ruckelt ohne Ende.

Damit kann also der Fehler weder bei der Aufnahme noch bei der Wiedergabe im movieplayer entstehen und es geht hier einzig und allein um die Netzwerk-Übertragung und die Mount-Optionen.

Soweit, sogut. Nachdem ich das herausgefunden hatte, habe ich versucht, das bisher über CIFS gemountete Verzeichnis des Linux-Servers per NFS auf der Box zu mounten. Das habe ich dann auch hinbekommen, allerdings, wenn ich einen NFS-gemounteten TS-Stream im movieplayer abspielen will, friert mir die Box umgehend ein. Ich komm' nur noch über telnet rein und kann da dann einen reboot machen, Fernbedienung, Bild und Ton sind weg!

Deswegen meine Bitte: Gibt es jemanden, der seine Box über einen Switch per NFS zu einem SuSE 9.0 Server verbunden hat und auf diesem Wege problemfrei TS-Streams auf dem movieplayer abspielen kann? Wenn ja, würden mich mal sämtliche Parameter des mounts sowie des NFS-Servers interessieren.

Bin für jede Hilfe dankbar.

cu
wolle

[Schwarzseher]

Bei mir läuft es unter Win2k Pro einwandfrei.

[gmo18t]

Hi,

also folgende Kombination geht prima:

SuSE 9.0 mit Kernel 2.6.2 und nfs server des K E R N E L S.
nfs mount mit default optionen der tuxbox (allerding gleich ganzes root filesystem, da remote-boot).

Sagem Kabel, AVIA600_vb028, int. uccode, AlexW Image vom 26.02, .spts_mode + .hw_sections in /var/etc...

- GMo -

[wwershofen]

SuSE 9.0 mit Kernel 2.6.2 und nfs server des K E R N E L S.

Was verstehst Du unter "nfs server des Kernels"? Ich starte den nfsserver über /etc/init.d/nfsserver und darin wird /usr/sbin/rpc.nfsd aufgerufen. Laut man rpc.nfsd startet dieser das NFS-Kernel-Modul nfsd.o, welches ich auch per "lsmod" angezeigt bekomme.

Oder meinst Du, das der nfsserver nicht als Modul sondern direkt in den Kernel kompiliert werden soll?

Werd wohl auch mal den 2.6er Kernel einsetzen, fahre bislang noch 2.4.21

thx
wolle

[wwershofen]

Bevor ich den Linux-Kernel auf meinem Streaming-Server aktualisiere, möchte ich Euch die Ergebnisse meiner Log-Sitzung bezüglich des Problems mit dem "Einfrieren" der dBox beim Abspielen von TS-Streams auf einem NFS-Mount nicht vorenthalten. Vielleicht findet ja jemand dadrin noch irgendwas, womit das Problem begründet werden könnte. Ich kenn' mich leider netzwerktechnisch nicht so gut aus, als das ich das interpretieren könnte.

Ich habe heute mal das Log der dBox per seriellem Kabel und dBox-Bootmanager aufgezeichnet und gleichzeitig auf dem Streaming-Server ein "tcpdump -ni eth0 host dBoxII" mitlaufen lassen. Auf diese Weise hoffe ich, so viel wie möglich aussagekräftige Meldungen generiert zu haben. Aufgrund der Größe der Logs habe ich hier nur die aus meiner Sicht relevanten Auszüge gepostet, die vollen Logs gibt's zum Download unter den folgenden Links:
DBox-Bootlog
tcpdump-Log

Zum Test-Setup:
Ich habe auf der dBox das Verzeichnis /dvr meines Linux-Servers einmal via NFS auf /mnt/filme und einmal unter CIFS auf /mnt/custom gemounted. Auf dem Server läuft der Kernel-NFS-Server des Kernels 2.4.21 und Samba 2.2.8 unter SuSE 9.0. Es sind 8 nfs-Threads gestartet und meine /etc/exports sehen so aus:

wolle@athlon:~> cat /etc/exports
# See exports(5) for a description.
# This file contains a list of all directories exported to other computers.
# It is used by rpc.nfsd and rpc.mountd.
/dvr 192.168.97.0/255.255.255.0(ro,no_root_squash,async)

Der Server hat die IP 192.168.97.2 und die Box hat 192.168.97.101

Beim Mounten des Verzeichnisses (einmal NFS, einmal CIFS) sieht das im dBox-Log so aus:

Using /lib/modules/2.4.25-rc2-dbox2/kernel/net/sunrpc/sunrpc.o
Using /lib/modules/2.4.25-rc2-dbox2/kernel/fs/lockd/lockd.o
Using /lib/modules/2.4.25-rc2-dbox2/kernel/fs/nfs/nfs.o
Mount(0) 192.168.97.2:/dvr -> /mnt/filme
SUPPORT: NFS: 2, CIFS: 2
SUPPORT: NFS: 2, CIFS: 2
Using /lib/modules/2.4.25-rc2-dbox2/kernel/fs/cifs.o
Mount(1) 192.168.97.2:dvr -> /mnt/custom
CIFS: Unknown mount option nolock
CIFS: Unknown mount option udp

Die gemounteten Einträge sehen so aus:

~ > mount
/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
/proc on /proc type proc (rw)
/dev/mtdblock/3 on /var type jffs2 (rw)
ramfs on /tmp type ramfs (rw)
192.168.97.2:/dvr on /mnt/filme type nfs (ro,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.97.2)
//192.168.97.2/dvr on /mnt/custom type cifs (ro,unc=\192.168.97.2\dvr,username=wolle,domain=,rsize=8192,wsize=8192)

Zunächst der Versuch, den TS-Stream über CIFS abzuspielen. Der Stream ruckelt von Beginn an, aber immerhin kommt was. Im dbox-Log sah das so aus:

[movieplayer.cpp] actionKey=tsplayback
CBookmarkManager: read bookmarkcount:1
CBookmarkManager: read bookmarkname:
CBookmarkManager: read bookmarkurl: /mnt/filme/Heidi.ts
CBookmarkManager: read bookmarktime: 789202944
Startplay
[movieplayer.cpp] found pida: 0x0A00 ; pidv: 0x09FF ; ac3: 0
SPTS, queue 0 extended.
SPTS, queue 0 extended.
SPTS, queue 0 extended.
[controld] VIDEO_EVENT_SIZE_CHANGED 480x576 (4:3 -> 4:3)
Stopp gedrückt
PES, queue 0 normal.
[basicsocket] send_data: Resource temporarily unavailable
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 4:3)
PES, queue 0 normal.

Auf dem Server sah der zugehörige Netzwerk-Traffic in tcpdump so aus:

12:57:23.366063 192.168.97.101.1025 > 192.168.97.2.139: P 810:897(87) ack 1934 win 6972 <nop,nop,timestamp 200121 594627002> NBT Packet (DF)
12:57:23.366395 192.168.97.2.139 > 192.168.97.101.1025: P 1934:2099(165) ack 897 win 6432 <nop,nop,timestamp 594631630 200121> NBT Packet (DF) [tos 0x10]
12:57:23.367113 192.168.97.101.1025 > 192.168.97.2.139: . ack 2099 win 6972 <nop,nop,timestamp 200121 594631630> (DF)
12:57:23.368171 192.168.97.101.1025 > 192.168.97.2.139: P 897:995(98) ack 2099 win 6972 <nop,nop,timestamp 200121 594631630> NBT Packet (DF)
12:57:23.368680 192.168.97.2.139 > 192.168.97.101.1025: P 2099:2206(107) ack 995 win 6432 <nop,nop,timestamp 594631632 200121> NBT Packet (DF) [tos 0x10]
12:57:23.370046 192.168.97.101.1025 > 192.168.97.2.139: P 995:1082(87) ack 2206 win 6972 <nop,nop,timestamp 200122 594631632> NBT Packet (DF)
12:57:23.370132 192.168.97.2.139 > 192.168.97.101.1025: P 2206:2371(165) ack 1082 win 6432 <nop,nop,timestamp 594631634 200122> NBT Packet (DF) [tos 0x10]
12:57:23.405779 192.168.97.101.1025 > 192.168.97.2.139: P 1082:1145(63) ack 2371 win 6972 <nop,nop,timestamp 200125 594631634> NBT Packet (DF)
12:57:23.406081 192.168.97.2.139 > 192.168.97.101.1025: . 2371:3811(1440) ack 1145 win 6432 <nop,nop,timestamp 594631670 200125> NBT Packet (DF) [tos 0x10]
12:57:23.406102 192.168.97.2.139 > 192.168.97.101.1025: . 3811:5251(1440) ack 1145 win 6432 <nop,nop,timestamp 594631670 200125> NBT Packet (DF) [tos 0x10]
12:57:23.409343 192.168.97.101.1025 > 192.168.97.2.139: . ack 5251 win 12960 <nop,nop,timestamp 200126 594631670> (DF)
12:57:23.409380 192.168.97.2.139 > 192.168.97.101.1025: P 5251:6530(1279) ack 1145 win 6432 <nop,nop,timestamp 594631673 200126> NBT Packet (DF) [tos 0x10]

Hier jetzt der erfolglose Versuch, per NFS-Mount den TS abzuspielen. Dbox-Log:

[movieplayer.cpp] actionKey=tsplayback
CBookmarkManager: read bookmarkcount:1
CBookmarkManager: read bookmarkname:
CBookmarkManager: read bookmarkurl: /mnt/filme/Heidi.ts
CBookmarkManager: read bookmarktime: 789202944
Startplay
nfs: server 192.168.97.2 not responding, timed out
---(Meldung 9x wiederholt)---
[movieplayer.cpp] found pida: 0x0A00 ; pidv: 0x09FF ; ac3: 0
SPTS, queue 0 extended.
nfs: server 192.168.97.2 not responding, timed out
---(Meldung 29x wiederholt)---
SPTS, queue 0 extended.
SPTS, queue 0 extended.
nfs: server 192.168.97.2 not responding, timed out
---(Meldung 16x wiederholt)---
[controld] VIDEO_EVENT_SIZE_CHANGED 480x576 (4:3 -> 4:3)
nfs: server 192.168.97.2 not responding, timed out
---(Meldung undendlich-mal wiederholt)---

Die Box ist also tatsächlich nicht eingefroren, sondern wartet nur Ewigkeiten auf den NFS-Server. tcpdump sagt dazu folgendes:

11:43:47.044471 192.168.97.101.1589620918 > 192.168.97.2.2049: 92 access [|nfs] (DF)
11:43:47.044622 192.168.97.2.2049 > 192.168.97.101.1589620918: reply ok 120 access c 39372e31 (DF)
11:43:47.045876 192.168.97.101.1589620919 > 192.168.97.2.2049: 104 access [|nfs] (DF)
11:43:47.045914 192.168.97.2.2049 > 192.168.97.101.1589620919: reply ok 120 access c 39372e31 (DF)
11:43:47.047213 192.168.97.101.1589620920 > 192.168.97.2.2049: 112 getattr [|nfs] (DF)
11:43:47.047244 192.168.97.2.2049 > 192.168.97.101.1589620920: reply ok 112 getattr REG 100644 ids 500/100 [|nfs] (DF)
11:43:47.048452 192.168.97.101.1589620921 > 192.168.97.2.2049: 116 access [|nfs] (DF)
11:43:47.048480 192.168.97.2.2049 > 192.168.97.101.1589620921: reply ok 120 access c 39372e31 (DF)
11:43:47.084040 192.168.97.101.1589620922 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:47.084283 192.168.97.2 > 192.168.97.101: udp (frag 64295:1288@2944)
11:43:47.084299 192.168.97.2 > 192.168.97.101: udp (frag 64295:1472@1472+)
11:43:47.084314 192.168.97.2.2049 > 192.168.97.101.1589620922: reply ok 1464 read (frag 64295:1472@0+)
11:43:47.089723 192.168.97.101.1589620923 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:47.089820 192.168.97.2 > 192.168.97.101: udp (frag 64296:968@7360)
11:43:47.089831 192.168.97.2 > 192.168.97.101: udp (frag 64296:1472@5888+)
11:43:47.089838 192.168.97.2 > 192.168.97.101: udp (frag 64296:1472@4416+)
11:43:47.089849 192.168.97.2 > 192.168.97.101: udp (frag 64296:1472@2944+)
11:43:47.089927 192.168.97.2 > 192.168.97.101: udp (frag 64296:1472@1472+)
11:43:47.090052 192.168.97.2.2049 > 192.168.97.101.1589620923: reply ok 1464 read (frag 64296:1472@0+)
11:43:47.094679 192.168.97.101.1589620924 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:47.094773 192.168.97.2 > 192.168.97.101: udp (frag 64300:968@7360)
11:43:47.094780 192.168.97.2 > 192.168.97.101: udp (frag 64300:1472@5888+)
11:43:47.094786 192.168.97.2 > 192.168.97.101: udp (frag 64300:1472@4416+)
11:43:47.094792 192.168.97.2 > 192.168.97.101: udp (frag 64300:1472@2944+)
11:43:47.094876 192.168.97.2 > 192.168.97.101: udp (frag 64300:1472@1472+)
11:43:47.095001 192.168.97.2.2049 > 192.168.97.101.1589620924: reply ok 1464 read (frag 64300:1472@0+)
11:43:48.461042 192.168.97.101.1589620923 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:48.461268 192.168.97.2 > 192.168.97.101: udp (frag 64301:968@7360)
11:43:48.461282 192.168.97.2 > 192.168.97.101: udp (frag 64301:1472@5888+)
11:43:48.461295 192.168.97.2 > 192.168.97.101: udp (frag 64301:1472@4416+)
11:43:48.461307 192.168.97.2 > 192.168.97.101: udp (frag 64301:1472@2944+)
11:43:48.461376 192.168.97.2 > 192.168.97.101: udp (frag 64301:1472@1472+)
11:43:48.461501 192.168.97.2.2049 > 192.168.97.101.1589620923: reply ok 1464 read (frag 64301:1472@0+)
11:43:51.213487 192.168.97.101.1589620924 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:51.213726 192.168.97.2 > 192.168.97.101: udp (frag 64302:968@7360)
11:43:51.213740 192.168.97.2 > 192.168.97.101: udp (frag 64302:1472@5888+)
11:43:51.213754 192.168.97.2 > 192.168.97.101: udp (frag 64302:1472@4416+)
11:43:51.213766 192.168.97.2 > 192.168.97.101: udp (frag 64302:1472@2944+)
11:43:51.213834 192.168.97.2 > 192.168.97.101: udp (frag 64302:1472@1472+)
11:43:51.213959 192.168.97.2.2049 > 192.168.97.101.1589620924: reply ok 1464 read (frag 64302:1472@0+)
11:43:53.965957 192.168.97.101.1589620923 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:53.966193 192.168.97.2 > 192.168.97.101: udp (frag 64303:968@7360)
11:43:53.966207 192.168.97.2 > 192.168.97.101: udp (frag 64303:1472@5888+)
11:43:53.966220 192.168.97.2 > 192.168.97.101: udp (frag 64303:1472@4416+)
11:43:53.966232 192.168.97.2 > 192.168.97.101: udp (frag 64303:1472@2944+)
11:43:53.966300 192.168.97.2 > 192.168.97.101: udp (frag 64303:1472@1472+)
11:43:53.966424 192.168.97.2.2049 > 192.168.97.101.1589620923: reply ok 1464 read (frag 64303:1472@0+)
11:43:59.470894 192.168.97.101.1589620924 > 192.168.97.2.2049: 124 read [|nfs] (DF)
11:43:59.471121 192.168.97.2 > 192.168.97.101: udp (frag 64304:968@7360)
11:43:59.471135 192.168.97.2 > 192.168.97.101: udp (frag 64304:1472@5888+)
11:43:59.471148 192.168.97.2 > 192.168.97.101: udp (frag 64304:1472@4416+)
11:43:59.471160 192.168.97.2 > 192.168.97.101: udp (frag 64304:1472@2944+)
11:43:59.471229 192.168.97.2 > 192.168.97.101: udp (frag 64304:1472@1472+)
11:43:59.471352 192.168.97.2.2049 > 192.168.97.101.1589620924: reply ok 1464 read (frag 64304:1472@0+)

Auffällig ist hier wohl, daß die replies des servers im Abstand von mehreren Sekunden kommen - von einem Stream kann da wohl keine Rede mehr sein. Außerdem werden die Pakete ja scheinbar ganz schön zerhackt.

Wenn jemand hierzu irgendwelche Tipps für mich hätte, wäre ich sehr dankbar.

thx
wolle

[gmo18t]

Hi,

@wwershofen
na, da ist ja bei Dir ja eine knifflige Geschichte, irgendwie muss das
doch zu lösen sein ...

Ich benutze auch den nfs Server als Kernelmodul (ist schon recht so), aber da ich ja per remote-boot nfs mounte, sind bei mir die Parameter des DBox mounts etwas anders, hab aber nur noch rsize u. wsize im Kopf -> beides 4096 und "v2" (schau heut abend nochmal genauer nach). Ob's mit nfs protokoll version 3 was aufs sich hat ? Im 2.6er
gibt's auch schon Version 4 (experimental). Außerdem hab ich noch
"provide NFS Server over TCP support (experimental)" aktiviert -> ob dann defaultmäßig TCP anstelle UDP genommen wird ?

Vielleicht hat ja der 2.6er nfs server ein paar Verbesserungen gegenüber dem 2.4er ? -> probier in jedem Fall den 2.6er Kernel !

- GMo -

[gmo18t]

Hi,

http://nfs.sourceforge.net/nfs-howto/performance.html hier sollten auch ein paar nützliche Tips zu finden sein !

- GMo -

[sir-zock-a-lot]

Sehr umfangreich, aber wirklich gut:

http://www.netapp.com/tech_library/3183.html#3.1.

Mal was anderes: Kannst dein NFS-share von einem anderen Client mounten ? Oder gar mal versuchen, ein NFS-share auf der gleichen Kiste lokal zu mounten ? Laeuft der portmapper ?

Gruss,
Patrick

[wwershofen]

Außerdem hab ich noch
"provide NFS Server over TCP support (experimental)" aktiviert -> ob dann defaultmäßig TCP anstelle UDP genommen wird ?

You made my day!

Das war der entscheidene Hinweis! tcp statt udp in den Mountoptionen auf der dBox brachte den alles entscheidenen Durchbruch! Ich kann jetzt TS-Streams, die via NFS gemounted sind, abspielen - und zwar ohne Ruckeln !!! (und ohne den neuen Linux-Kernel zu verwenden )

Wow, mir fällt ein Stein vom Herzen!

Für alle, die ähnliche Probleme haben und meine Lösung nachbauen wollen, hier die Mount-Optionen:

1.Zeile: ro,soft,tcp,nolock
2.Zeile: rsize=16384,wsize=16384

oder für die, die per telnet mounten wollen:

Code: Alles auswählen

mount -t nfs <server-ip>:/<verzeichnis> /mnt/filme -o ro,soft,nolock,tcp,rsize=16384,wsize=16384

Ein kleines Problem gilt es jedoch noch zu lösen:
Wenn ich im Movieplayer mit den Nummerntasten der Fernbedienung im Stream hin und her springe, gibt es bei den 5 Minutensprüngen fast immer einen schwarzen Bildschirm und keinen Ton, obwohl der Stream an der richtigen Stelle fortgesetzt wird - einmal kurz Pause drücken behebt das Problem.
Bei 5-Minuten-Sprüngen tritt das Problem fast immer auf, bei 10 Minuten manchmal und bei 1-Minuten-Sprüngen gar nicht.
Das habe ich bei den bisherigen Streams via CIFS noch nie gehabt.

Liegt das vielleicht am Image? Habe z.Zt. alexW-Release vom 17.2. drauf. Werde mal das JtG-Image, was ich vorher benutzt habe, nochmal draufspielen, mal sehen, ob das damit hinhaut.

Big THX to all of you
wolle

[wwershofen]

Sehr umfangreich, aber wirklich gut:

http://www.netapp.com/tech_library/3183.html#3.1.

... und da steht auch der Grund drin, warum UDP bei mir nicht funktioniert:

NFS over UDP has deficiencies that are exposed on congested networks, such as routed multi-speed networks

Die Verbindung zwischen Server und dBox geht über einen autosensing Switch, der Server hat eine 10/100MBit Karte während die Box als einziger Client in meinem Netzwerk (4 PCs, 1 Printerserver, 1 dBox) ja nur 10MBit hat.
Jetzt wird mir auch klarer, warum ich seit dem Zeitpunkt, als ich meinen alten 10MBit-Hub durch den Switch ersetzt habe, keine MP3-Files mehr über NFS auf der Box abspielen konnte.

Man lernt eben nie aus!

cu
wolle

[Schwarzseher]

You made my day!

Herzlichen Glückwunsch!

Ein kleines Problem gilt es jedoch noch zu lösen:
Wenn ich im Movieplayer mit den Nummerntasten der Fernbedienung im Stream hin und her springe, gibt es bei den 5 Minutensprüngen fast immer einen schwarzen Bildschirm und keinen Ton, obwohl der Stream an der richtigen Stelle fortgesetzt wird - einmal kurz Pause drücken behebt das Problem.

Ist bei mir genauso, mit alexW und jtg auf einer Sagem 1xI.

[sir-zock-a-lot]

Na wunderbar

Liegt das vielleicht am Image? Habe z.Zt. alexW-Release vom 17.2. drauf.

Ich denke nein, das waere mir und vor allem meiner besseren Haelfte schon aufgefallen.

Na dann viel Spass beim ruckelfreien Gucken

Gruesse,
Patrick

[charly123]

Jetzt wird mir auch klarer, warum ich seit dem Zeitpunkt, als ich meinen alten 10MBit-Hub durch den Switch ersetzt habe, keine MP3-Files mehr über NFS auf der Box abspielen konnte.

und was machste jetzt ? wieder deinen alten 10 MBit Hub hervorkramen ?

[wwershofen]

und was machste jetzt ? wieder deinen alten 10 MBit Hub hervorkramen ?

Nö, warum?

Ich habe mir bis heute damit geholfen, die MP3-Files über ein CIFS-Share zu mounten. Nach den Erkenntnissen von heute, das NFS zur Box in meinem Netzwerk nur über TCP und nicht über UDP geht, kann ich nun mit den oben genannten Mount-Optionen auch wieder per NFS MP3 abspielen - mit dem Switch natürlich.

Den Hub findest Du demnächst bei EBay.

cu
wolle

[sapsitapsi]

Wie kann ich die Box dazu bewegen, mit NFS v3 zu mounten? Ich habe das 20040217-AlexW drauf. Egal. ob ich über Neutrino oder per Telnet mounte, er nimmt immer v2. Das hat die unannehme Folge, daß rsize/wsize ein Maximum von 8192 haben und die TS-Streams ruckeln.

Vielen Dank,
sapsi

[gmo18t]

Hi,

versuch mal, ob die Option "nfsvers=3" was hilft. Wichtig ist aber, daß der nfs-server auch V3 unterstützt, d.h. bei Linux sollte die enstprechende Kerneloption vor dem Kompilieren ausgewählt sein.
-> mit "rpcinfo -p" kannst Du überprüfen, welche Versionen Dein linux nfs-server kennt ...

- GMo -

[wwershofen]

Wie kann ich die Box dazu bewegen, mit NFS v3 zu mounten?

Bei mir hat die Box das mit dem gleichen Image automatisch gemacht, daher denke ich, daß es tatsächlich an Deinem Server liegt. Ein Tip von sir-zock-a-lot (c):

Hast Du vielleicht in Deiner Prozesstabelle sowas wie
/usr/sbin/rpc.mountd --no-nfs-version 3
stehen? Das war wohl bei älteren Debians der Fall...

Welchen Kernel hast Du denn Laufen? Bei mir läuft ein 2.4.21 wunderbar

cu
wolle

[sapsitapsi]

Vielen Dank für Eure Hilfe!

Der Fall hat sich geklärt.

Ich habe nochmal meine Kernel-Setting überprüft, NFS v3 war drin, aber ...
ich hatte noch einen Userland-NFS-Server für Version 2. Naja, mein Debian-System läuft schon ein paar Jahre, und trotz regelmäßigem Update (testing) wurde der Userland-NFS-Server nie herausgenommen. Aber jetzt läufts

CU,
sapsi

[tehr]

Schön, dass es bei Euch funktioniert.

Wenn ich versuche, bei den mount-Optionen tcp anzugeben, bekomme ich immer den Fehler:

Mount-Fehler: lade Default-Einstellungen.

Ausprobiert habe ich einige yadi-Images seit dem 30.05.04. Leider war keines dabei, das tcp unterstützt.

Der NFS-Server ist ein SuSE-Linux 8.0 mit Kernel 2.4.18. Lasse ich die Option tcp weg, funktioniert im Prinzip alles, nur die Wiedergabe von TS mit dem Movieplayer ruckelt. Das Ruckeln scheint abhängig von der Datenrate zu sein.

Die Verkabelung besteht aus einem 100er Switch an dem neben der Dbox und dem NFS-Server noch einige Rechner hängen, die aber praktisch keinen Traffic verursachen.