<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 9 May 2021 at 11:16 PM, Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am working on the Python 3 version of mhegepgsnoop, and I have come<br>
up with a small problem with the channel table.  In v31, the channel<br>
table has a new column "deleted".  When the "deleted" value for a<br>
channel is not NULL, it is a timestamp of when the channel was deleted<br>
from your list of channels by a channel scan.  The channel remains in<br>
the database, but marked as deleted, until there are no more<br>
recordings in the recordings table that match that channel.  This<br>
allows the recordings matching a deleted channel to be displayed<br>
properly with their correct channel data, even after the channel is<br>
long gone.<br>
<br>
When mhegepgsnoop looks up the database to get the channels it is<br>
trying to match to, it currently does not know about the "deleted"<br>
column and will therefore try to match MHEG-5 EPG channel names to<br>
channels that no longer exist.  If the name for a deleted channel<br>
matches better than the name of an existing channel, it will mismatch<br>
the EPG data to the deleted channel.  So what I would like to be able<br>
to do is to get mhegepgsnoop to ignore all channels it reads from the<br>
database which have a non-NULL "deleted" value.  But if there are<br>
still people out there using mhegepgsnoop who have not yet upgraded to<br>
MythTV v31 or above, I will need to do some extra code that checks to<br>
see if the "deleted" column even exists, before checking its value.<br>
This is likely a nasty hack type bit of code, which I would prefer to<br>
avoid if it is not needed.<br>
<br>
So is there anyone out there who is running mhegepgsnoop.py and has<br>
yet to upgrade to v31 or later?<br>
<br>
_______________________________________________<br>
mythtvnz mailing list<br>
<a href="mailto:mythtvnz@lists.ourshack.com" target="_blank">mythtvnz@lists.ourshack.com</a><br>
<a href="https://lists.ourshack.com/mailman/listinfo/mythtvnz" rel="noreferrer" target="_blank">https://lists.ourshack.com/mailman/listinfo/mythtvnz</a><br>
Archives <a href="http://www.gossamer-threads.com/lists/mythtv/mythtvnz/" rel="noreferrer" target="_blank">http://www.gossamer-threads.com/lists/mythtv/mythtvnz/</a><br>
</blockquote></div></div><div dir="auto">Could you just guard the SQL queries in the code to check for the presence of the new column, and then support both schema versions?</div><div dir="auto"><br></div><div dir="auto">A-la: <div><a href="https://stackoverflow.com/a/19377091">https://stackoverflow.com/a/19377091</a></div><div dir="auto"><br></div><div dir="auto">Cheers </div><div dir="auto">Jono</div><div dir="auto"><br></div></div><div dir="auto"><br></div>