[DetectAds] Announcing DetectAds version 2

MymsMan said:
... I wondered if there was any chance of modifying an HDR firmware sufficiently to allow it install on an HD and provide a DLNA-decryption server that way
Click to expand...
IIRC we know what DLNA server code was adapted by Humax and so a strategy might be to build that and look for similar playback calls in the humax_tv blob. Then it might be possible also to build a stand-alone HW decrypting DLNA server that doesn't crash the TV. Will anyone manage this before the 2038 bug strikes? Maybe not.
 
Black Hole said:
... references to decrypted download options, decrypt-in-place from the WebIF OPT+ menu, and unencrypt (automated decryption in the background) DO NOT APPLY to the HD-FOX. ...
Click to expand...
As above, the HD is now equal to the HDR in this area, so this text is out of date, except that the timeout issue may be more likely for decrypt-in-place on the HD.
 
/df said:
My "work"flow is to run detectads from Sweeper rules which I'd like to have the same regardless of platform. So currently I have to queue a recording for decryption and then queue it for ad-detection.
Click to expand...
Queue processing is set up so that decryption runs before ad-detection so it is safe to put both requests on the queue at the same time.
So your sweeper rules could say after the rule that selects a recording and Queues it for ad-detection
1579963079855.png

It will take me a while to understand how the your pipelining of stripts works
 
MymsMan said:
...
It will take me a while to understand how your pipelining of stripts works
Click to expand...
man fifo, etc.

stripts expects to write to a file: presumably it just opens it for writing and writes to it sequentially. If the file is already there and is a FIFO (named pipe) the FIFO buffers the output. Then you can read the data from the FIFO and direct it to stdout or a file; I used cat but possibly you could code that using Jim AIO primitives. You have to redirect stripts's stdout to avoid appending it to the decrypted file in the stdout case. All of this is done in 2 exec subprocesses linked by the FIFO; I hope that completion of the cat process indicates that the decryption finished or failed: maybe worth testing to see if it can hang. stripts also creates the sidecar files and so the whole lot are deleted at the end; if you did want them you could have called stripts directly.

I was a bit surprised that it worked (let alone so well). As an inexpert TCLer (which means that the error checking may be a bit random), I tried a shell script first: it's is a bit shorter.
 
af123 said:
With the encryption key set to all 3s or something similar? It is a lot faster with a repeated key than without.
Click to expand...
1579965244835.png
The first example above is with the machine set to the manufacturers encryption key (10 minute recording so wouldn't rule out chasedecryption)
The second example id with key all x00 so much faster
 
Bit of suggestion.

If you run chase decryption and watch the file during transmission often you end up with a crop file and the original permanently left behind. I wondered if the failure to delete the original and rename the crop couldn't be put on the queue of tasks to try once the file lock was removed so it could complete later on a failure?
 
salad dodger said:
Bit of suggestion.

If you run chase decryption and watch the file during transmission often you end up with a crop file and the original permanently left behind. I wondered if the failure to delete the original and rename the crop couldn't be put on the queue of tasks to try once the file lock was removed so it could complete later on a failure?
Click to expand...
It's an idea but often recordings are moved/renamed by Sweeper so can't be found later, if I have chased played a programme I just usually delete the original and crop as soon as I've done watching.
I've added it to the to-do list.
 
MymsMan said:
It's an idea but often recordings are moved/renamed by Sweeper so can't be found later,
Click to expand...
I would find that useful too as I frequently do as salad dodger does. You could just exit with no error message. It would be a better solution than having to delete them both as at present, and if they have been moved by sweeper, cest la vie.
 
Last edited:
Hi @MymsMan

I think I've (finally) got to grips with this package … Thank You, very much for all the work you've put into it ;)

