[mythtv-users] Fwd: Fwd: Re: channel4 hd has no eit - cross-eit

Stephen Worthington stephen_agent at jsw.gen.nz
Mon Sep 6 09:46:54 UTC 2021

On Mon, 6 Sep 2021 07:01:01 +0100, you wrote:

>On Sun, 5 Sept 2021 at 11:10, John <jksjdevelop at gmail.com> wrote:
>> I use 65692 which does work but the number may differ for you, test the SD
>> channel you pick as source for the EIT of the HD channel.
>How can I tell which one it is? I see no clue from the query below as to
>which of them is being used for EIT.
> select serviceid,chanid,channum,sourceid,callsign,deleted,xmltvid from
>channel where callsign like("%Channel 4%");
>I also tried looking at all the existing column headings in "channel" (with
>"select * from channel") but none suggested that a channel was being used
>for EIT. Obviously that info must be in some other table. Would you know

The field you want is "useonairguide".

>> I am testing the following to cope with the clocks changing.
>> I know its cringe worthy but might work, the two versions of crosseit have
>> the single line change.
>>  # Winter --
>>     # date = dateobj # + datetime.timedelta(seconds=time.altzone)
>>     # Summer
>>     date = dateobj + datetime.timedelta(seconds=time.altzone)
>>  #!/bin/bash
>> if date +%Z | grep -e BST; then
>>     echo "Summer"
>>     ./cross-eit3S.py 65692,"hd.channel4.com"
>> else
>>     echo "Winter"
>>     ./cross-eit3W.py 65692,"hd.channel4.com"
>> fi
>> /usr/local/bin/mythfilldatabase --refresh-all --verbose xmltv --file
>> --sourceid 1 --xmlfile output.xml
>You are right that the mix of bash and python is somewhat cringe-worthy: it
>would be neater to do the change in python rather than calling two versions
>of the script.
>However a more serious problem is that this approach changes the time zone
>for all the dates in the EIT for that week. In steady state that's likely
>to be fine, but in those two transition weeks of the year, when one batch
>of listings has some listings before the change and some after the change,
>some of those listings will be assigned the wrong offset.
>The correct but slightly more laborious fix, in my opinion, would be to
>apply the offset to each individual programme listing in the batch, thus
>possibly having programmes in the same batch with different UTC offsets,
>which will happen during those transition weeks. I'll code it up in python
>when I have a moment, starting from the code that Stephen posted yesterday
>that got rid of the absurdly long lines.

No, there will not be different offsets.  Cross-eit.py is exporting
data from the MythTV database.  MythTV internally only works in UTC,
so all the exported data will be UTC.  So all that needs to be done is
to add the string " +0000" on the end of the "start=" and "stop="

When mythfilldatabase reads an XMLTV file, it will use the timezone
offsets to convert each timestamp to UTC before it puts it into the
database.  EPG collected from a TV channel (using EIT, MHEG5 or OpenTV
which are the formats I have used) is usually in local time and
therefore will have the correct offsets on it.  When that collected
data crosses a daylight saving change, you will see the offset values
change (unless the EPG provider has screwed things up, which is fairly
common in this part of the world).

It is possible that the old cross-eit.py code that included using
timedelta was from when MythTV used local times in its database.  That
caused hideous complications in the code for handling daylight saving,
so the internal times were all changed to UTC many versions of MythTV
ago now.

I have put an updated version of cross-eit.py (v2.1) with this change
on my web server:


More information about the mythtv-users mailing list