Picture breaks up on recordings while Auto Decrypt is running

N

Nobby Sheep

Member
Hi,

I have been getting picture break ups on recordings made with my HDR FOX T2.

Initially I thought it may be signal problems etc, then I thought it may be because I inadvertently deleted a file while the box was recording, or maybe even accessing webif while the box was recording, but it seems to only be a problem when Auto Decrypt is set.

As a test I ran my Humax without recursive Auto Decrypt (for a week) and did not noticed any picture break up on recordings.

On Saturday evening I enabled recursive Auto Decrypt and while watching a recording of the Quo documentary (I know), the picture broke up around five or six times. Picture break up was on the recording as I replayed each one to check.

I gather from the Wiki that Decrypt copies the files from one directory to another while decrypting, but should this affect recordings happening at the same time, or does Decrypt actually happen when the box is busy?

I notice that an earlier package Unencrypt ran/runs overnight because of CPU activity.

I was wondering if anyone else has noticed this or whether I'm barking up the wrong tree?
 
That's good. Suggest you look at the SMART stats. of your disk next (and possibly run fix-disk from maintenance mode).
 
Thanks for the reply.

I had run fix-disk a couple of months ago as I was getting 0MB recordings (hard drive had gone "read only") and it fixed a few things - realigned sectors (I think).

SMART status says "passed".

The only highlighted section is number 5

Reallocated_Sector_Ct PO--CK 8 100 100 036 Pre-fail Always -

Would fix-disk help with this?


The other option is to install Unencrypt, but from reading the Wiki the better choice should be Auto Decrypt.


The HDR FOX T2 is only five months old.
 
Line (Number ) 5 has 8 reallocated sectors, this is quite a low figure and not usually a problem unless it is in the 1000s. As default Unencrypt works between 1am and 6am when the Humax is out out standby and was written before Auto Decrypt, the later versions of Custom Firmware give high priority to the 'Humax' features and a lower priority to things like Auto Decrypt, so there is usually no problems with the CF stuff causing recording errors. Problems with disk access can add to the likelyhood of recording errors which is why it is always a good idea to run fix disk repeatedly until no corrections are made
 
Just an update on my problem.

I ran fix-disk a couple of times and no problems were found.
Retuned the HDRFOXT2 manually to avoid duplicate transmitters.
Re-enabled autodecrypt.

While watching Graham Norton (BBC1HD) on Friday in delay (by about 10 minutes) from the created file (not timeshifted), the picture broke up (between 5 and 10 minutes in), the sound disappeared and the picture jumped a second or two.

A BBC2HD (Doctor Who Culture Special) had just finished recording.

I notice from the auto.log the picture break up occurred as the Doctor Who programme was being decrypted.
Code: 
22/11/2013 22:40 - DECRYPT: /media/My Video/Me, You and Doctor Who_ A Culture____20131122_2131
22/11/2013 22:40 -  DLNA: http://127.0.0.1:9000/web/media/743.TS
22/11/2013 22:46 - Removing/binning old copy.
22/11/2013 22:46 - Done... 2.66 GiB in 412.936 seconds - 6.59 MiB/s

My guess is the break up occurred at the end of the decrypt when the original file was being deleted.


I have installed unencrypt and all decryption is now being done overnight, but as this appears to no longer be supported is there a way that autodecrypt can sense that something is about to record and delay any action until the coast is clear?
 
If you are using unencrypt, it may be useful to know that you can change the period over which it runs (default = 1am to 6am) Notes HERE, the Humax must be out of standby to run unencrypt. As far as autodecrypt detecting pending recording events, if could run the 'status' command line that will return 'recording' or 'will record' (in the next 15 Mins.), but the 'will record' only works if padding is off I think
 
Thanks for the quick reply.

I've got the default (1am - 6am) set on unencrypt which is fine and does the job.
My wake up period is set from 1am-6am as well.

I was wondering though, if the problem (of picture breaks) is caused by deleting files then maybe installing "undelete" might allow autodecrypt to run but without the deletion of the original file.

If, of course, undelete works for autodecrypt deletions as well as regular deletions.

Running status command lines is a bit beyond me, so I'll leave that to others :), but am happy using AR so maybe someone may look at it in the future.
 
Undelete may help by shifting the time that a deletion happens, when installed, anything to be deleted is actually moved to the [Deleted] folder so no deletion action is carried out at that time, the deletion is then carried out after a number of days. The Undelete package also uses the linux trm command rather than rm, which does a Truncate ReMove, as it is less 'violent'
 
Excellent.

I assume that moving a recording to the [deleted] folder doesn't actually move any "ones and noughts" so should be easier on the system.

I'll take out unecrypt and install undelete for a few days and see if that helps.

I'll report back in a week or two.

Thanks once again.
 
Yes, as you say the move doesn't actually move the file, it just changes the Table Of Contents to point to the new location within the partition
 
Just an update on the situation.

Since installing undelete everything has played nicely over the Christmas period. All the programmes I've (finally) got around to watching have not suffered any picture break ups.

So I guess the "delicate" way that undelete deals with deletions has helped.
 
There is some confusion here. The topic title says "Auto Decrypt", yet you keep referring to unencrypt. There is a difference: unencrypt is an old package lacking many of the refinements and safeguards that have developed in the WebIF way of doing things, and is now not recommended (although, if you want to restrict decryption operations to specific hours of the day, it is the way to go for that).

Auto-decrypt is the modern alternative, is set on specific folders using the WebIF media browser OPT+ button, and can be set as recursive to encompass sub-folders - or the whole Media folder can be set to recursive auto-decrypt to decrypt everything automatically. The WebIF co-ordinates the action of the various auto-processes to ensure they operate in a logical order and avoids overloading the processor. It also detects failures in the processes and attempts to recover, whereas unencrypt doesn't. The auto-processes use the undelete bin, I am pretty sure unencrypt doesn't.

Details regarding decryption available via the link in Things Every... (click) section 5.
 
Black Hole said:
There is some confusion here.
Click to expand...

I thought I had a problem with auto decrypt. The problem was the deletion of the original file (after auto decryption) would affect a recording happening at the time of the deletion. (See the auto.log in post #8.)

I got round the problem initially by using unecrypt, but because that's not supported (and as you say is not recommended) I wanted to find a better solution to my problem.

That solution appears to be installing undelete with it's "lighter" way of deleting things.

The confusion you see is just me trying to sort things out myself and switching between the unsupported unencrypt and the supported auto decrypt + undelete to try and remedy the problem.

As I state in post #14, I've not encountered any recording stutters with the autodecrypt/undelete combination. So this may be a suitable solution if anyone else encounters the same problem.

Hope that explains it!
 
I also had a similar problem with deleting files (and with generating bookmarks using arbookmarks).
I also discovered that emptying the deleted items folder could cause break up as well.

In the end I manually forced the emptying to occur at 6am each day.
 
Ezra Pound said:
The Undelete package also uses the linux trm command rather than rm, which does a Truncate ReMove, as it is less 'violent'
Click to expand...

Interesting ... is undelete the only process that uses 'trm'?
Does deletion via Web-if OPT+ menu use 'rm' or 'trm'?

I have often wondered if there is any difference between deleting via Web-if compared to deleting via TV screen using the remote control ... i.e. is OPT+ deletion more 'gentle' than SUI or better in some other way?
 
I don't have a definite answer on this, but I think it's fair to assume that code written by af123 (as the Web-If is) will use trm rather than rm, so a Web-If OPT+ >> Delete will be more gentle
 
You must log in or register to reply here.
Back
Top