[DetectAds] Announcing DetectAds version 2

I need to double check the installation logic that should have added the retry column to the database.

To cure the problem you will need to delete the queue data base

Enter the following in a command line (Telnet or from Diagnostics menu)
Code: 
rm /mod/etc/detectads_queue.db
 
MymsMan said:
I need to double check the installation logic that should have added the retry column to the database.

To cure the problem you will need to delete the queue data base

Enter the following in a command line (Telnet or from Diagnostics menu)
Code: 
rm /mod/etc/detectads_queue.db
Click to expand...
Thanks, that seems to be working now.
 
Last edited:
I would like the ability to (as a one-off) scan the library for candidates and queue them for processing. I realise I can simulate that using sweeper rules, but a one-click "catch-up" button would be convenient.
 
The two approaches that I can think of (at the moment) are to:
  1. Add a an extra action to the Folder actions pull down menu on Browse/FlexView - 'Queue folder for DetectAds'
  2. Add a 'DetactAds' button to the bottom of Browse/FlexView to process selected like the Delete/Cut/Copy buttons.
My slight concern is it would is that we could have button clutter if there is then a call for an MP3 extract button and Decrypt selected button,
It might be better to have a single 'Process Selected' which asks you what action to perform on the selected entries.

I will add the idea to the to-do list which grows longer as SWMBO has other ideas for my time! :rolleyes:
 
What about a button in the detectads settings page that simply says "scan for unprocessed candidates and queue them"?
 
I have updated DetectAds and ChaseGet on the package repository.

The most significant change is to allow the specification of a target start time for recordings queued for processing.

This is for those who find that they sometimes experience recording problems on busy systems with multiple recordings and playback at the same time as DetectAds processing.

If you wish wish to defer DetectAds processing to a time when the system is less busy you can specify a target start time.
The target time is the earliest start time but processing may start later depending on when the regular DetectAds task starts and how many other items need to be processed on the queue. You must of course ensure the the system is switched on at the target processing time and remains on long enough to process all of the queued items (possibly set up a scheduled repeating reminder event)

The target time can be specified on the settings page, DetectAds processing panel or as -t hh:mm on the Sweeper action parameter or on command line invocation
 
I have noticed that on the webif, a programme (not BBC) is showing as playing when it is actually recording. Should it be doing this, and if it's DetectAds in ChaseGet mode (which I have set and I suspect) surely it should be showing as both recording and playing, or just recording.
 
The way the current status is derived for display on the status display is somewhat close to guesswork - it doesn't know about Detactads and other packages so assumes playing if a file is in use.

I have suggested that the webif includes an interface so that packages can declare when they are processing files to give a better status display but AF123 hasn't taken up the idea.
 
I sort of guessed that was the reason, but thanks for the confirmation Myms.
It could replace the less than useful 'Idle:' time;)
 
In what way do you find it useful prpr? What exactly does it indicate? I can't make head nor tail of it.
 
The DetectAds status, should it ever be implemented, would appear in the activity list display and not a replacement for any other information
 
MymsMan said:
I have suggested that the webif includes an interface so that packages can declare when they are processing files to give a better status display but AF123 hasn't taken up the idea.
Click to expand...
That one slipped through the cracks. There are hooks that the auto processing use so I'll look at generalising them a bit so detectads can use them too.
 
MymsMan said:
The DetectAds status, should it ever be implemented, would appear in the activity list display and not a replacement for any other information
Click to expand...
I realise that. I was just having a pop at the Idle Time thingy, whatever it indicates and why?
 
Trev said:
I realise that. I was just having a pop at the Idle Time thingy, whatever it indicates and why?
Click to expand...
It indicates how long the box has been idle - how long since somebody last pressed a button on the remote control. It can show you how long you have before the box turns itself off if you have auto power down enabled or you can infer that your other half has fallen asleep in front of the TV again when logging in from work.

If you don't want it, put this in EXTRA.css

Code: 
#idletime { display: none; }
 
When I map a drive letter to "\\foxT2\root" in W10 explorer, should it show up as 25.1 MB and full? Mine does.
 
You must log in or register to reply here.
Back
Top