"WRITE ERROR on recording, disk full?" messages now and then

[rassi]

Anyone, tips for this issue?

Problem started again. Trying watch one SDTV recording and doing one recording.

[TIMER] record time changed, start prepare is now: Wed Dec 12 15:13:29 2012
[Timer] Record RecordTimerEntry(name=Talent USA, begin=Wed Dec 12 15:13:49 2012, serviceref=1:134:1:0:0:0:0:0:0:0:FROM BOUQUET "alternatives.jim.tv" ORDER BY bouquet, justplay=0)
[TIMER] activating state 1
[RecordTimer] media is not mounted: /media/hdd/movie
[TIMER] backoff: retry in 5 seconds
[RecordTimer] media is not mounted: /media/hdd/movie
[TIMER] failed to find mount to check for free space.
RemovePopup, id = DiskFullMessage
AddPopup, id = DiskFullMessage
[ImageManager] AutoStart Enabled
[ImageManager] Backup Schedule Disabled at (now=ke 12. joulukuuta 2012 15.46.21)
[BackupManager] AutoStart Enabled
[BackupManager] Backup Schedule Disabled at (now=ke 12. joulukuuta 2012 15.46.21)
[EPGImport] autostart (0) occured at 1355319981.16
[EPGImport] WakeUpTime now set to -1 (now=1355319981)
[ePNG] couldn't open /usr/share/enigma2/ico_dvb_s-fs8.png
[ePNG] couldn't open /usr/share/enigma2/ico_dvb_c-fs8.png
[ePNG] couldn't open /usr/share/enigma2/ico_dvb_t-fs8.png
[ePNG] couldn't open /usr/share/enigma2/ico_service_group-fs8.png
RemovePopup, id = ZapError
[Skin] Attribute not implemented: alphatest value: blend

I have raised nfsd count with config on server from 8 to 16
RPCNFSDCOUNT=16

[Rob van der Does]

Problem started again. Trying watch one SDTV recording and doing one recording.

Can you post the outcome of the telnet commands 'blkid', 'mount' and 'df -h'?

[andyblac]

what build are you running ?.

[rassi]

Can you post the outcome of the telnet commands 'blkid', 'mount' and 'df -h'?

root@vuduo:~# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             102.3M     63.2M     39.1M  62% /
devtmpfs                 67.5M      4.0K     67.4M   0% /dev
tmpfs                    64.0K         0     64.0K   0% /media
/dev/sda1               958.7M    589.6M    369.1M  62% /media/usb
tmpfs                    67.6M    140.0K     67.4M   0% /var/volatile
192.168.1.6:/mnt/video/dream/
                          6.8T      6.4T    404.4G  94% /media/hdd

root@vuduo:~# mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,sync,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=69072k,nr_inodes=17268,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/usb type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /var/volatile type tmpfs (rw,relatime)
usbfs on /proc/bus/usb type usbfs (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.6:/mnt/video/dream/ on /media/hdd type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,port=65535,timeo=70,retrans=3,sec=sys,local_lock=none,addr=192.168.1.6)

root@vuduo:~# blkid
/dev/ubi0_0: UUID="16cc3c12-b33e-402d-a640-00ca75662c19" TYPE="ubifs"
/dev/sda1: UUID="F886-6A81" TYPE="vfat"

what build are you running ?.

At the moment Build 502, issue has been at least since 262, but I think it has follow me all ways with OpenPli 3.0 based images.
Ever seen this issue with non-OpenPli images. Same Atom based Ubuntu NAS has been on use couple of years now. I have used DM800, DM7025 and Vu+ DUO with it.


If this tells something... i do not know

root@vuduo:~# nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
7795       0          7795

Client nfs v3:
null         getattr      setattr      lookup       access       readlink
0         0% 650       8% 2         0% 63        0% 643       8% 2         0%
read         write        create       mkdir        symlink      mknod
2392     30% 3280     42% 17        0% 0         0% 0         0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus
3         0% 0         0% 0         0% 0         0% 0         0% 207       2%
fsstat       fsinfo       pathconf     commit
10        0% 6         0% 0         0% 517       6%

[Rob van der Does]

Please update and try again: from build 508 a network tweak has been implemented.

[andyblac]

i made changes to the way mounts are detected for rec timers in build 508, could update to a build later than this and try again please.

[rassi]

Update will be done. I inform after next "Disk full -popup" (hope not!) or after some days has past.

[andyblac]

ok thanks.

[rassi]

ok thanks.

It didn´t help
One recording was on, started playback from old recording, about 30 secs after play, playback and timer recording stopped.
Disk Full popup didn´t show that was only thing which differ earlier.


Debug log
Enigma2-13-12-2012_16-03-40.log

There´s nothing about Disk full errors.

[rossi2000]

i had some similar issues when i first started using an NFS share to record/playback things

it was due to the way i had NFS setup on the server, it wasnt exporting the directories properly.

just looking at some of your fstabs and stuff it looks different to mine. when i get home i'll put up my settings.


this is my setup,

Ubuntu server with NFS which my 2TB drive is attached and mounted into /home/user. NFS exports this directory for sharing.
my quad conencts to this NFS share which is setup in mount manager in network settings. (also need to install NFS on the box and make sure "use as hdd replacement" is ticked)

[rassi]

My exports file on server is pretty basic

@NAS:/etc$ cat exports |grep dream
/mnt/video/dream 192.168.1.0/24(rw)

but still, this issue is only with OpenPli images.

and speed test to NFS server, also transfered 20GB from VU to NAS via NFS

