<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Sept 2021 at 11:57, John <<a href="mailto:jksjdevelop@gmail.com">jksjdevelop@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 06/09/2021 10:46, Stephen Worthington wrote:<br>
> On Mon, 6 Sep 2021 07:01:01 +0100, you wrote:<br>
><br>
>> On Sun, 5 Sept 2021 at 11:10, John <<a href="mailto:jksjdevelop@gmail.com" target="_blank">jksjdevelop@gmail.com</a>> wrote:<br>
>><br>
>>> I use 65692 which does work but the number may differ for you, test the SD<br>
>>> channel you pick as source for the EIT of the HD channel.<br>
>>><br>
>> How can I tell which one it is? I see no clue from the query below as to<br>
>> which of them is being used for EIT.<br>
>><br>
>> select serviceid,chanid,channum,sourceid,callsign,deleted,xmltvid from<br>
>> channel where callsign like("%Channel 4%");<br>
> [snip]<br>
>> I also tried looking at all the existing column headings in "channel" (with<br>
>> "select * from channel") but none suggested that a channel was being used<br>
>> for EIT. Obviously that info must be in some other table. Would you know<br>
>> which?<br>
> The field you want is "useonairguide".<br>
><br>
>>> I am testing the following to cope with the clocks changing.<br>
>>><br>
>>> I know its cringe worthy but might work, the two versions of crosseit have<br>
>>> the single line change.<br>
>>><br>
>>> # Winter --<br>
>>> # date = dateobj # + datetime.timedelta(seconds=time.altzone)<br>
>>> # Summer<br>
>>> date = dateobj + datetime.timedelta(seconds=time.altzone)<br>
>>><br>
>>> #!/bin/bash<br>
>>> if date +%Z | grep -e BST; then<br>
>>> echo "Summer"<br>
>>> ./cross-eit3S.py 65692,"<a href="http://hd.channel4.com" rel="noreferrer" target="_blank">hd.channel4.com</a>"<br>
>>> else<br>
>>> echo "Winter"<br>
>>> ./cross-eit3W.py 65692,"<a href="http://hd.channel4.com" rel="noreferrer" target="_blank">hd.channel4.com</a>"<br>
>>> fi<br>
>>> /usr/local/bin/mythfilldatabase --refresh-all --verbose xmltv --file<br>
>>> --sourceid 1 --xmlfile output.xml<br>
>>><br>
>> You are right that the mix of bash and python is somewhat cringe-worthy: it<br>
>> would be neater to do the change in python rather than calling two versions<br>
>> of the script.<br>
>><br>
>> However a more serious problem is that this approach changes the time zone<br>
>> for all the dates in the EIT for that week. In steady state that's likely<br>
>> to be fine, but in those two transition weeks of the year, when one batch<br>
>> of listings has some listings before the change and some after the change,<br>
>> some of those listings will be assigned the wrong offset.<br>
>><br>
>> The correct but slightly more laborious fix, in my opinion, would be to<br>
>> apply the offset to each individual programme listing in the batch, thus<br>
>> possibly having programmes in the same batch with different UTC offsets,<br>
>> which will happen during those transition weeks. I'll code it up in python<br>
>> when I have a moment, starting from the code that Stephen posted yesterday<br>
>> that got rid of the absurdly long lines.<br>
> No, there will not be different offsets. Cross-eit.py is exporting<br>
> data from the MythTV database. MythTV internally only works in UTC,<br>
> so all the exported data will be UTC. So all that needs to be done is<br>
> to add the string " +0000" on the end of the "start=" and "stop="<br>
> timestamps.<br>
><br>
> When mythfilldatabase reads an XMLTV file, it will use the timezone<br>
> offsets to convert each timestamp to UTC before it puts it into the<br>
> database. EPG collected from a TV channel (using EIT, MHEG5 or OpenTV<br>
> which are the formats I have used) is usually in local time and<br>
> therefore will have the correct offsets on it. When that collected<br>
> data crosses a daylight saving change, you will see the offset values<br>
> change (unless the EPG provider has screwed things up, which is fairly<br>
> common in this part of the world).<br>
><br>
> It is possible that the old cross-eit.py code that included using<br>
> timedelta was from when MythTV used local times in its database. That<br>
> caused hideous complications in the code for handling daylight saving,<br>
> so the internal times were all changed to UTC many versions of MythTV<br>
> ago now.<br>
><br>
> I have put an updated version of cross-eit.py (v2.1) with this change<br>
> on my web server:<br>
><br>
> <a href="http://www.jsw.gen.nz/mythtv/cross-eit.py" rel="noreferrer" target="_blank">http://www.jsw.gen.nz/mythtv/cross-eit.py</a><br>
> _______________________________________________<br>
> mythtv-users mailing list<br>
> <a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
> <a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
> <a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
> MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
<br>
Thanks will give that a try<br>
<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a></blockquote><div><br></div><div>Just curious, do real TV's and set-top-boxes with satellite tuners show the EPG for Channel Four HD on Freesat? </div><div><br></div><div>Klaas.</div><div><br></div><div><br></div></div></div>