PDA

View Full Version : [VU+ Duo] NFS Playback Problem with Chase Play



pacha2
26-03-13, 12:36
I have 2 boxes - 1 Vu Duo and 1 DM800.
I have the internal Duo drive connected to the DM800 via NFS and can usually playback recordings SD & HD fine on the DM800.

However I have problems if the program I am trying to watch is still being recorded.
Chase Play is what causes a big problem, the playback constantly stops and stutters. If I stop that timer and start a new recording then I can play the the recording fine.
I can also playback recording while the Duo is recording something else, but not the same file that is being actively recorded.

I have tried a number of different NFS mount options and also using CIFS too, but nothing has resolved the problem. The problem does not seem to be the network or the DM800 as once the recording has been stopped then playback is perfect.

On the Du I am currently running the ViX Image from May last year.

Kernel version: 3.1.1
Firmware version: 2.4
Gui version: May 13 2012

I'm thinking of trying another image, but wanted to see if anyone else has come across a similar problem?

Thanks.

Larry-G
26-03-13, 16:46
2.4 is a very old image, id recomend flashing to the latest ViX 3.0 image build 632 or higher.

Sent from my GT-I9300 using Tapatalk 2

pacha2
27-03-13, 00:56
Thanks for the reply.

I decided to upgrade and went for a total change, I chose the BlackHole 1.7.9 image on the Duo.

And it has exactly the same behaviour.
CIFS mounts from the Duo stutter repeatedly on the DM800
NFS works fine, except if you playback a file that is currently recording. It then pauses and stutters which gets worse the longer it plays for.

I will try some different NFS options on the sever and client to see if they make any difference. Previously these only made things worse....

Larry-G
27-03-13, 02:14
BH 1.7.9 is also a old image. Either try ViX 3.0-362 or BH 2.0.2

Sent from my GT-I9300 using Tapatalk 2

pacha2
27-03-13, 14:11
For vix do you mean build 362 or 632? :-)

mickyblueys
27-03-13, 17:39
632

Sent from my GT-I9100 using Tapatalk 2

Larry-G
27-03-13, 23:30
Yes I meant 632

Sent from my GT-I9300 using Tapatalk 2

pacha2
28-03-13, 21:02
Thanks for the replies.

I have now updated to the latest release and the problem seems the same if not worse.
Most HD Recordings stutter when played via NFS.

I haven't played with any NFS server settings yet, but would be grateful of any suggestions.

pacha2
28-03-13, 21:38
I've just tried using some of the recommended settings in /etc/exports

/media/hdd/ 192.168.1.0/255.255.255.0(rw,soft,upd,nolock,no_root_squash,sy nc,no_subtree_check)

When I restart nfs I receive this.

exportfs: /etc/exports:1: unknown keyword "soft"

pacha2
01-04-13, 12:19
I've carried out further tests and still experience the pausing and stuttering playback when playing something that is recording.
The CPU usage is very low on both boxes (less than 20%)

I have found this error below in /var/log/messages when I stop and start nfs with

/etc/init.d/nfsserver stop
/etc/init.d/nfsserver start
vuduo user.warn kernel: svc: failed to register lockdv1 RPC service (errno 124).
I've been unable to identify why this error occurs. It could be an IPV6 issue but I've not proved that.

My /etc/exports now only contains this

/media/hdd/movie 192.168.1.5(rw,no_root_squash,async,no_subtree_che ck)

And on the client the /etc/fstab is currently as below.


192.168.1.4:/media/hdd/movie /media/duo nfs rw,nolock,soft,async,udp,noatime,nodiratime,rsize= 32768,actimeo=90 1 0

andyblac
01-04-13, 16:46
I've carried out further tests and still experience the pausing and stuttering playback when playing something that is recording.
The CPU usage is very low on both boxes (less than 20%)

I have found this error below in /var/log/messages when I stop and start nfs with

/etc/init.d/nfsserver stop
/etc/init.d/nfsserver start
vuduo user.warn kernel: svc: failed to register lockdv1 RPC service (errno 124).
I've been unable to identify why this error occurs. It could be an IPV6 issue but I've not proved that.

My /etc/exports now only contains this

/media/hdd/movie 192.168.1.5(rw,no_root_squash,async,no_subtree_che ck)

And on the client the /etc/fstab is currently as below.


192.168.1.4:/media/hdd/movie /media/duo nfs rw,nolock,soft,async,udp,noatime,nodiratime,rsize= 32768,actimeo=90 1 0

hi

rsize=32768 is way to high, please try =8192

pacha2
01-04-13, 19:45
I've tried many different read sizes from 1024 to 32k. I've had it 8192 and the problem is consistent.

I can play HD recordings smoothly
I can play HD recordings when the Duo is recording smoothly
I cannot play the same HD recording that is being recorded. It plays for 3 seconds and then stutters and goes in slow motion.

Can someone confirm that this type of setup works for them with 2 e2 boxes via NFS please?

