[mythtv] Channel Management Ideas and Plans

David Engel david at istwok.net
Mon Jan 28 03:22:15 UTC 2019


On Sun, Jan 27, 2019 at 03:09:39PM -0600, David Engel 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.

Ooh, I forgot one other thing.  I forgot it because it's big enough
feature that I gave it its own Google Keep note.  It's also not
technically a channel managment feature but the inspiration for it
defintely came from here.  This one is definitely in the "when I get
to it" category.  I hope someone else with think it useful enought to
pick up the ball and run with it before then.  Hint, hint, hint! :)

Add System Messages
===================

Thanks to Jean-Yves Avenard's work on notifications some years ago, we
have a way to inform users on all frontends of things that might need
immediate attention.  That includes things like "tuning is taking too
long", a recording is failing" and "the backend is not responding".

There are lots of other things that users should be made aware of but
have to go look for on various other screens and sometimes even log
files.  These include things like "channels were added or deleted"
(inspiration), "a scheduling conflict was created", "recordings were
missed or failed", "mythfilldatabase failed" and "a transcoding job
failed".

There should be some indication on the main menu screen and maybe even
all screens or just all menu screens when new messages are available.
In the messages area, users should be able to delete old messages and
mark new messages as read and also mark read messages as unread again.
In some cases, it would be nice to be able to go straight from the
message screen to another appropriate screen.  For example, if
channels are added, have a link to go to the channel editor.

I've got some more notes for this but you get the idea.  I'll save
them for when/if it's closer to becoming reality.

David
-- 
David Engel
david at istwok.net


More information about the mythtv-dev mailing list