[VU+ Duo] "WRITE ERROR on recording, disk full?" messages now and then

[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
View attachment 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.

/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)
[/QUOTE]

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

[QUOTE]
and why i use TCP not UDP.[/QUOTE]

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.

 

[andyblac]

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.

might be bandwidth issues then remember 4-6mb sec max is what you will get so recording and playing at same IMO i pushing bandwidth as would 2 HD recordings at same.

can you do some more tests.


BTW, when using HARD if your server drops it share your client box will just sit there waiting with spinners, this is why openvix does not use 'HARD'.

 

[rassi]

might be bandwidth issues then remember 4-6mb sec max is what you will get so recording and playing at same IMO i pushing bandwidth as would 2 HD recordings at same.

can you do some more tests.

Just tested only recording there was 2x SD + 1 HD = Disk full message. I will test this same thing with BH, maybe OpenPLi also, to be sure is this issue only with Vix or Openpli.

BTW, when using HARD if your server drops it share your client box will just sit there waiting with spinners, this is why openvix does not use 'HARD'.

Ok. Didn´t tested it yet. but using initr should avoid this?
intr — Allows NFS requests to be interrupted if the server goes down or cannot be reached.

 

[rassi]

hard option wasn´t the key
2x SD + HD = Disk Full

I think i can be now sure that changing NFS options do not give me any help with this.

 

[andyblac]

hard option wasn´t the key
2x SD + HD = Disk Full

I think i can be now sure that changing NFS options do not give me any help with this.

try with just one recording, see what it does, if no DISK FULL it is bandwidth.

 

[rassi]

try with just one recording, see what it does, if no DISK FULL it is bandwidth.

No problems with one recording all of them are fine, i think all DISK FULL messages has arrived when doing more than one recording.

Swapped now back to BlackHole and yes all recording do work fine with out an any issues.
Tested 2xSD + HD = OK about one hour recording.
Now recording 2xHD + SD + SD playback = after 15 minutes everything Ok.
Will check little bit later how my recording do work are they fine
or do i see some glitches. At least playback is flawless

 

[rassi]

2xHD+SD recordings are glitch free, so there´s no problem with network. It´s something very odd and rare

 

[Del Boy]

I've just had a similar thing. Got a new Solo2 box on latest version as of today, mounted my NFS Share but then when it recored I got disk full and worse than that because it was in autotimer it just kept looping round. It all started when I hit the pause button. Cant send log because the box is in accessible. Going to have to re-install - any ideas.

Incidentally, tried a re-install of my image I made today. Comes up press power to update, then UBIFS but it doesnt completely replace the previous image and the problem with looping through this record issue is still here? Have I got to run a standard image then mine over the top or something? Not really any different to a standard backup!

All help gratefully received

thanks

 

[Del Boy]

Also noticed that my old DUO used to ask for a username and password on shares but the solo2 doesn't. Was sure on the DUO I could select a NAS drive and select it under mounts like a local HDD whereas with the solo2 I'm having to use bookmarks which aren't my preferred choice

 

[warajoker]

Im getting "write error" on the solo2 and its brand new only opened yesterday and so is the 1tb hardrive?

 

[Sicilian]

Im getting "write error" on the solo2 and its brand new only opened yesterday and o is the 1tb hardrive?

Your starting to live up to your name aren't you!

Create your own thread with Solo2 tag and you may get a better response.