• 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.

[DetectAds] Announcing DetectAds version 2

My apologies; I meant bookmark. I was getting inconstant results from cropping so turned it off. Currently with these settings it's not performing any actions on the files:

upload_2015-12-22_13-20-59.png
 
My apologies; I meant bookmark. I was getting inconstant results from cropping so turned it off. Currently with these settings it's not performing any actions on the files:
You currently have traditional ( after auto decryption) selected rather than chaserun but it appears you don't have auto decryption turned on for the Fargo folder since the recording don't have the Dec flag
 
I think that's probably the reason.

How does Traditional deal with one off recordings?

If the only difference between the Chaserun & Traditional is when it performs the processing, could Traditional use the same code to decrypt individual files, as with Chaserun, & then post process the fie?
 
I think that's probably the reason.

How does Traditional deal with one off recordings?

If the only difference between the Chaserun & Traditional is when it performs the processing, could Traditional use the same code to decrypt individual files, as with Chaserun, & then post process the fie?
In Traditional processing it is the completion of auto-decryption that triggers the start of DetectAds,

For one-off recordings you can set the Auto Decrypt or Recursive Auto Decrypt flags on the My Video folder so it works just the same.

If you run DetectAds from the Opt+ menu or via Sweeper it will use traditional/chaserun processing depending on whether or not the recording has already been decrypted.
 
I had a detectads error message I'd not seen before. Log below:
Code:
23/03/2016 18:58:01 RM(4556)-   DETECTADS: Checking /media/My Video/Stargate SG-1/Stargate SG-1_20160323_1858.ts (Pick) for channel exclusion
23/03/2016 18:58:02 RM(4556)-   DETECTADS: Started /media/My Video/Stargate SG-1/Stargate SG-1_20160323_1858.ts for chaserun advert detection
23/03/2016 18:58:02 DA(4564)- ==DETECTADS Chase Run: /media/My Video/Stargate SG-1/Stargate SG-1_20160323_1858.ts
23/03/2016 19:00:02 - CG(6050)- System power on attempted
23/03/2016 19:11:07 DA(4564)- Final bookmarks:
23/03/2016 19:11:07 DA(4564)- Incomplete data retrieval -1266806784 bytes missing (06:11:48)
23/03/2016 19:11:07 DA(4564)- Queing /media/My Video/Stargate SG-1/Stargate SG-1_20160323_1858.ts for retry of detectads due to significant file length error
23/03/2016 19:11:11 DA(4564)- /mod/tmp/Stargate SG-1_20160323_1858-dec.ts deleted
23/03/2016 19:11:11 DA(4564)- done...processed /media/My Video/Stargate SG-1/Stargate SG-1_20160323_1858.ts in 669.826s 00:11:10 - 0 ad breaks detected
Removed /mod/tmp/Stargate SG-1_20160323_1858-inp.ts<br>
Removed /mod/tmp/Stargate SG-1_20160323_1858-inp.nts<br>
Removed /mod/tmp/Stargate SG-1_20160323_1858-inp.hmt<br>
Removed /mod/tmp/Stargate SG-1_20160323_1858-dec.ts<br>
Removed /mod/tmp/Stargate SG-1_20160323_1858-dec.nts<br>
Removed /mod/tmp/Stargate SG-1_20160323_1858-dec.hmt<br>
The package has behaved correctly in that it deleted the process files and queued it up for later processing but I wonder why it reported '-1266806784 bytes' as missing?
 
The package has behaved correctly in that it deleted the process files and queued it up for later processing but I wonder why it reported '-1266806784 bytes' as missing?
This is probably one of the unexplained situations where decryption fails. normally the decrypted file length should be identical to the encrypted file length.

Did it eventually process correctly?
 
This is probably one of the unexplained situations where decryption fails. normally the decrypted file length should be identical to the encrypted file length.

Did it eventually process correctly?
Yes, but webif auto-decrypt kicked in before detectads and I ended up clearing the detectads queue manually and set the analysis to run in the background as I did not want to wait for the next scheduled autoprocess run.
 
I've noticed if you use Detectads in chaserun mode with a padded recording, that most of the time the synopsis, genre and any guidance information saved in the hmt file is from the previous programme. If you compare this to the original recording (moved to '[Deleted Items]/Detectads' after completion of the run) you will find that the data in the the original hmt file is almost always correct, and does not match that in the hmt file with the bookmark information. If you inspect the information in the ts file (using Sidecar> TS info) the information in the ts file is also correct.
 
