[mythtv-users] UK Commercial Detection (Clusters)

[Roger Siddons]

On Mon, 29 Apr 2013 11:37:25 +0100, Phill Edwards <philledwards at gmail.com>  
wrote:

>
> I've been trying to test out this script by running ot from the
> command line first off (before setting it up as a job in MythTV). I'm
> having trouble getting it working. I'm using these programs from the
> recordedprogram table as the test bed:
>
> mysql> select chanid, starttime, title from recordedprogram where
> title like "Modern%";
> +--------+---------------------+---------------+
> | chanid | starttime           | title         |
> +--------+---------------------+---------------+
> |   2573 | 2013-04-10 09:30:00 | Modern Family |
> |   2573 | 2013-03-31 08:00:00 | Modern Family |
> |   2573 | 2013-04-17 09:30:00 | Modern Family |
> |   2573 | 2013-03-27 08:30:00 | Modern Family |
> |   2573 | 2013-04-03 08:30:00 | Modern Family |
> |   2573 | 2013-04-14 09:00:00 | Modern Family |
> +--------+---------------------+---------------+
>
> So I then execute this from the command line but get a failure to log
> into MySQL (I think that's why it's failing):
>
> $ silence.py --chanid 2573 --starttime 20130410093000 --loglevel debug
> 2013-04-29 20:22:30.912538 D [18671] Python Database Connection Trying
> database credentials from: /home/phill/config.xml
> 2013-04-29 20:22:30.923958 D [18671] Python Database Connection Trying
> database credentials from: /home/phill/config.xml
> 2013-04-29 20:22:30.940568 E [18671] m mythcommflag: Could not find  
> recording
>
> /home/phill/config.xml exists and is a symbolic link to  
> /etc/mythtv/config.xml.
>
> I'm running Ubuntu 12.04 & Myth 0.26. All of my storage group
> directory names have slashes on the end. I'm doing this in Australia
> (is this a UTC issue?) Can anyone see why this is failing? What dumb
> mistake am I making here?

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.

The connection errors aren't important - IME the Python bindings sometimes  
take a while to connect. The last line indicates that the connection  
succeeded but your starttime is wrong.

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.