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

Stephen Worthington stephen_agent at jsw.gen.nz
Wed Sep 8 10:41:49 UTC 2021


On Tue, 7 Sep 2021 23:14:15 +0100, you wrote:

>On 06/09/2021 10:46, Stephen Worthington wrote:
>> 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%");
>> [snip]
>>> 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
>>> which?
>> 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="
>> timestamps.
>>
>> 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:
>>
>> http://www.jsw.gen.nz/mythtv/cross-eit.py

>Having checked more thoroughly the new version adds an hour incorrectly, 
>So a program scheduled for 18:00 in the donor listing is erroneously 
>scheduled at 19:00.

Since cross-eit.py does not change any times and works only in UTC, it
is not possible that it is cross-eit.py doing this.  So if that is
what you are seeing, we will need to debug what is happening
thoroughly.  The first thing to try is to dump the EPG data for both
the source and destination channels and see if there is anything
different between them.  You can do that with mysqldump:

sudo mysqldump mythconverg program -X -w "chanid=<source chandid>"
>source.xml
sudo mysqldump mythconverg program -X -w "chanid=<destination
chandid>" >dest.xml
diff -u source.xml dest.xml


More information about the mythtv-users mailing list