Pixelation When Recording HD

Ben said:
Aerial is firmly in place and there aren't may trees about. It does seem odd that there is never breakup when it's live TV, so I can't see why signal quality would be only affecting recorded programs.
Click to expand...

I'm also experiencing pixelation and signal drop only on recordings. For me it seems to happen roughly every 15 minutes and last for about 10 seconds. Anyone got any ideas why this could be happening?
 
I suggest telnetting into the box and running 'top' to see if anything is using the CPU when this occurs.

I have noticed that the sysmon package seems to use lots of CPU every now and again. The processes 'temp' and 'vmstat' seem to use lots of CPU when presumably all they are doing is reading some values and storing them in a database.

Code: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2133 root      20  -5  7808 7104 1168 R   92  5.7   0:28.36 vmstat
 
It is somewhat ironic that something being used to display CPU peaks could be causing them, may-be 'nice' could be used e.g. nice -n 19 vmstat
 
I had the same problem about a year ago (pixelation and skipping about 10 secs on recordings).
I contacted Humax and they said to reformat the disk. I was doubtful (thinking it was a standard answer) but eventually gave in and reformatted.
What do you know it solved the problem!!!
Been running fine since then, whereas before it hit every recording.

Lot of effort but worth a try
 
I have my suspicions about disk fragmentation. Formatting it (and reloading recordings) would regroup the free space into one area.
 
If you have suspicions about a particular file, the app. 'filefrag' can show the discontinuities.

Code: 
humax# /mod/sbin/filefrag /media/My\ Video/Never\ Mind\ the\ Buzzcocks/Never\ Mind\ the\ Buzzcocks_20121022_2201.ts
/media/My Video/Never Mind the Buzzcocks/Never Mind the Buzzcocks_20121022_2201.ts: 417 extents found, perfection would be 15 extents

If the '-v' option is added it will list out all the discontinuities.
 
Once thing I can pass on is that if you use an amp or anything else between the box and aerial to check the seating
of the UHF plug. Many of these (especialy the short cheap ones made for games consoles) have an internal pin
that is slightly too small to fit snugly. With vibration and over time they come loose and the first symptom is pixelation.

Now I think of it - we did have an amp that was in the habbit of overheating and causing pixelation too at one time.
(and when you end up telling historical stories that are years old about freeview you KNOW there is a serious problem somehwere!)
 
Jack616, if its the same as the problem I had then it can't be an aerial problem. If it were:
- it would affect live TV as well, not just recordings.
- it would not be possible to make live TV jump forward 10 seconds or so, else progs would finish early and then only on affected machine - that could be a useful feature, when is next lottery draw!!
 
Black Hole said:
I have my suspicions about disk fragmentation. Formatting it (and reloading recordings) would regroup the free space into one area.
Click to expand...

Thanks! This seems to have fixed it for me, although I only formatted the drive a couple of months ago so not sure how it managed to get so fragmented in that time.
 
Black Hole said:
I've had a play, useful data for general consumption.

Simultaneous recording of two HiDef programmes, playback of a HiDef recording, and DLNA streaming of another HiDef recording - no problem. Ditto while performing a couple of gigabytes copy to USB - no problem. I then deleted a couple of gigabytes, and got stutters in the recordings. (I can't imagine what's so hard about deleting - all it needs to do is mark the disk sectors as free in the allocation tables.)

Then I ran simultaneous recording of two HiDefs, one streamed playback of HiDef, live timeshifted play of a third HiDef channel, and 5GB copy from USB to internal disk. Again, no problem until I queued up a delete.

So that's 3 write and 2 read operations at HiDef data rate, plus a copy write from USB at (what I guess was) about 4 or 5 times HiDef data rate.

In summary, there seems to be plenty of bandwidth for normal operations, just avoid deleting while recording (and possibly copies to virtual drive).
Click to expand...
I think you have hit on the problem. I was recording and playing back at the same time. When I finished the playback I deleted the file - hence pixelation.

I will now avoid deleting any file while either watching or recording. Is there a process to mark for deletion and create an event for the Humax to wake up at say 0600 and delete all files marked, then go back to sleep?
Windows chews up all available RAM when copying. I wonder if this is a similar issue?
 
I think in this case undelete will come to your rescue. Files deleted by the WebIF or the SUI won't actually delete at the time, they will be moved to a recycle bin (a very easy operation) and then cleared out after a selectable number of days.

I'm not sure whether the eventual deletion from the recycle bin imposes the same kind of load, but certainly a modification could be made to ensure it is done in a quiet period.
 
How are you deleting the files? Removing a large file over Samba/NFS or via telnet will generally cause pixelation of recordings and playback in progress, particularly if they're HD. Removing the file via the on-screen menus, webif or trm command shouldn't cause this because they truncate the file in stages, spreading the filesystem extent deallocations over multiple journal entries.

Black Hole said:
I'm not sure whether the eventual deletion from the recycle bin imposes the same kind of load, but certainly a modification could be made to ensure it is done in a quiet period.
Click to expand...

Automatic removal from the bin uses trm so is gentle on the filesystem and disk bandwidth.
 
af123 said:
How are you deleting the files? Removing a large file over Samba/NFS or via telnet will generally cause pixelation of recordings and playback in progress, particularly if they're HD. Removing the file via the on-screen menus, webif or trm command shouldn't cause this because they truncate the file in stages, spreading the filesystem extent deallocations over multiple journal entries.



Automatic removal from the bin uses trm so is gentle on the filesystem and disk bandwidth.
Click to expand...
I am removing the files via the Humax Menus only. I have done the deletion through SAMBA only once and that was definitely not the case when I had the extreme pixelation and loss of signal message.
 
Here's my 'top' which seems to show a fairly high load average when recording. Anything look out of the ordinary here?

Code: 
Mem: 122036K used, 2948K free, 0K shrd, 4272K buff, 48960K cached
CPU:  40% usr  15% sys  0% nic  35% idle  5% io  0% irq  1% sirq
Load average: 2.09 2.23 1.37 6/161 1905
  PID  PPID USER    STAT  VSZ %VSZ %CPU COMMAND
  173  155 root    S    365m 299%  55% /usr/bin/humaxtv
  341    9 root    SW<      0  0%  2% [kjournald]
 
I'm only getting 25-30% when recording 2 Hi-Defs and watching a third so if the 55% is constant, it does appear to be high
 
It's died down now and is sat at 10% with a load average of 0.5 - all very odd. Think I'm just going to ftp all my recordings off, format the drive and put everything back.
 
xyz321 said:
I have noticed that the sysmon package seems to use lots of CPU every now and again. The processes 'temp' and 'vmstat' seem to use lots of CPU when presumably all they are doing is reading some values and storing them in a database.

Code: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2133 root      20  -5  7808 7104 1168 R  92  5.7  0:28.36 vmstat
Click to expand...
Just a reminder since some people still seem to think it is broken. The problem of the processes 'temp' and 'vmstat' using excessive CPU has been fixed in the latest version of sysmon (1.1.0). See here for details. I have been running it for nearly two months with no problems whereas previously I would see picture break up.

The relatively high priority nice setting will be fixed in the next version of custom firmware (2.17).
 
You must log in or register to reply here.
Back
Top