• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

HD recordings picture break-up

J

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?
 
What version of CF are you on? There was a problem with process priorities on previous versions.
 
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.
 
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
 
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.
 
Mike0001 said:
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.
Click to expand...
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.
 
prpr said:
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.
Click to expand...


Sorry. Brain misfunction!:(
 
af123 said:
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.
Click to expand...

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?)
 
jxp said:
I will also try running a disk check when I have the time (it can take about an hour right?)
Click to expand...
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.
 
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?
 
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).
 
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?
 
The output from 4kalign said

Code: 
Standard format drive - partitions are always aligned.

So it doesn't seem like that is the problem
 
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.
 
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.
 
You must log in or register to reply here.
Back
Top