DGburns, I have the very same sony file from usenet and it wont play properly via nfs, did you get it to play?
All my other HD stuff is fine, just annoying that the silly sony doesnt work.
First off, if we're talking about the same clip (a Greek cruise ship and lots of Greek island video) it's a Program Stream, not a Transport Stream, even though it's named '.ts'. Info about the clip also claims it is PCM audio, but I don't think this is correct or the clip would not have audio at all on the Roku. VLC stream info says the audio is 'mpga'.
I call the clip "Sony-Paradise_Blue.mpg", cuz that's a title screen in the clip.
My Roku = 2.0.34 firmware. Mplay v.3 of 8/10/05.
I just copied it from my Windows (XPPro-SP2) machine to my Linux (Mandrake LE2005) machine via SMB sharing. The transfer went at ~74Mbps (~8.8MB/sec). I long ago deinstall WindowsSFU so I can't test via NFS sharing from the XP machine.
I have both an SMB and a NFS share on that Linux machine. I telnet to the Roku and do timed copies using command:
[/code]time cp Sony-Paradise_Blue.mpg /dev/null[code]
From the SMB share, I get 10m39s @ average 3MB/sec.
From the NFS share, I get 3m44s @ average 8.3MB/sec.
So what you can see from this test is that
a) my hardware setup is able to stream across LAN in excess of Roku ability.
b) reading data via NFS is MUCH faster at the Roku than via SMB.
c) for this particular clip, "real time" was claimed by VLC to be 9m24sec, so you can see that under this test condition the Roku via SMB in theory has NO CHANCE to play it back properly.
As for playback in Mplay,
a) via SMB, the clip is "jumpy", audio drops out constantly, MPlay becomes non-responsive to the remote. The telnet session I had running was also unresponsive. In essence, I had to wait for the clip to run it's course in order for the Roku to be usable again (I didn't want to reboot it for this sequence of tests).
b) via NFS, the clip plays through all the way. Some occasional audio dropouts, very few video glitches. The remote and telnet session remained responsive.
I also tried using VLC on my Windows PC to convert the original mpg to a true Transport Stream. I did this with no video or audio codecs specified so that all VLC did was read the source and mux it to a ts file. I ran that ts through MPEG2REPAIR. It reported 24 video frame errors and 300+ secs of video timestamp gaps. After "fixing", the video frame errors are gone but 300+ timestamp gaps remain.
Playing this new version of the clip as a TS, essentially the same, though it 'felt' like there were fewer audio drops playing the TS over NFS than playing the PS over NFS.
Hope this info helps.
Oh. by the way, pretty girl....