network recording stutter when played?

[zenith]

i have a vu duo with hdd and two xp1000 on same network nfs sharing all mounted no problem.
i also have pc mounted on cifs mounted no problem.
i can play a recording on the xp1000s no problem too fro vu duo hdd.
nfs shares and samba on all boxes enabled.
problem starts when trying to watch a live recording on xp1000 box.
its like it is in slow motion but plays fine once recording finished?
can anyone help at all.

 

[judge]

what's the speed of your network, wired or wireless?
recording & watching HD at the same time over a slower network could easily cause this.
Saying that, I don't have an xp1000 so don't know how well it works watching a currently recording show on playback but presume it should be fine.

 

[zenith]

got a wndr3700 netgear router all wired no wireless?
as i say watching hd no problem unless recording.
all boxes are vix image 649.
i have recently had to reinstall vix 3.0.649 but played before this,unfortunately did`nt make a backup.

 

[judge]

you should still be able to find older images on http://www.world-of-satellite.com/enigma2/openvix/
also, maybe try cifs mounts & let us know if there's any difference.

 

[zenith]

my other xp1000 box plays no problem but the one i am having problems with does not same box too?

 

[zenith]

think i have sorted it.
removed all my mounts wiped contents of fstab folder don`t delete it!
and full restarted box not enigma restart,fresh and reinstalled.
think i corrupted fstab folder somehow originally.

 

[zenith]

spoke too soon back to same slow motion stutter
is there any other folders i should be looking at other than fstab one?
below is mount in telnet

rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=118100k,nr_inodes=29525,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /media type tmpfs (rw,relatime,size=64k)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
/dev/sda1 on /media/usb type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
//192.168.1.6/export on /media/net/andy type cifs (rw,mand,relatime,vers=1.0,sec=ntlm,cache=loose,unc=\192.168.1.6\export,username=andy,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.6,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
192.168.1.12:/media/hdd/ on /media/net/XP1000 type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,soft,nolock,proto=tcp,port=65535,timeo=14,retrans=3,sec=sys,local_lock=all,addr=192.168.1.12)
192.168.1.16:/media/hdd/ on /media/net/VUDUO type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,soft,nolock,proto=tcp,port=65535,timeo=14,retrans=3,sec=sys,local_lock=all,addr=192.168.1.16)
root@dining:~#

 

[dfdream]

I too have this issue with a solo. (similar spec to xp1000)
I think the is that these devices havent enough power.
I record from the SOLO onto the HDD of the DUO. If I watch a recording on solo from duo while another recording is going on the solo the stuttering happens.
There is a little slowness switching channels while recording but playback while recording across the network on the solo is a no go.
Dont know if there is the same issue on faster boxes like DUO/SOLO2 etc.

 

[Rob van der Does]

I can assure you that any box is capable of doing that: recording and playback of multiple files will only use a few % of the CPU.
More likely is the lan-bandwith: in your case all recordings and playback goes via lan; that is simply too much.

 

[pacha2]

I have experienced similar problems in the past. Troubleshooting these does take take, but it's definitely a reasonable setup that you have.

Firstly you must always test with the same channel and same class of program as the bitrates do vary considerably between channels and even programmes on the same channel. I think Sky Sports is usually a high bandwidth one.

If you have 3 (1 server, 2 clients) boxes and the chase play streaming scenario works on one (client a) but not on another (client b) some things to check are
1. The network connectivity on client b. I would always recommend wired over wifi or homeplugs. If you stop the recording does the same file then play without stuttering?
2. Firmware version of both boxes
3. CPU usage of all 3 boxes (top)
4. NFS mount setup on clients. I use UDP as its supposed to give best performance.

 

[pooface]

Yes, I would say defo a bandwidth issue... previously, I used to have a 100mbps network connection to a nas drive. I would be recording to the mass drive on 1 box and watching something else from another and get stuttering...

Now, I have 1GB lan, and don't get the same problems...

Sent from my GT-I9300 using Tapatalk 2

 

[zenith]

answers to the questions below-

If you have 3 (1 server, 2 clients) boxes and the chase play streaming scenario works on one (client a) but not on another (client b) some things to check are
1. The network connectivity on client b. I would always recommend wired over wifi or homeplugs. If you stop the recording does the same file then play without stuttering? all boxes are lan no wireless.box upstairs plays recordings while live recording takes place on vu duo.
2. Firmware version of both boxes-all the same 3.1.649
3. CPU usage of all 3 boxes (top)-not sure how to check that?
4. NFS mount setup on clients. I use UDP as its supposed to give best performance.[/QUOTE]-sorry udp?i set mine up fstab nfs share.
when i play after recording finished it plays fine only stutter when recording a film or program and try to watch that film or program via recording.
i have a netgear wndr3700

 

