[DetectAds] Announcing DetectAds version 2
- Thread starter MymsMan
- Start date
OP
MymsMan
Ad detector
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
Dave F.
Member
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?
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?
OP
MymsMan
Ad detector
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.
MontysEvilTwin
Well-Known Member
I had a detectads error message I'd not seen before. Log below:
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?
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>
OP
MymsMan
Ad detector
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?
MontysEvilTwin
Well-Known Member
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.
MontysEvilTwin
Well-Known Member
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.
OP
MymsMan
Ad detector
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.
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.
MontysEvilTwin
Well-Known Member
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?
MontysEvilTwin
Well-Known Member
I've attached hmt files, grabbed while a chaseget run was ongoing, with corresponding screenshots to illustrate:
OP
MymsMan
Ad detector
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
MontysEvilTwin
Well-Known Member
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.
Black Hole
May contain traces of nut
detectads seems to have stopped running on my "commercial" machine. I've been too busy to look into it - anything I should try quickly?
Black Hole
May contain traces of nut
It's already installed (listed as a dependency of sysmon).
OP
MymsMan
Ad detector
In that case we will need some proper diagnostics!
Turn on Debugging logging under General Settings on Diag page and post the detectads.log
Black Hole
May contain traces of nut
Roger that. I'll give it some time...