Greetings,

Flashed mmcplus52MHz kernel, downloaded and installed extra NFS modules and was able to mount NFS-shared tree on my home Linux box from Nokia without a problem. Played some mp3 files directly from the server but the playback was interrupted every time network was accessed (the LEDs on my router blinked) as if the player did not attempt to buffer input at all. Tried increasing NFS buffer size to a max rsize=32768, this only makes the playback choke less frequently but still pretty much unusable. Using MPlayer instead of standard Audio Player did not make much difference apart from it tending to block the GUI completely. Am I doing something wrong or just expecting too much from a poor little Nokia girl?

Tests were done with Nokia sitting right in front of my Netgear RangeMax 240 wireless router.

Cheers,
Ivan

Try running mplayer with the cache option "mplayer -cache 8192". I don't think the problem is with the 770 as much as the applications looking at a NFS mounts as being local drives so you're running into transfer rate issues. If I remember correctly MMC Mobile card transfer rate is 20 MB or 80 Mbps...a wee bit faster then wi-fi. I'm not overly familiar with the cache function of mplayer though, so I can say for certain with will even matter with what you are trying to do.

I'd definitely try -cache option on mplayer. What puzzles me however is that both players behave as if neither their I/O layer nor the underlaying OS knows nothing about buffering. It's like they play a 32KB chunk of data, stop and wait until another 32KB are delivered across NFS/WiFi, only then resume playing that block. Is it normal? Besides, I don't think the problem is in WiFi throughput but more likely in its large latency. As such, if you try reading data in relatively small blocks (max 32K in case of NFS) you end up spending most of your time awaiting the next block wireless transfer negotiated. To avoid this situation one need to use extensive read-ahead buffering or a dedicated streaming protocol with feedback control.

I was just wondering if I maybe missed something important in configuration or is it the expected behavior.

--Ivan

MPlayer uses -cache option even by default (with some small buffer), so it is not quite clear what causes the problem. In general, I noticed that overall stability gets worse and the device lockups and reboots more often when using wifi (not only for MPlayer). Don't know if stability got improved with the latest software update, I'm still using 'mistral' on my device.

You can try testing NFS with USB networking or probably bluetooth, it is interesting if the results are better in this case.

Try Canola or Media Streamer.

Ok, I sort of figured out what was the culprit: the GUI file open dialogue/FileManager. Tried starting mplayer from xterm and the playback was just fine with the NFS-mounted file specified on command line. But FileManager (as well as file open applet) attempts to scan through the whole tree every time you want to open a single file! Of course, with 30,000+ mp3 files to go it consumes memory pretty soon leaving Nokia kernel with no free space for filesystem caching. It also seems to have a memory leak since memory is never fully released until a reboot. Apparently, Maemo developers have never actually tested GUI tools against a multi-thousand file trees...

@zlatoust: It might be worth raising that behaviour as a bug in https://maemo.org/bugzilla/