mickyblueys
01-04-13, 20:00
I've tried many different read sizes from 1024 to 32k. I've had it 8192 and the problem is consistent.

I can play HD recordings smoothly
I can play HD recordings when the Duo is recording smoothly
I cannot play the same HD recording that is being recorded. It plays for 3 seconds and then stutters and goes in slow motion.

Can someone confirm that this type of setup works for them with 2 e2 boxes via NFS please?

I am recording a show on a duo box downstairs in hd, and I'm watching it upstairs on my 2nd duo, for you're test.
It plays fine for one minute then the box downstairs suddenly rebooted. Upon reboot it starts to record again automatically, I start watching again upstairs, and this times it is doing both perfectly fine, no stuttering perfect quality. This using nfs shares.......hope this helps. Duo downstairs on vix 3.0 629, duo upstairs on vix 3.0 643

Not sure if the box downstairs actually crashed or just reboot, but here is the only Crash log reference I have, it has been sent direct from box 1364842602.13

Hope this all helps.

Sent from my GT-I9100 using Tapatalk 2

pacha2
01-04-13, 21:08
Thanks for the feedback. That's really good to hear that it works.

What channel did you try? Can you try a high bitrate one like Sky Sports 1-4 HD if you have that.

Are you using any customised NFS parameters on the client or server?

mickyblueys
01-04-13, 21:17
I tried bbc 1 hd, recorded Africa documentary. My nfs settings are basically default, I wouldn't really know what to alter or where to look.


Ok just tried sky sports hd 1......no problems. Plays perfect upstairs. Also downstairs box now vix 643 updated earlier.

Sent from my GT-I9100 using Tapatalk 2

white_westie
01-04-13, 23:01
Just to add my experience. I have used my stb (an ET9000) as an nfs server for the last 2 years with different images, with no problems. Current image is openVIX bld632, previous images where openAAF1.0 and EGAMI1.4. Client is a WDLIVE modified to use nfs, or an old E1 TM9100, and am having no problems with 'chase play' - which is something I regularly do.
Using default nfs settings on server and client - do have to agree with Andy that using high rsize in mount command on E1 box causes stutter.
Don't have sky, so can only test on BBC or ITV HD.

WW

andyblac
02-04-13, 00:02
guys, please bare in mind that duo has a maximum bandwidth of 100mbits (including overheads) i think you are pushing the limit with 2 HD streams as they can reach 40mbits per stream.

white_westie
02-04-13, 09:20
Quick question Andy - when recording a hd stream to a local disk, does it use the loopback address, and hence load the n/w interface?
If not, then why would you be pushing the stb when recording to a local disk, and sharing out a using an nfs export, as only the nfs would be using the n/w interface!

andyblac
02-04-13, 09:48
Quick question Andy - when recording a hd stream to a local disk, does it use the loopback address, and hence load the n/w interface?
If not, then why would you be pushing the stb when recording to a local disk, and sharing out a using an nfs export, as only the nfs would be using the n/w interface!

sorry,i re-read your posts, and i thought thought you where recording the stream the from a server box to the client box hdd, and also watching it from server box as well, that does require the stream to be streamed twice, as for playing a live recording via NFS, irc there is no timing yet on the ts file until the file is complete, so my guess is that NFS is having a hard time trying to keep resyncing with the file.

as a test could record the file to the client HDD and play the file from the HDD.

andy.

white_westie
02-04-13, 10:14
Dont have any disks on my clients, so cannot try that.
Not sure if OP has disks in both stbs' so maybe he can try that test for you.
As regards the ts timing issue, I know my WDLIVE just sees the size of the ts file when you start playback, and it ends when it reaches that point. I just stop/resume the playback and it updates the ts file time info.

pacha2
02-04-13, 11:07
Yes I have a USB in the client box I could test that, but I'm not clear what the test would prove?

You can see the time elapsed/remaining duration is constantly being updated by the client so as mentioned it is probably giving the NFS client some issues.

I've actually managed to stop this being updated every 3 seconds by using the NFS mount parameter actimeo=90, which allows it to update every 90 seconds. However the NFS playback issue remains the same.

I have access to a friends Duo today, so I will update that and run some more tests. This should then prove that the DM800 is the issue and I can justify switching that to an XP1000.

pacha2
02-04-13, 14:02
Using 2 Duo boxes with NFS the chase play scenario works flawlessly.

So it seems the DM800HD is not man enough for this type of playback.

Thanks for all your input

andyblac
02-04-13, 14:22
Using 2 Duo boxes with NFS the chase play scenario works flawlessly.

So it seems the DM800HD is not man enough for this type of playback.

Thanks for all your input

or the image, unfortunately i do not have any DMM boxes so i can;t build images for them. sorry.

pacha2
02-04-13, 16:15
I have tried multiple images on that box too. I am currently using an OpenPii image with the 2.6.18 kernal.
When testing I can see rpciod/0 taking up 10-20% cpu but I didn't think that was too high, it obviously is.
Where as the Duo's CPU looks hardly touched during NFS "chase play" playback.