[mythtv] Channel Management Ideas and Plans

David Engel david at istwok.net
Tue Apr 16 15:48:47 UTC 2019


On Tue, Apr 16, 2019 at 01:44:20PM +0100, Stuart Auchterlonie wrote:
> 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

I'd consider that funny, and highly trusting that rescanning will
re-use the same chanids.  With what I've proposed, you wouldn't need
to change much and you also wouldn't need to rely on getting the same
chanids.  Instead of "truncate channel", you'd run "update channel set
visible=<value-for-deleted>".

David
-- 
David Engel
david at istwok.net


More information about the mythtv-dev mailing list