Has there been a Change to Webif Detect Ads?

[SunnysideUK]

I've noticed that my detect adverts seems t have changed. I noticed this several weeks ago and the problem has remained.
Maybe its not my Humax4 (another updated Humax does the same).

Essentially I have the detection mark the advert points and then I fine tune the positions and run ad removal from Webif.
Now I have to use the sidecar option after auto-detection to update existing HMT file, as its last set bookmark is way short of reality (but shows it at the end on the play bar)
Then I manually add the end bookmark.
I then have to go through the bookmarks to correct them. The first 2 are usually correct but then they drift off.
This does now have a side effect: where the start of the ad was, the recoding suddenly jumps (on the play bar) to the end of the now non existing ad break. This is where I put the new bookmark (I like to keep the bookmarks at the ad removal points).

Is there a fix for this as is or can I rollback to a previous working version?

 

[MymsMan]

There have been no changes to detectads since 2019 (long overdue for an update)

I don't understand what you are saying - the last bookmark should be at the detected end of programme/start of trailing ads
I don't understand why the sidecar utility is needed or would help

Bookmarks can drift from correct positions if there is interference/glitches in the recordings which cause the extracted audio track that detectads uses for detection to be shorter than the actual recording. Detectads should create a length error warning/notification if the difference is longer than 5/10 seconds.
These values can be customised in settings.

-misDetSec  5    = Warn if more than n secs data missing during ad detection
-misDetAlarm 10  = Webif notification if more than n secs data missing during ad detection

Screen shots of bookmarks before and after running sidecar might help.

 

[SunnysideUK]

There have been no changes to detectads since 2019 (long overdue for an update)

I don't understand what you are saying - the last bookmark should be at the detected end of programme/start of trailing ads
I don't understand why the sidecar utility is needed or would help

Bookmarks can drift from correct positions if there is interference/glitches in the recordings which cause the extracted audio track that detectads uses for detection to be shorter than the actual recording. Detectads should create a length error warning/notification if the difference is longer than 5/10 seconds.
These values can be customised in settings.

-misDetSec  5    = Warn if more than n secs data missing during ad detection
-misDetAlarm 10  = Webif notification if more than n secs data missing during ad detection

Screen shots of bookmarks before and after running sidecar might help.

Understood. I thought of that but after cropping a recording this am.
I do have my log of the process though.
I'll do some snapshots on the next recording but I'll gave to schdul;e one as I've only got BBC politics scheduled fort the next few days.

#1. 07:12 11-02-2025    Panic in Year Zero (1962)_20250211_0130     6.6
#2.            Length:    01:44:57    Size:    1.5 GiB (SD)
#3.            Length:    01:40:12    Size:    999.2 MiB (SD)
#4.            0 12 1401 3172 4879 5908

#5. 16 2944 3192 4652 4900 6034 (6297)
#6. 19 1175 1420 2945 3191 4652 4898 6032 -added missing ad.
#7. 19     1175 1420   2945 3191   4652 4898   6032
#8.            -2                 -2                  -2
#9. 19     1173 1420   2943 3191   4650 4898   6032 | 0 1157 2680 4139 5262 6014 | 0 1157 3172 4880 5894

Lines 1-4 are my summery. #2 before, #3 after and #4 my final bookmarks.
#5 are the auto-detected bookmarks. I added the braced no: 6297 as the new one bookmark I added after updating the HMT file.
Unfortunately in this case an ad was missing (easily see gap in the Webif GUI) and I added that manually as can be see in #6.
#7 are my corrections to the bookmarks.
#8 are the corrections as there is a delay at bookmark before the cur point (-2 seconds)
#9. the figures at the end are the bookmarks generated post cropping and the correct one I now have to do manually
Post cropping Corrected
| 0 1157 2680 4139 5262 6014 | 0 1157 3172 4880 5894 |
As you can see the first ad bookmark (1157) is correct and go wrong after.

 

[SunnysideUK]

Snapshots of test recording today: "The Quiet Woman (1951)_20250211_1305"

Humax ad detection 1 Post detection
[ATTACH type="full" size="1381x420"]7362[/ATTACH]

Humax ad detection 2a Pre-Crop (corrected)
[ATTACH type="full" size="1356x395"]7363[/ATTACH]

Humax ad detection 2b Pre-Crop (corrected)
[ATTACH type="full" size="994x587"]7364[/ATTACH]

Humax ad detection 3a Cropping 1 (~60sec in)
[ATTACH type="full" size="987x602"]7365[/ATTACH]

Humax ad detection 3b Cropping 2
[ATTACH type="full" size="992x611"]7366[/ATTACH]