I think I've now got it working for me … but I did have some challenges, the final one of which I sorted out last night by reading just about all of this thread (I must admit, I skim read most of it :whistling: ) … and while it's nice to know that other members have faced the same mis-understandings as me of how this package works … and I can't be sure of what the wiki said when they had their mis-understanding … I thing I'd suggest (because I still didn't spot this) that the wiki still isn't as clear as it could be around chase-playing when "Crop recording following ad detection?" is set to "No" ;) … as a "case study" ... I had to get as far as post #127, on page 7, of this thread before I got the message that this might not work (properly) when you said the following, in response to questions from Black Hole …
MymsMan said:
Chase play only works properly with the cropped recording …
Click to expand...
... but then that was more than two years ago and there were still another 13 pages of discussion (and possible developments) to review before I'd know whether that was still the case ... but then you re-asserted the information, a little more definitively IMHO, in post #355, on page 18 of the thread, in response to a discussion between Trev and BennyBoy ...
MymsMan said:
Cropping is the only way to take advantage of ad-detection during recording …
Click to expand...

So can I request that the wiki is made a little more "definitive", to reflect the above quotations ... I realise that the first line of the Chase playing section of the wiki says "You can watch the cropped output from the chaserun process whilst recording is still in progress" ... but it doesn't say you can't (reliably) watch the decrypted and bookmarked output ... so perhaps that first line could be updated with the extra text (added text underlined in red, like tracked changes in Word ... I'm not suggesting they should be made red to stand out like that :thumbsup:) ...
You can watch the cropped (but not decrypted and bookmarked) output from the chaserun process whilst recording is still in progress either through the normal TV user interface or via file sharing using an application such as VLC however there are a number of things to be born in mind.
Click to expand...
… and/or, an extra bullet point in the list of things to be borne in mind in that section could say ...
DetectAds can not place bookmarks into a programme that is being recorded or played because the Humax frequently updates the hmt file with the current status and that overwrites the bookmarks. In chaserun mode you will only see the bookmarks at the end of recording when the Humax has finished updating the hmt file. For this reason, Cropping is the only way to take advantage of chase playing with ad-detection during recording.
Click to expand...

Thanks, once again for all the good work :thumbsup: :thumbsup::cheers:
Cheers, Phil
 
I am, slowly, working my way through my to-do list and will update the wiki before releasing the next version.
I will include your comments with others then.
 

Auto re-create sidecar files

I am running detectads in chaseplay mode and the transport mechanism Skip/skip back etc. (sidecar files?) fails on the cropped recording. Is there a way of automatically running the sidecar package immediately after decryption and cropping? And would this fix it? I must try running it manually...
hummy.tv hummy.tv
 
I'm a great fan of this package and have been using it for years on my HDR T2. I'm thinking of getting a Foxsat HDR and would like to have Detectads on that too. I've been doing some reading & posted a thread in the Foxsat section and am guessing from the replies that the code will need to be compiled for the Foxsat? If so, is it possible to have the code put into the hummy git repo?
git.hpkg.tv

hummypkg

Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go
git.hpkg.tv git.hpkg.tv
TBH, I'm totally new to this, but dark winter days are approaching so it might be a good project. Maybe I'm just wishfully thinking that this can be done, and maybe there are dependencies that are not possible on the Foxsat?
 
The package is already on the git repository and anyone is welcome to fork the package

However the underlying web interface on the HDR T2 has diverged and evolved considerably from that on the Foxsat so I am not sure how easy it would be to port the package to the Foxsat.

I have never has a Foxsat so I don't know if you can access the hard disk across the network.
If you can access the disk remotely then you could consider running ad detection remotely, either using detectads running on the T2 or by software running on a PC - several people have reported success using AdBreaker to remove ads from programmes recorded on HdHomeRun using DVRonTime.
Programmes would need to decrypted before any ad detection could be performed
 
Many thanks @MymsMan for your quick reply and the links.
I suspect you're right about the webif compatibility and like the idea of running ad detection remotely. From the little I've read so far it looks like remote access to the Foxsat drive may be possible. When I get a Foxsat, I'll see how possible / practical it is.
 
I have run DetectAds on Foxsat HDR recordings by copying the .ts file only across to my Fox T2. Use Sidecar to create appropriate files so the T2 can then use DetectAds on the recording. The recording can then be played back on the T2.

P.S. These are SD recordings as I don't have the Nowsters(?) patch installed on the Foxsat.
 
You must log in or register to reply here.
Back
Top