DetectAds bookmarks

DAsh

DAsh

Member
I’ve setup the latest version of CF using a temporary Ethernet connection to my router and applied a few key packages. One of which is DetectAds.

For DetectAds to work I eventually realised that I needed to enable content sharing in the Humax’s internet settings

I recorded a channel 4 programme and disconnected the Ethernet cable after the first set of ads. Afterwards I found that the CF had successfully bookmarked the end of the first set of ads, but not the subsequent sets of ads.

Do I need the Humax to be connected for bookmarking of ads?

(I selected the option to process the file while still recording using Chaserun)

Thanks

Dave
 
Last edited:
DAsh said:
Do I need the Humax to be connected for bookmarking of ads?
Click to expand...
Connected to the Internet you mean? No, why would it?

If it marked any ad breaks at all, it seems to be working. Detection requires characteristic silences in the soundtrack, and if they are not present in the right pattern detection will fail.

There is a slight possibility you haven't given it enough time to process.

Update: The above is completely wrong in the light of subsequent discussion. I had expected the CF decryption facilities used the internal loop-back IP address, but af123 tells us the loop-back doesn't work for DLNA streaming (the key to custom decryption) so has to be implemented by the HDR-FOX addressing its own IP address via the home network, hence needing (at the very least) a loop-back jack/plug/cable connected to the Ethernet socket in the absence of a full network.

DAsh said:
For DetectAds to work I eventually realised that I needed to enable content sharing in the Humax’s internet settings
Click to expand...
Of course! Everything that requires access to decrypted recordings relies on Content Share being turned on. Have you read any instructions? If so, which ones don't tell you to enable decryption (so we can fix them)?

Update: Disconnection of the network does not automatically cancel the Content Share setting, although it does cancel itself from time to time, apparently at random (or at least for reasons unknown). It can be enforced (each boot) using the bootsettings package.

DAsh said:
Dave
Click to expand...
We know who you are, you don't need to sign off every post.
 
Last edited:
Black Hole said:
Connected to the Internet you mean? No, why would it?
Click to expand...
Thinking about this some more (and I'm talking off the top of my head), there could (just) be a connection: the custom decryption relies on the DLNA server (which is what gets turned on when you enable Content Sharing), and an internally-routed network data transfer. If the internal link stops working without an external connection...

I don't think that would explain your observation though.
 
DetectAds relies on the DLNA server being active to allow for decryption and it id quite possible that the Humax turns off the server when there is no network connection and no-one to share content with.

Are there any messages in detectads.log
 
We know that the server does get turned off randomly, but I am not aware of a causal link... I'll have a fiddle.
 
The symptoms are consistent.

DetectAds was able to detect the first ad break before network connection was lost, but couldn't process anything afterwards.

I would expect it to have reported a decryption length error and queued the recording for later processing.
 
I have added a comment about Content Sharing in the Installation section of the DetectAds wiki page.

MymsMan said:
I would expect it to have reported a decryption length error and queued the recording for later processing.
Click to expand...
I thought something ought to have fallen over!

MymsMan said:
The symptoms are consistent.
Click to expand...
Er, no, not unless the OP neglected to mention something.
 
0UQ5OyA.jpg


Attached file shows that DetectAds was indeed affected by removal of the ethernet cable.

It appears that there's no chance of the scan resuming now that I've reconnected the cable due to auto deletion of the temp files at lines 18 to 23

Looks like I'll have to get myself some homeplugs
 
Last edited:
It should be possible to crack this (although it may take some time). It's not been spotted before because (I guess) the vast majority of CF users have their machines networked. I haven't seen any problems on my non-networked machine because it isn't used to decrypt.

In the above post I don't understand the reference to IP address 10.0.1.34. These internal operations ought to be using the default loop-back address 127.0.0.1.

Even without a software cure, it might be possible to use a loop-back Ethernet plug rather than a full network. Or at worst a local connection (a HomePlug wouldn't have to actually connect to something else).

That said, getting connected is the best way to go. You may like to consider a WiFi dongle instead of HomePlugs. For more info see https://hummy.tv/forum/threads/conn...wifi-and-wifi-extender.5754/page-2#post-75945.
 
Yes, maybe, but 127.0.0.1 is a better address for the software to use for accesses to itself. My contention is that it would stop things breaking if there was no network.
 
Black Hole said:
Yes, maybe, but 127.0.0.1 is a better address for the software to use for accesses to itself. My contention is that it would stop things breaking if there was no network.
Click to expand...
The DLNA server is not accessible via the loopback (127.0.0.1) address.
You can make up a dummy loopback plug to keep the Ethernet link alive though.
 
I've updated the decryption guide to include the requirement for Ethernet activity. Good spot - how many years have we been doing this?
 
DAsh: I've been busy making sure all the reference sources include the requirement for a network connection (or at least a loop-back jack) for the decryption processes, and inserted a paragraph in the DetectAds wiki entry to state that it relies on decryption.

Thank you very much for bringing this to my attention (no, that's not intended sarcastically).
 
You must log in or register to reply here.
Back
Top