Results for write throughput:
76.695 Mbit/s with udp,async,wsize=16384
76.695 Mbit/s with tcp,async,wsize=4096
67.108 Mbit/s with udp,async,wsize=8192
67.108 Mbit/s with udp,async,wsize=4096
67.108 Mbit/s with udp,async,wsize=32768
67.108 Mbit/s with tcp,async,wsize=8192
67.108 Mbit/s with tcp,async,wsize=32768
67.108 Mbit/s with tcp,async,wsize=16384

Results for read throughput:
89.478 Mbit/s with udp,async,rsize=8192
89.478 Mbit/s with udp,async,rsize=32768
89.478 Mbit/s with udp,async,rsize=16384
89.478 Mbit/s with tcp,async,rsize=8192
89.478 Mbit/s with tcp,async,rsize=4096
89.478 Mbit/s with tcp,async,rsize=32768
89.478 Mbit/s with tcp,async,rsize=16384
76.695 Mbit/s with udp,async,rsize=4096

root@vuduo:~# dd if=/dev/zero of=/media/hdd/testfile bs=188K
^C
root@vuduo:~# ls /media/hdd/testfile -l
-rw-r--r--    1 nobody   nogroup  20935041024 Nov 23 22:10 /media/hdd/testfile

[rassi]

Trying different mount options.

Was with TCP:

192.168.1.6:/mnt/video/dream/ on /media/hdd type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,port=65535,timeo=70,retrans=3,sec=sys,local_lock=none,addr=192.168.1.6)

Now with UDP:

192.168.1.6:/mnt/video/dream/ on /media/hdd type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,proto=udp,port=65535,timeo=100,retrans=10,sec=sys,local_lock=none,addr=192.168.1.6)

[andyblac]

My exports file on server is pretty basic

@NAS:/etc$ cat exports |grep dream
/mnt/video/dream 192.168.1.0/24(rw)

but still, this issue is only with OpenPli images.

and speed test to NFS server, also transfered 20GB from VU to NAS via NFS.......

when you say openpli images, are you talking open pli image or another (ViX), remember ViX is NOT OpenPLi, my network code is different from PLi's

and just fro reference here my ubuntu exports.

/root/Downloads 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_check)
/root/STB 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_check)

and why i use TCP not UDP.

5.4. NFS Over TCP


A new feature, available is NFS over TCP. Using TCP has a distinct advantage and a distinct disadvantage over UDP. The advantage is that it works far better than UDP on lossy networks. When using TCP, a single dropped packet can be retransmitted, without the retransmission of the entire RPC request, resulting in better performance on lossy networks. In addition, TCP will handle network speed differences better than UDP, due to the underlying flow control at the network level.
The disadvantage of using TCP is that it is not a stateless protocol like UDP. If your server crashes in the middle of a packet transmission, the client will hang and any shares will need to be unmounted and remounted.
The overhead incurred by the TCP protocol will result in somewhat slower performance than UDP under ideal network conditions, but the cost is not severe, and is often not noticable without careful measurement. If you are using gigabit ethernet from end to end, you might also investigate the usage of jumbo frames, since the high speed network may allow the larger frame sizes without encountering increased collision rates, particularly if you have set the network to full duplex.

[rassi]

when you say openpli images, are you talking open pli image or another (ViX), remember ViX is NOT OpenPLi, my network code is different from PLi's

At the moment i do mean ViX images only, i have thought that network code is the same on all OpenPli based images. If i do not remember totally wrong same issue has been also with real OpenPli images, it is so long time when i have
last time used real OpenPli, so i cannot be 100% sure about this.

and just fro reference here my ubuntu exports.

[CODE]/root/Downloads 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_chec k)
/root/STB 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_chec k)

Now I added no_root_squash and no_subtree_check to exports.
I have used only (rw) on exports for years.

and why i use TCP not UDP.

I have used TCP for years, but now give it a try to UDP. My NAS is solid and behind UPS, so i´ll give a try for it. Have to find something which can solve this issue

I really want use OpenViX! That´s why I haven´t gave up

Just cannot be sure which causes this, is it NAS or ViX or both as this case looks to be very rare. Maybe both as example NFS on BlackHole works like a charm with my setup.

[rassi]

Trying different mount options.


Now with UDP:

192.168.1.6:/mnt/video/dream/ on /media/hdd type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,proto=udp,port=65535,timeo=100,retrans=10,sec=sys,local_lock=none,addr=192.168.1.6)

Damn, no help
Again disk full arrived when playback an record when another recording is on. So this does not like playback & record sametime.

[TIMER] record time changed, start prepare is now: Sun Dec 16 08:59:40 2012
[Timer] Record RecordTimerEntry(name=Strike Back, begin=Sun Dec 16 09:00:00 2012, serviceref=1:0:19:584:E:46:E080000:0:0:0:, justplay=0)
[TIMER] activating state 1
[TIMER] Filename calculated as: '/media/hdd/movie/20121216 0900 - C More Series HD - Strike Back'
[TIMER] Not enough free space to record
[TIMER] Not enough free space to record
RemovePopup, id = DiskFullMessage
AddPopup, id = DiskFullMessage

root@vuduo:~# nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
1083977    18662      1083997

Now testing with hard mount

192.168.1.6:/mnt/video/dream /media/hdd nfs     rw,async,hard,tcp,intr  0 0

hard or soft — Specifies whether the program using a file via an NFS connection should stop and wait (hard) for the server to come back online, if the host serving the exported file system is unavailable, or if it should report an error (soft).

If hard is specified, the user cannot terminate the process waiting for the NFS communication to resume unless the intr option is also specified.

If soft is specified, the user can set an additional timeo=<value> option, where <value> specifies the number of seconds to pass before the error is reported.

Note: Using soft mounts is not recommended as they can generate I/O errors in very congested networks or when using a very busy server.

intr — Allows NFS requests to be interrupted if the server goes down or cannot be reached.