[mythtv] Channel Management Ideas and Plans

[David Engel]

On Sun, Jan 27, 2019 at 06:14:05PM -0500, faginbagin wrote:
> On January 27, 2019 4:09:39 PM EST, David Engel <david at istwok.net> wrote:
> >Here's a brief description of some of the things relating to channel
> >management that I hope to work on.  I'll likely start on some of them
> >soon.  I'll get to the others when/if I get to them.  Please provide
> >comments or other suggestions here.
> >
> >Removal of DataDirect Support
> >=============================
> >
> >This has been discussed many times before and already announced here.
> >The intent is to simplify mythfilldatabase and related functionality
> >by only supporting xmltv.
> >
> >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.
> >
> >Enhance Channel Visibility with New Values
> >==========================================
> >
> >Gary Buhrmaster has a nice script for managing the channel.visible
> >setting for HDHomeRun Prime users(*)(#).  Unfortunately, the script
> >doesn't and can't know things that only the user knows.  Things like
> >"even though I can receive the channel, I don't want it visible" or
> >"the channel isn't receivable right now but I know it will be when I
> >plan to use it".
> >
> >To solve this problem, I intend to extend the meaning of
> >channel.visible from simply no and yes values to also include values
> >for "never" and "always".  Gary's script could then be changed to know
> >not to override those values.
> >
> >(*)I can envision other, similar scripts and even functionality built
> >into MythTV for periodically scanning and validating channel
> >reception.  This change would be useful for them too.
> >
> >(#)Gary also has other scripts that are very useful for MythTV users.
> >In fact, they are part of the inspiration for this series of changes.
> >
> >Better Automated Handling of Channel Additions/Deletions
> >=======================================================
> >
> >Handling of channels additions and deletions in mythfilldatabase has
> >always seemed way more complex to me than needed.  Perhaps that
> >because of the DataDirect complication (see above) or I'm just to
> >naive to understand all of the subtleties.  Either way, I hope to
> >improve on it.
> >
> >Note that I'm primarily concerning myself with the
> >mythfilldatabase/xmltv part of this problem for the time being.  I
> >know I can't totally ignore channel scanning for those tuner types
> >that require it but major changes in the is not something I'm prepared
> >to take on.
> >
> >Anyway, I'm looking to add new settings for each videosource to
> >control channel additions and deletions.  For additions, I'm thinking
> >of a setting with values like "ignore", "add as never visible", "add
> >as invisible", "add as visible" and "add as always visible".  If it's
> >possible to actually check the reception then also have an option for
> >"add as detected".  For deletions, I'm thinking of a setting with
> >values like "ignore", "delete", "mark as invisible" and "mark as
> >never visible".
> >
> >Better Automated Handling of Channel Updates
> >============================================
> >
> >Besides channels getting added and deleted, other channel information
> >like names, callsigns and icons get updated over time.  I don't know
> >if mythfilldatabasse handles any of that or not.  Gary Buhrmaster
> >(surprise), though, has a script for doing much of this, at least for
> >tv_grab_zz_sdjson_sqlite users.  I'd like to see some of that
> >functionality get rolled into MythTV proper.  I don't know if that
> >should be mythfilldatabase, mythutil or an entirely new utility at
> >this point.
> >
> >One complicating factor is deciding how granularly to control the
> >updates -- at the videosource level and/or the individual channel
> >level.  Also, which information to allow updates -- purely cosmetic
> >stuff like name vs. callsign (with scheduling implications) vs. tuning
> >stuff like frequency and multiplex.  Gary's script allows very
> >granular control which is great for me because I need it.  Others
> >probably don't and just makes things more complex for them.
> >
> >David
> 
> Regarding option 1, I assume you aren't suggesting adding callsign to oldrecorded because it already has a station column, which seems to me to be an alias for callsign. Would it make sense to change that column name to callsign to be consistent across the board?

You are correct that oldrecorded already has the station column.
That's why I only listed channum and channame for addition to
oldrecorded.

As for renaming station to callsign, we have generally discouraged
such schema changes as gratuitous in the past.  The reason is to make
it easier to compare and move data between older and newer schema
versions.  The developer who was most vocal about that policy is long,
long, long, gone, though.  If the other, current developers want to
revisit that policy, we can.

David
-- 
David Engel
david at istwok.net