I don't use padding so have never seen that.

How much padding do you use?
Do you know how soon after the recording starts that the hmt is updated with the correct synopsis and other information?
Is the scheduled start time (not actual start) in the detectads output hmt correct?

DetectAds copies the hmt information at 2 minutes after the recording start time ([$ts get start])
I could change that to be 2 min after the scheduled start ([$ts get schedstart]) provided the start time is for the program to be recorded and not residual from the previous program.
 
For padded recordings there can actually be several EPG data blocks in the .hmt file. I don't know if the main EPG information is updated after a while.
 
I don't use padding so have never seen that.

How much padding do you use?
Do you know how soon after the recording starts that the hmt is updated with the correct synopsis and other information?
Is the scheduled start time (not actual start) in the detectads output hmt correct?

DetectAds copies the hmt information at 2 minutes after the recording start time ([$ts get start])
I could change that to be 2 min after the scheduled start ([$ts get schedstart]) provided the start time is for the program to be recorded and not residual from the previous program.
I mostly use AR, but pad some of the less reliable channels using the Multimode package. I add 2 minutes to the start (and end). Without this sometimes the first 30 seconds or so are not recorded. Occasionally the synopsis etc. is correct, so the hmt is probably updated close to the scheduled start time, depending on the broadcaster.
The cleanest solution is to update the hmt with detectads a couple of minutes after the scheduled start time, as this will accommodate any amount of padding. However, while the actual start time is correct in the hmt file (both original and detectads) when the synopsis information is for the previous programme, the scheduled time is too. If the variable you use for the scheduled start time is not read from the hmt file, this probably is the best way. If it does come from the hmt file, you may have to use the actual start time plus a few minutes. In my case, the actual start time plus 3 minutes will probably be enough. Actual start plus 6 minutes will likely accommodate up to 5 minutes padding at the start: do many people use more padding at the start than this?
 
I think the flag on the WebIf should at least say "Ad-detection" but certainly not "Addetection".
 
I mostly use AR, but pad some of the less reliable channels using the Multimode package. I add 2 minutes to the start (and end). Without this sometimes the first 30 seconds or so are not recorded. Occasionally the synopsis etc. is correct, so the hmt is probably updated close to the scheduled start time, depending on the broadcaster.
The cleanest solution is to update the hmt with detectads a couple of minutes after the scheduled start time, as this will accommodate any amount of padding. However, while the actual start time is correct in the hmt file (both original and detectads) when the synopsis information is for the previous programme, the scheduled time is too. If the variable you use for the scheduled start time is not read from the hmt file, this probably is the best way. If it does come from the hmt file, you may have to use the actual start time plus a few minutes. In my case, the actual start time plus 3 minutes will probably be enough. Actual start plus 6 minutes will likely accommodate up to 5 minutes padding at the start: do many people use more padding at the start than this?
So I cant rely on the schedstart time in hmt, it could be for the previous programme but I have no easy way of telling whether that is the case or whether it is an AR programme with a delayed start. I don't think the padding time is stored anywhere in the hmt and I don't use any other data source (other than settings DB).

I think the simplest (1 character) and safest change is to change to actual start time +3min, too much more and I risk not being able to process in parallel with recording for short programmes.

We are fortunate that the title field in the hmt is correct and doesn't contain the title of the previous program
 
So I cant rely on the schedstart time in hmt, it could be for the previous programme but I have no easy way of telling whether that is the case or whether it is an AR programme with a delayed start. I don't think the padding time is stored anywhere in the hmt and I don't use any other data source (other than settings DB).

I think the simplest (1 character) and safest change is to change to actual start time +3min, too much more and I risk not being able to process in parallel with recording for short programmes.

We are fortunate that the title field in the hmt is correct and doesn't contain the title of the previous program
Sounds sensible to me, and has a low risk of causing any other problems. I've not typically used more 2 minutes padding at the start; programmes tend to start late and then overrun rather than start much earlier than scheduled.
 
detectads seems to have stopped running on my "commercial" machine. I've been too busy to look into it - anything I should try quickly?
 
Back
Top