Humax ad detection 3c Post-Cropping Report {+4min10sec. I don't remember happening this before)
[ATTACH type="full" size="1304x984"]7367[/ATTACH]

Humax ad detection 4 Post-Cropping Bookmarks
[ATTACH type="full" size="1361x400"]7368[/ATTACH]

Humax ad detection 5 Updating HMT Report
[ATTACH type="full" size="1107x879"]7369[/ATTACH]

Humax ad detection 6 Post HMT update Bookmarks
[ATTACH type="full" size="1355x395"]7370[/ATTACH]

Humax ad detection 7a Corrected Bookmarks (leaving detected to be removed)
[ATTACH type="full" size="1357x402"]7371[/ATTACH]

Humax ad detection 7b Corrected Bookmarks (leaving 2nd bm to be removed, as start of removed ad)
[ATTACH type="full" size="1357x390"]7372[/ATTACH]

Re. image 3c.
I don't remember this post processing happening before. Its adding over 4 minutes to the initial 2 minutes process.
Its something I’d do manually on occasion post ad removal, but it now seems to be automated every time.
Also note: detection missed 2 ad breaks I had to manually add in.

{Edit. Oh! the images are not the way I see then on editing! Maybe I shouldn't use CODE?}

P.S. I remember a few weeks ago someone posting ad detection now taking a long time.....

 

[Black Hole]

{Edit. Oh! the images are not the way I see then on editing! Maybe I shouldn't use CODE?}

Yes. Inside code tags the forum presents the content literally, without interpretation... so why use code tags at alll?

FWIW detectads is working fine for me, but I only bookmark and never crop.

 

[SunnysideUK]

Yes. Inside code tags the forum presents the content literally, without interpretation... so why use code tags at alll?

FWIW detectads is working fine for me, but I only bookmark and never crop.

I was trying not to swamp the page with lots of pictures!
Not sure of the best way to present lots of images.

 

[MymsMan]

As well as removing the code tags - change to [spoiler] if you want, can you show the detectads log entries related to processing the file (in either detectads.log if using chaserun detection or auto log if processing after recording)
It looks as if detectads may have failed while processing the ad break at 1:22

Please keep the original recording - I may need to ask you to reprocess

P.S. I remember a few weeks ago someone posting ad detection now taking a long time.....

Ad detection has always taken a long time - but that can be reduced to almost nothing by using chaserun mode to run in parallel with recording.
The 4 minutes you are commenting on is when running Crop not Detectads but the 1:40 was just an estimate and the progress bar is based on that estimate, don't know why it was so wrong.

BTW you don't need a Bookmark at the very end of recording.

 

[Black Hole]

I was trying not to swamp the page with lots of pictures!

Insert Thumbnail. From Newbie's Guide:

Images & Media

Sometimes an image can explain a problem (or a solution) far more effectively than mere words, and 'still' (non-video) image files such as JPG or PNG can be attached to a post and inserted into the post itself. Some browser/OS combinations allow a file to be dragged into the post directly, otherwise click the "upload a file" button below the editor window (if you don't see it, try "more options").

When uploaded, the file becomes an attachment to the post which readers can access. To display the image within the post itself: once the file had been uploaded, position the text cursor at the place you want to include the image and then insert by clicking "Thumbnail" or "Full Image". It is preferable to insert only a thumbnail wherever possible, as this reduces the displayed length of a topic and the download time on slow connections...

 

[SunnysideUK]

Yes. Inside code tags the forum presents the content literally, without interpretation... so why use code tags at alll?

FWIW detectads is working fine for me, but I only bookmark and never crop.

Yes, this part is ok, it’s the cropping part that seems to have changed with a now some extra post processing, perhaps now tripling the process time, say from 2min to 6mins. It never used to do this.
On wondering if I should reset the box and start again (presumably a system flush).
Not sure if backing up and files is a good idea in case one or more are corrupt in some way and I end up reintroducing problems.

 

[MymsMan]

Yes, this part is ok, it’s the cropping part that seems to have changed with a now some extra post processing, perhaps now tripling the process time, say from 2min to 6mins. It never used to do this.
On wondering if I should reset the box and start again (presumably a system flush).
Not sure if backing up and files is a good idea in case one or more are corrupt in some way and I end up reintroducing problems.

Since late last year crop now includes running sidecar to rebuild the .nts to improve skipping and fastforward on cropped recording.

It would appear that @prpr probably didn't adjust the time estimate to allow for this extra processing.
I have been trying to think whether it would be possible to overlap cropping and sidecar prcoessing, possibly using named pipes, to reduce the elapsed time

 

[prpr]

It would appear that @prpr probably didn't adjust the time estimate to allow for this extra processing.

Indeed not.

I have been trying to think whether it would be possible to overlap cropping and sidecar prcoessing, possibly using named pipes, to reduce the elapsed time

I think sidecar reads the whole .ts file to index it before writing the .nts, so it seems unlikely to be possible.

 

[SunnysideUK]

Since late last year crop now includes running sidecar to rebuild the .nts to improve skipping and fastforward on cropped recording.

It would appear that @prpr probably didn't adjust the time estimate to allow for this extra processing.
I have been trying to think whether it would be possible to overlap cropping and sidecar prcoessing, possibly using named pipes, to reduce the elapsed time

Is it possible to backdate Webif to the version before this change?
Is so, how please?

 

[Black Hole]

Is it possible to backdate Webif to the version before this change?
Is so, how please?

I think you misunderstand. The WebIF needs updating to account for the extra processing in its progress bar. You don't want the version without the extra processing!

 

[prpr]

Is it possible to backdate Webif to the version before this change?

There lies dependency hell and consequent misery.
What's the actual problem here? Do you not care about having the sidecar files correct? If not, uninstall sidecar and it won't run.