[mythtv-users] UK Commercial Detection (Clusters)

Phill Edwards philledwards at gmail.com
Wed May 1 11:15:17 UTC 2013


> I suspect it's UTC & padding that's thwarting you. Unfortunately I wrote
> the Wiki when the UK was on UTC+0, so didn't fully appreciate these issues
> at the time.
>
> Firstly, the 'recordedprogram' table is showing you nominal program times.
> Check the 'recorded' table for the actual recording start time. If you use
> padding, you'll find your target recording starts at 9:28 or thereabouts.
> It's easier/safer to get the time from the recording filename.
>
> All those times are in UTC, whereas the Python bindings seem to use local
> time (my version does but things may have changed recently - I haven't
> checked/updated for several months) Therefore (assuming you're on UTC+10) I
> would guess you should be looking for something like 20130410192800. Note
> adding a '+1000' suffix has no effect - it's purely cosmetic.
>
> Post back if I'm right and I'll add a note to the Wiki about this.

Pure genius, Roger! It was, indeed, a UTC & padding issue.

This time I selected the recording starttime from the recorded table,
like you said:

mysql> select chanid, starttime, title from recorded where title = "Family Guy";
+--------+---------------------+------------+
| chanid | starttime           | title      |
+--------+---------------------+------------+
|   2315 | 2013-04-09 12:28:00 | Family Guy |
+--------+---------------------+------------+

Then on the command line I ran the following, which found and
commflagged the recording file:

$ silence.py --chanid 2315 --starttime 20130409222800 --loglevel debug

Notice how the start time of 12:28:00 from recorded.starttime resulted
in a time element of 22:28:00 in the filename (because the recording
was made while my timezone was UTC +10 hrs).

It only actually detected 2 out of 4 ad breaks but that's probably
something I can work on with the tuning parameters.

Thanks for your help, Roger.


More information about the mythtv-users mailing list