[DetectAds] Announcing DetectAds version 2

OwenMc said:
Today's manual detect ads are all failing for me with a memory allocation issue (Iwas set up to run traditional processing) - see below.

I was prompted for a package update first thing today, can't recall what it was though, but all yesterday's worked fine so I'm a tad suspicious....
Click to expand...

I have been out all day and only just got home but all of my recordings today have failed so I am also a tad suspicious that last night's update to libsndfile has not gone down too smoothly.

I will have time tomorrow to investigate properly - I probably need to recompile the Silence module with the latest version of libsndfile.
 
MymsMan said:
I have been out all day and only just got home but all of my recordings today have failed so I am also a tad suspicious that last night's update to libsndfile has not gone down too smoothly.

I will have time tomorrow to investigate properly - I probably need to recompile the Silence module with the latest version of libsndfile.
Click to expand...

After difficulty trying to remember all the ins and outs of cross compiling I have uploaded a version, 0.2.1-6, that appears to work with the new libsndfile package and hopefully resolves problems with large files.
 
I'm having a problem chase-playing ad-detected recordings (which I understood is possible). If I bring up the time bar, it only shows the length of recording (I presume) that had been processed by the time I started the play, complete with bookmarks so far, and it remains that way even when the processing has completed. I can't use bookmarks or transport control to go beyond the end time on the time bar, but the recording plays (if left to its own devices) to its full length.

Is this a known limitation? If not, is it unique to me?

My experience so far, apart for one instance where the ad-detected break was in the wrong place, has been pretty good.
 
Black Hole said:
I'm having a problem chase-playing ad-detected recordings (which I understood is possible). If I bring up the time bar, it only shows the length of recording (I presume) that had been processed by the time I started the play, complete with bookmarks so far, and it remains that way even when the processing has completed. I can't use bookmarks or transport control to go beyond the end time on the time bar, but the recording plays (if left to its own devices) to its full length.

Is this a known limitation? If not, is it unique to me?

My experience so far, apart for one instance where the ad-detected break was in the wrong place, has been pretty good.
Click to expand...
Chase play only works properly with the cropped recording since the Humax takes a snapshot of the hmt file at the time of opening and doesn't see any bookmarks that are added subsequently

See the Chase Playing section of the wiki page
 
Ah well, that's where I got confused. I have difficulty understanding how one could chase-play a recording that is going to have chunks removed from it, whereas it would be much easier to understand how one might chase-play a recording that is only having bookmarks added.
 
Once the file is opened for chase-play it doesn't matter if something else opens it to cut bits out of it by writing it to a new file. Linux even allows it to be renamed or deleted and your play will still work until you stop it. It's inode based not directory entry based, unlike Windoze which is the latter.
 
Further, when the recording is played again later, it still has the wrong metrics in the time bar. How did the .hmt become frozen like that?
 
Black Hole said:
Further, when the recording is played again later, it still has the wrong metrics in the time bar. How did the .hmt become frozen like that?
Click to expand...
It's not just yourself - I had the same last night, stuck at 2:02 on the time bar, played well beyond that, and updated the "where am i now" counter to reflect that.
There WERE no ad breaks after that happened, so can't comment on the bookmarking.

Also, I had a few missed ad-breaks in 1 recording (not the same one I was chase playing), though that may just have been 'cos there wasn't enough silence to trigger a 'break'.
I didn't go back to the original to check.
 
Black Hole said:
Further, when the recording is played again later, it still has the wrong metrics in the time bar. How did the .hmt become frozen like that?
Click to expand...
Whilst playing a recording the hmt is updated periodically to update the resume point but it appears that the humax rewrites most of the hmt from its cached copy overwriting the recording length and bookmarks rather than just updating the few bytes that need changing.
 
Ouch! That's a bugger, isn't it.

How about creating a working copy .hmt, which then gets written back when it's safe?
 
Black Hole said:
Ouch! That's a bugger, isn't it.

How about creating a working copy .hmt, which then gets written back when it's safe?
Click to expand...
Not sure how practical that would be,
Chase playing, by definition, finishes at some time after the recording has completed and after DetectAds has completed normal processing. You would need a periodic task checking whether the recording was still in use and safe to update the hmt.
Since a lot of programming is watch and then delete is it worth the effort and extra complexity?
 
"We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; " (JFK, 1962)
And because we can!
 
Trev said:
"We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; " (JFK, 1962)
And because we can!
Click to expand...
The US applied silly amounts of money and effort to the moon landing programme - my resources are somewhat more limited!

Fixing the recording duration on programs that have been chased played doesn't rank that highly on my Bucket list.
Of course if you would prefer that I devote myself to that cause rather than allowing your machine to go back to standby after a recording, retaining original file name titles, and the other myriad changes that have been requested just say the word ...
 
No, of course not Myms. I forgot to include the smiley in my post.
It's just that, in my case, 'because I can' frequently seems to outweigh any common sense regarding effort and time involved for minimal result.:rolleyes:
That's not implying that putting a man on the moon was a 'minimal result'.;)
 
There is nothing wrong with the phrase 'Because I can', however when it morphs into 'Because we can', 'Because someone else can', 'Because you can', that is when you run into problems regarding the time and effort involved
 
You must log in or register to reply here.
Back
Top