[pacha2]

1. I had this same issue previously with a much lower spec'd box, and as you have it working on one of clients this scenario should be possible on both. With a few more tests we should be able to identify the cause.
2. That looks good, so we can ignore this one now
3. You neeed to Telnet on to each of the boxes and type "top" without the quotes. Do this before you start recording/playback and leave it open when you start recording/playback and observe how it changes.
4. Looking again at your setup above it's not clear to me which box is what. I think you have the following, could you correct and/or confirm please?
192.168.1.6 - Duo
192.168.1.16 - ?? XP1000 (Working Client a)
192.168.1.12 - ?? XP1000 (non-working client b)
Can you share the contents of /etc/fstab of both client boxes?

 

[zenith]

192.168.1.16 - Duo
192.168.1.12 - ?? XP1000 (Working Client a)
192.168.1.20 - ?? XPdining (non-working client b)
Can you share the contents of /etc/fstab of both client boxes?[/QUOTE]

fstab working client telnet
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=118100k,nr_inodes=29525,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /media type tmpfs (rw,relatime,size=64k)
/dev/sda1 on /media/hdd type ext4 (rw,relatime,data=ordered)
tmpfs on /var/volatile type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
//192.168.1.15/export on /media/net/andy type cifs (rw,mand,relatime,vers=1.0,sec=ntlm,cache=loose,unc=\192.168.1.15\export,username=andy,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.15,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
192.168.1.20:/media/usb/ on /media/net/DINING type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,soft,nolock,proto=tcp,port=65535,timeo=14,retrans=3,sec=sys,local_lock=all,addr=192.168.1.20)
192.168.1.16:/media/hdd/ on /media/net/VUDUO type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,soft,nolock,proto=tcp,port=65535,timeo=14,retrans=3,sec=sys,local_lock=all,addr=192.168.1.16)
root@xp1000:~#


fstab non working client mount telnet
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=118100k,nr_inodes=29525,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /media type tmpfs (rw,relatime,size=64k)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sda1 on /media/usb type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
192.168.1.16:/media/hdd/ on /media/net/VUDUO type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,soft,nolock,proto=tcp,port=65535,timeo=14,retrans=3,sec=sys,local_lock=all,addr=192.168.1.16)
root@dining:~#

 

[pacha2]

Well the NFS mounts on both clients are exactly the same so if it works on one in theory it should work on the other too.
You've got a lot of options on the NFS mount, is this by design?
But you could try changing "proto=tcp" to "proto=udp", and perhaps add async
I have experiemented with a few options and I'm currently using

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

Does the output from "top" show anything strange, especially on the XPdining box?

 

[zenith]

just done a check of the cpu
on box upstairs working one it does`nt go over 30% usage.
one downstairs at a peak uses 51% at peak does`nt go lower than 30%

 

[zenith]

the idle on both vu duo and xp1000 upstairs is in the 92%
also %usz for usr/bin/enigma2 is xp1000 81% vu duo is 118%
xpdining is idle is 68%.
also %usz for usr/bin/enigma2 is only 47%
these figures seem to show big differences

 

[zenith]

Well the NFS mounts on both clients are exactly the same so if it works on one in theory it should work on the other too.
You've got a lot of options on the NFS mount, is this by design?
But you could try changing "proto=tcp" to "proto=udp", and perhaps add async
I have experiemented with a few options and I'm currently using

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

Does the output from "top" show anything strange, especially on the XPdining box?

setup automatically the mounts did`nt change anything that was automatically rw,nolock,tcp there only the passwords or locations.

 

[pacha2]

First thing I would do is perform a full reboot of all the boxes.
Hopefully this should get the CPU levels to a sensible level. Check with top.
If not share the top output so we can see the problematic processes.
Re-test the streaming scenarios

On my Duo I have a daily reboot scheduled (Power Timer) as I've come across strange high CPU usage when left running for a week or so.

 

[judge]

rebooting a box won't fix bandwith useage...
this does really seem like a local network read/write issue.
if you are recording HD over a network & watching it back as you are also recording, make sure your local network is up to it.