Mailing List Archive

Is anyone still using MythTV v30 or below?
I am working on the Python 3 version of mhegepgsnoop, and I have come
up with a small problem with the channel table. In v31, the channel
table has a new column "deleted". When the "deleted" value for a
channel is not NULL, it is a timestamp of when the channel was deleted
from your list of channels by a channel scan. The channel remains in
the database, but marked as deleted, until there are no more
recordings in the recordings table that match that channel. This
allows the recordings matching a deleted channel to be displayed
properly with their correct channel data, even after the channel is
long gone.

When mhegepgsnoop looks up the database to get the channels it is
trying to match to, it currently does not know about the "deleted"
column and will therefore try to match MHEG-5 EPG channel names to
channels that no longer exist. If the name for a deleted channel
matches better than the name of an existing channel, it will mismatch
the EPG data to the deleted channel. So what I would like to be able
to do is to get mhegepgsnoop to ignore all channels it reads from the
database which have a non-NULL "deleted" value. But if there are
still people out there using mhegepgsnoop who have not yet upgraded to
MythTV v31 or above, I will need to do some extra code that checks to
see if the "deleted" column even exists, before checking its value.
This is likely a nasty hack type bit of code, which I would prefer to
avoid if it is not needed.

So is there anyone out there who is running mhegepgsnoop.py and has
yet to upgrade to v31 or later?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Is anyone still using MythTV v30 or below? [ In reply to ]
On Sun, 9 May 2021 at 11:16 PM, Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> I am working on the Python 3 version of mhegepgsnoop, and I have come
> up with a small problem with the channel table. In v31, the channel
> table has a new column "deleted". When the "deleted" value for a
> channel is not NULL, it is a timestamp of when the channel was deleted
> from your list of channels by a channel scan. The channel remains in
> the database, but marked as deleted, until there are no more
> recordings in the recordings table that match that channel. This
> allows the recordings matching a deleted channel to be displayed
> properly with their correct channel data, even after the channel is
> long gone.
>
> When mhegepgsnoop looks up the database to get the channels it is
> trying to match to, it currently does not know about the "deleted"
> column and will therefore try to match MHEG-5 EPG channel names to
> channels that no longer exist. If the name for a deleted channel
> matches better than the name of an existing channel, it will mismatch
> the EPG data to the deleted channel. So what I would like to be able
> to do is to get mhegepgsnoop to ignore all channels it reads from the
> database which have a non-NULL "deleted" value. But if there are
> still people out there using mhegepgsnoop who have not yet upgraded to
> MythTV v31 or above, I will need to do some extra code that checks to
> see if the "deleted" column even exists, before checking its value.
> This is likely a nasty hack type bit of code, which I would prefer to
> avoid if it is not needed.
>
> So is there anyone out there who is running mhegepgsnoop.py and has
> yet to upgrade to v31 or later?
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>
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?

A-la:
https://stackoverflow.com/a/19377091

Cheers
Jono
Re: Is anyone still using MythTV v30 or below? [ In reply to ]
On Mon, 10 May 2021 07:34:02 +1200, you wrote:

>On Sun, 9 May 2021 at 11:16 PM, Stephen Worthington <
>stephen_agent@jsw.gen.nz> wrote:
>
>> I am working on the Python 3 version of mhegepgsnoop, and I have come
>> up with a small problem with the channel table. In v31, the channel
>> table has a new column "deleted". When the "deleted" value for a
>> channel is not NULL, it is a timestamp of when the channel was deleted
>> from your list of channels by a channel scan. The channel remains in
>> the database, but marked as deleted, until there are no more
>> recordings in the recordings table that match that channel. This
>> allows the recordings matching a deleted channel to be displayed
>> properly with their correct channel data, even after the channel is
>> long gone.
>>
>> When mhegepgsnoop looks up the database to get the channels it is
>> trying to match to, it currently does not know about the "deleted"
>> column and will therefore try to match MHEG-5 EPG channel names to
>> channels that no longer exist. If the name for a deleted channel
>> matches better than the name of an existing channel, it will mismatch
>> the EPG data to the deleted channel. So what I would like to be able
>> to do is to get mhegepgsnoop to ignore all channels it reads from the
>> database which have a non-NULL "deleted" value. But if there are
>> still people out there using mhegepgsnoop who have not yet upgraded to
>> MythTV v31 or above, I will need to do some extra code that checks to
>> see if the "deleted" column even exists, before checking its value.
>> This is likely a nasty hack type bit of code, which I would prefer to
>> avoid if it is not needed.
>>
>> So is there anyone out there who is running mhegepgsnoop.py and has
>> yet to upgrade to v31 or later?

>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?
>
>A-la:
>https://stackoverflow.com/a/19377091
>
>Cheers
>Jono

The user that has access to the mythconverg database does not normally
have access to the mysql database where the information_schema table
is. So that particular method will not work. The hack I am currently
thinking of that should work (yet to be tried), is to do a "desc
channels" query to see if the "deleted" column exists. I then have to
parse the output, and do two versions of the code, one for using the
Python bindings (-p option) and one using a mysql command line query.

Do I take it then that you are still using an earlier MythTV version
and would like me have mhegepgsnoop compatible with it?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Is anyone still using MythTV v30 or below? [ In reply to ]
On 10/05/2021 at 3:31:37 PM, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

>
> Do I take it then that you are still using an earlier MythTV version
> and would like me have mhegepgsnoop compatible with it?
>

>
Nope, I’m not using MythTV in anger here currently. My comment was more
general in nature - I spend a fair amount of my work life figuring out how
to be backwards compatible with breaking changes in APIs and DB schemas, so
thought I’d share a pattern that I’ve seen be used successfully.