-Decrypt files

hairy_mutley

Active Member
I am sure that this has been discussed in the past, but my searches have not managed to find a reference.
I seem to have a number of files around ending with "-Decrypt" along with their vanilla equivalent. Both show the green "Dec" & "Ad" symbols. Both filesets are complete (.ts, .thm, .mht & .nts) and appear to play, the .ts files are the same size and on the few that I have tested, the .ts files are identical. Does it matter which fileset I get rid of?
 
If they are the same size, are decrypted and have ad breaks marked then you can delete either file. I usually delete the version with '-dec' in the filename as there are tags in the hmt file which are more effort to remove (they don't cause any problems, I just prefer not to have them in the final version of the recording).
I think what happens (when Detectads is running in chaseget mode) after the recording, decryption and adbreak detection is complete, is that the processed recording is moved from 'mod/tmp' to the original folder, the original recording is deleted, and the processed one is renamed to remove the '-dec' suffix and any tags (like '-decrypt') from the hmt file. If you are watching the original recording in chase play mode, for example, when the recording finishes it is not deleted and you end up with two sets of files. At this point the original will not be decrypted. What usually happens if you don't delete the original file is that it is 'traditionally' processed later so it also ends up decrypted with marked adbreaks.
 
OK, thanks for the advice.
As for the mechanism... it must be different in my case, I don't use chaseget (I have found it to cause glitches when watching something at the same time, but that is another story.
The vanilla files show a file time just after recording ends. The "-dec" files show a time in the 04:30 window when the box wakes and I have sweeper rules to perform the decrypt and ad-detect. It seems that for about 7 nights, most recordings from the previous day have a -dec fileset for just after 04:30. However, there have been no new instances for over 9 days.
I will try and have another look at the files to see if any other pattern emerges.
 
If the files are still encrypted when detectads process starts it will still use the chaseget mechanism even though the recording is complete.
It sounds as if your sweeper rules might be kicking off the decrypt and detectads tasks at the same time, you could avoid this by adding a check for 'Recording Not flagged as encrypted' to the rule so that ad detection only starts once the the decryption is done
 
It seems that I had detect-ads before decrypt. Anyway, how does this look now?
Code:
recurse 9 or {now {<= 0400} now {> 0500} } action stop
# Queue for Decrypt
recurse 9 flag ODEncrypted !queue any action {queue decrypt}
# Queue for DetectAds
recurse 9 bookmarks 0 !flag Addetection !textmatch %channel~~BBC* !queue detectads !flag ODEncrypted action {queue detectads}
 
Back
Top