Recursive Auto-Shrink, Auto-Decrypt no longer working

R

Rob Singlehurst

Member
I copied some .ts files off of my Hummy onto my pc and couldn't play them back. I then realised that they hadn't been decrypted. After a bit more research I can see that only files that have been processed with detectads have been shrunk and decrypted - the Recursive options on "My Video" folder are no longer working.
I looked on here and deleted /mod/etc/queue.db which unfortunately made no difference. Anything recorded off of a channel that is in the detectads excluded list is not being added to the auto-processing queue.
I ran fixdisk last night, it found a few errors which have been fixed but still nothing added to the queue.
Here's a screen grab of the queue. The rather odd thing is the date of the media scan!!
QueuedTasks.JPG


Anyone any ideas please? My daughter is at Uni and I would like to copy off a load of stuff to a USB stick so she can watch it.

Cheers,

--Rob
 
If you only require the recordings to be decrypted you don't need to run detectads or shrink, you can simply select decrypt from the Browse menus, of either a single file or a complete folder
 
What are your Auto processing settings on the Settings page?
What is the scan frequency and do you have any times excluded?
Does auto.log show scans taking place?
If you queue recordings for processing using the Queue for button on the browse page are they processed?
It could be due to a corrupt queue.db and you can try renaming it to force recreation.
 
Ezra Pound said:
If you only require the recordings to be decrypted you don't need to run detectads or shrink, you can simply select decrypt from the Browse menus, of either a single file or a complete folder
Click to expand...

I tried selecting a folder and that doesn't appear to work either - I can manually decrypt / shrink each file using the Opt+ menu next to each file.
 
MymsMan said:
What are your Auto processing settings on the Settings page?
What is the scan frequency and do you have any times excluded?
Does auto.log show scans taking place?
If you queue recordings for processing using the Queue for button on the browse page are they processed?
It could be due to a corrupt queue.db and you can try renaming it to force recreation.
Click to expand...

Here are my processing settings. I haven't altered anything on here for probably a year or two.
AutoProcessingSettings.JPG

Auto.log just shows entries created by detectads - I'm not sure what normal recursive decrypt / shrink entries would look like? I deleted the queue.db but that made no difference i.e. nothing has been added to it. I'm guessing that the future dated "Last media scan" is causing the problem perhaps?
If I use the "Queue For" button they get added to the Queue correctly and are processed (I have done it just now - wasn't aware of that facility!!).
 
That all looks up to date. Is the "last media scan" timestamp still wrong since you deleted the queue database?
 
Actually, the timestamp is stored in the webif.db file, not the queue.db file, so deleting the latter isn't going to help.
I don't know if this actually matters, but in case it does, you can try resetting it using this at a command prompt:
Code: 
humax# sqlite3 /mod/etc/webif.db "update settings set nval=(select strftime('%s','now')) where name='autolast';"
I would copy'n'paste that to make sure you get it right!
 
prpr said:
Actually, the timestamp is stored in the webif.db file, not the queue.db file, so deleting the latter isn't going to help.
I don't know if this actually matters, but in case it does, you can try resetting it using this at a command prompt:
Code: 
humax# sqlite3 /mod/etc/webif.db "update settings set nval=(select strftime('%s','now')) where name='autolast';"
I would copy'n'paste that to make sure you get it right!
Click to expand...

Thanks,
Yes you're right - the timestamp hasn't changed since deleting the queue.db file. I'll try that tonight when I'm back home - didn't setup port forwarding for telnet when I swapped my router a few weeks back so can't connect in at the moment. :( I'll let you know how I get on.

Cheers,
 
prpr said:
Actually, the timestamp is stored in the webif.db file, not the queue.db file, so deleting the latter isn't going to help.
I don't know if this actually matters, but in case it does, you can try resetting it using this at a command prompt:
Code: 
humax# sqlite3 /mod/etc/webif.db "update settings set nval=(select strftime('%s','now')) where name='autolast';"
I would copy'n'paste that to make sure you get it right!
Click to expand...

Success!!! I got someone at home to switch on my pc, remoted into that and then telneted into my Hummy, pasted the command and rebooted the Hummy :) Excellent - thank-you so much. Another one for the knowledge base! ;)

Capture.JPG
 
prpr said:
That all looks up to date. Is the "last media scan" timestamp still wrong since you deleted the queue database?
Click to expand...
Well spotted - I hadn't noticed that since I was using my phone earlier
The Humax would have been skipping autorun scans until 2021!

Had Dr Who taken the Humax time travelling in the TARDIS?
 
Last edited:
MymsMan said:
Well spotted - I hadn't noticed that since I was using my phone earlier
The Humax would have been skipping autorun scans until 2021!

Had Dr Who taken the Humax time travelling in the TARDIS?
Click to expand...

Yeah, I only noticed the year last night myself! All good now - I've increased the time between scans for now until it catches up.
 
Hi guys
just reading through messages guess what my media scan shows 2021 too.

so how do i enter the code
humax# sqlite3 /mod/etc/webif.db "update settings set nval=(select strftime('%s','now')) where name='autolast';"

which program on my pc do i need to use?

David
 
Black Hole said:
...or install webshell and access a command terminal from WebIF >> Diagnostics
Click to expand...
i installed the webshell, went into webig > > diagnostics and got "sorry this page is not available"

went via the putty route, telnet in cli run code

back into diag
media scan now shows NOW, yippppeee

thanks
 
Rob Singlehurst said:
I've increased the time between scans for now until it catches up.
Click to expand...
It will already have added all of the backlog to the queue so the scan interval is now irrelevant
You should probably turn off Create backup files in dustbin for decrypt and shrink? while processing the backlog so that the disk doesn't fill up.
You may want to leave the box turned on overnight for a while to allow it to catchup, or hold the queue and release them in batches
 
You must log in or register to reply here.
Back
Top