HD recordings picture break-up

jxp

Member
My picture break up on HD recordings seems to be coming back.
It hasn't been too bad for the past few months.
I realize it is probably reception/weather related but it seems suspicious that it is always within the first 5-10 minutes of a recording starting.

Looking at the last occurrence it was about 4 minutes in to a (padded) recording of Bake Off.
Checking the logs on the diagnostic page, they only thing dated at this time is the Dustbin clean up.

Is there any chance that could be affecting the picture quality? Is there any way to only run this at a certain time of day, so I can check?
 

prpr

Well-Known Member
What version of CF are you on? There was a problem with process priorities on previous versions.
 
OP
J

jxp

Member
I'm on the latest version of CF: 2.19.
I had thought the previous changes to process priorities had fixed the issue.
My HD mux shows 50% strength 100% quality which I thought should be plenty.
 
OP
J

jxp

Member
After a bit of digging I've made the following changes;
  • Commented out the empty_dustbin task from /mod/etc/anacrontab
  • Scheduled empty dustbin to run at 6:00am each day instead
I will see how it goes for a week and report back
 

af123

Administrator
Staff member
The dustbin cleanup only runs once a day; on the first boot of the day (usually the 04:30 housekeeping boot) or at 2am if the box is left on.

Which diagnostic logs gave you the impression that the task had run?

Have you run a full disk check? Your symptoms could indicate a disk problem.


Posted on the move; please excuse any brevity.
 

prpr

Well-Known Member
50% strength seems very low. Has your dish gone out of alignment? I can't think why anyone in the UK should have such a low signal strength.
Dish? On a T2?
FWIW, my signal strength is about 40% mainly because I have a sodding great attenuator in the feed trying to keep out Wenvoe (only partially successfully) from mucking up my Mendip feed. This level causes no problems whatsoever.
 

Mike2

Scrat
Dish? On a T2?
FWIW, my signal strength is about 40% mainly because I have a sodding great attenuator in the feed trying to keep out Wenvoe (only partially successfully) from mucking up my Mendip feed. This level causes no problems whatsoever.


Sorry. Brain misfunction!:(
 
OP
J

jxp

Member
The dustbin cleanup only runs once a day; on the first boot of the day (usually the 04:30 housekeeping boot) or at 2am if the box is left on.

Which diagnostic logs gave you the impression that the task had run?

Have you run a full disk check? Your symptoms could indicate a disk problem.


Posted on the move; please excuse any brevity.

My box has the 4:30 boot disabled and comes on at 6:00am (to generate thumbnails). It turns itself off when finished.
I think on Tuesday it wasn't on long enough for empty_dustbin to run at 6:00am.
The next time the box came on was when it started a scheduled recording at 8:00pm.

The dustbin log showed that it started shortly after 8:00pm which roughly coincided with the picture breakup in the recording.

I will try with empty_dustbin forced to 6:00am for a while and see what happens.
I will also try running a disk check when I have the time (it can take about an hour right?)
 

af123

Administrator
Staff member
I will also try running a disk check when I have the time (it can take about an hour right?)
The fix-disk process from maintenance mode takes an hour or so depending on the size of your disk. I run it every few months routinely to check for problems.
 
OP
J

jxp

Member
I ran fix-disk and didn't see any messages that shouted "OMG! Your disk is knackered"

The only actions I could see in the log were

Code:
...
/lost+found not found.  Create? yes
...
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
...

I have also been running on a modified schedule for empty_dustbin and auto-decrypt.

There is definitely a correlation between auto-decrypt ending and picture breakup.
It only seems to occur when recording HD and auto-decrypting a big file (usually HD)

Could either of the below items (binning, bookmarking) be running at too high a priority?

Code:
29/11/2013 21:17 -  Removing/binning old copy.
29/11/2013 21:17 - Done... 2.95 GiB in 466.27 seconds - 6.47 MiB/s
29/11/2013 21:17 -  ARBOOKMARK: /media/My Video/Marvel's Agents of S_H_I_E_L_D_/Marvel's Agents of S_H_I_E_L_D__20131129_1958
29/11/2013 21:18 - Found start of programme at packet 1341518 (pos 257571456/f5a3a80)
29/11/2013 21:18 - Found end of programme at packet 14952485 (pos 2870877120/ab1e1bc0)

Otherwise any chance of adding a "Don't auto-decrypt when recording HD" option?
 
OP
J

jxp

Member
I've been running without ARBookmarks for a week and haven't had any picture break ups. Could part of this package be running at too high a priority? Or could it be reading the HD files too quickly? The break ups tended to last about 5 seconds only, so I don't know how that relates to the ARBookmarks file reading (or writing).
 

af123

Administrator
Staff member
It sounds like it could be related. It will be running at the same priority as the rest of the automatic jobs which is as low a priority as possible. ARBookmarks does its work very quickly (one second according to the log you've posted) and shouldn't be overloading the disk or processor. Is your hard disk aligned? (run the 4kalign diagnostic to check). Is anyone else seeing this problem with ARBookmarks?
 
OP
J

jxp

Member
The output from 4kalign said

Code:
Standard format drive - partitions are always aligned.

So it doesn't seem like that is the problem
 

andyk

Member
For me, whenever auto kicks in to make its passes over the file system, it always causes a problem. What seems to happen is that the code to detect if it's ok to decrypt a file messes the file up. The recordings affected are HD recordings that are simultaneously being chase played. For me this is most MOTD shows (and seems to be always when a goal is being scored too - I did wonder at first if it was for places with loud audio). I deduced this was the problem initially by changing the timing of the auto runs - the problem reduced to exactly the time of the auto run. I then switched off auto decrypt altogether and all is well. The code's attempt to check for a busy file for shrinking doesn't exhibit this problem. I've switched off these recursive facilities and no more problems.
 

Wallace

Traveler 34122
That's strange because on one of my HDR's, I have both recursive auto-shrink and auto-decrypt enabled and have done for as long as they were available. I haven't noticed any issues at all.
 
Top