[mythtv] Channel Management Ideas and Plans

[Stuart Auchterlonie]

On 12/04/2019 21:24, David Engel wrote:
> [Quoting parts of my other emails for more context]
> 
> On Sun, Jan 27, 2019 at 03:09:39PM -0600, David Engel wrote:
>> Remove Some Dependencies on the Channel Table
>> =============================================
>>
>> When program entries are primarily read from the recorded table (Watch
>> Recordings screen) and the oldrecorded table (Previously Recorded
>> screen), they are augmented with data from the channel table.  This is
>> the reason that channel and videosource entries must be kept in the
>> database even after they are no longer being used for new recordings.
>> The intent of the following options is to remove these dependencies on
>> the channel table so that channels and videosources can be deleted as
>> soon as they are no longer used.
>>
>> Option 1.  Add the relevant columns to the other tables.  The recorded
>> table would add channum, callsign and channame(*).  The oldrecorded
>> table would add channum and channame.
>>
>> Option 1a.  The same as option 1 but add the new columns to the
>> recordedprogram table instead of the recorded table.  I prefer plain,
>> option 1 for simplicity and keeping the program and recordedprogram
>> tables with the same columns.
>>
>> Option 2.  Add some new indication in the channel table for "Deleted"
>> channels.  This could work with the cost being more complexity to
>> ignore deleted channels in the appropriate places and deciding when to
>> actually delete an entry or  mark it as deleted.
>>
>> Right now, I prefer option 1 due to its simplicity.  One downside is
>> that other potentially useful data about the channel would be lost
>> when it's deleted.  For example, what if a themer wanted to show the
>> channel icon in Watch Recordings instead of or in addition to the
>> preview image?
>>
>> (*)A couple of other columns from the channel table are pulled in here
>> but I believe they are only relevant immediately after the program was
>> recorded.  Returning NULLs if the channel is deleted much later should
>> not cause a problem.
> 
> On Sun, Jan 27, 2019 at 11:33:45PM -0600, David Engel wrote:
>> I'll consider recordedchannel (aka oldchannel) to be option 3.  We
>> already have a recordedprogram and other recorded* tables for similar
>> uses.  There are two issues I see.
> 
> On Mon, Jan 28, 2019 at 08:25:40PM -0600, David Engel wrote:
>> On Mon, Jan 28, 2019 at 09:54:35AM +0000, Gary Buhrmaster wrote:
>>> First, I philosophically do not like duplicate data
>>> in tables.  One table is the authoritative table, or
>>> there are none (I don't have the ability to check
>>> if that is a direct rule of Codd while I am writing
>>> this, but it certainly is derivable from those rules).
>>>
>>> The right answer for some of these issues is often
>>> what are called effective dated tables (with the
>>> additional of effective sequences for slightly more
>>> complex update scenarios).  That means every row
>>> has a date it starts to be valid.  So (using John's
>>
>> I do just that with a database at work.  However, I think that's
>> overkill for MythTV and "the perfect is the enemy of the good."
>> Still, I will let it percolate for a while as this is not the first
>> part I expect to work ong.
> 
>>> Since you are not likely going to effective date the
>>> tables (you need more than just a few experts on
>>> such things to be able to maintain such codes into
>>> the future), I would expect you will need to copy
>>> the data, and you should want 100% of the
>>> information you will want to present as part of the
>>> (old)recorded be copied.  That would include at
>>> least the channel name, number, channel icon, etc.
>>> since (at least for cable) channel 123 may have
>>> been ABC KABC today, but have been CBS KCBS
>>> last week, and you want the data presented to be
>>> valid for when the show was recorded.
>>
>> For recorded, I'm almost completely in the option 3 camp now.  That is
>> to have a recordedchannel table.  We already have the precedents for
>> recordedprogram, et al and the code to populate and clean them up when
>> needed.
>>
>> For oldrecorded, I'm still undecided.  I personally would be fine with
>> saying that anything beyonhd channem number, name and maybe icon
>> simply aren't there for uses where oldrecorded is the primary table.
> 
> I have about 90% of an option 3 coded and tested.  It creates new,
> recordedchannel (for recordedprogram) and oldchannel (for oldrecorded)
> tables.  The last remaining part has to do with icon handling.
> Becuase the icon path is not part of the Program/RecordingInfo object,
> it is fetched on demand using ChannelUtil::GetIcon() which blindly
> uses the channel table.  It needs to be modified to conditionally use
> channel, recordedchannel or oldchannel as appropriate.
> 

I actually like the sound of this.

Icon's are a bit problematic these days, since lyngsat implemented
linking protection, myth can't automatically download them using the
built in icon downloader.

> I'm about to throw it all out in favor of a new, option 2a.
> 
> The new option adds another, new value to channel.visible for
> "deleted".  Deleted channels are like existing, invisible channels
> with a a few, new exceptions.  They aren't shown in the channel
> editor, aren't popluated with guide data and are deleted from the
> channel table when they are no longer referenced by the
> recordedprogram and oldrecorded tables.
> 

Maybe i update my channels in a funny way ;-)
truncate channel;
truncate eit_cache;
truncate program;
rescan
restart backend


Regards
Stuart