[mythtv] Channel Management Ideas and Plans

[David Engel]

On Mon, Jan 28, 2019 at 04:09:03PM +1300, Stephen Worthington wrote:
> On Sun, 27 Jan 2019 15:09:39 -0600, you wrote:
> 
> [snip]
> 
> An additional complication that you may not have thought about - when
> a channel changes its identity (station name, callsign, icon),
> obviously the recording rules for that callsign need to be updated
> also.  But if you are using "power" recording rules, there will often
> be SQL stored in the recording rule that will contain a reference to
> the callsign and/or the chanid.  It would be good if those rules could
> at least be flagged for manual fixing, even if an automated fix was
> not possible.

I had thought of it but didn't get put into my notes which is why I
forgot to bring it up.  Thanks for reminding me.  Yes, "this channel"
recording rules should be updated automatically.  I don't it would be
wise to automatically update power rules too.  Did you see my addendum
for system messages?  One of the reasons for that is to inform the
user of such changes and indirectly remind them to take care of
anything that needs to be done manually.

> In this part of the world, channels are assigned XMLTV IDs by the EPG
> grabbing software that creates the xmltv data.  Those names are
> normally made from the channel name found when scanning for channels.
> When the station identity changes, those names also need to be changed
> if you are trying to keep things consistent.
> 
> Here are the current XMLTV IDs I am using for our free-to-air
> channels:
> 
> tv1.freeviewnz.tv
> tv2.freeviewnz.tv
> tv3.freeviewnz.tv
> bravo.freeviewnz.tv
> maori-tv.freeviewnz.tv
> tv1-plus1.freeviewnz.tv
> tv2-plus1.freeviewnz.tv
> tv3-plus1.freeviewnz.tv
> bravo-plus1.freeviewnz.tv
> duke.freeviewnz.tv
> edge-tv.freeviewnz.tv
> prime.freeviewnz.tv
> choice.freeviewnz.tv
> hgtv.freeviewnz.tv
> parliament.freeviewnz.tv
> hope-channel.freeviewnz.tv
> aljazeera.freeviewnz.tv
> te-reo.freeviewnz.tv
> firstlight.freeviewnz.tv
> tvsn-shopping-channel.freeviewnz.tv
> chinese-tv8.freeviewnz.tv
> tv29.freeviewnz.tv
> tv33.freeviewnz.tv
> apna.freeviewnz.tv
> rnz-national.freeviewnz.tv
> rnz-concert.freeviewnz.tv
> basefm.freeviewnz.tv
> threelife.freeviewnz.tv
> 
> and here are a few channels from our pay-TV satellite provider:
> 
> cnbc.sky.co.nz
> cnn.sky.co.nz
> comedy-central.sky.co.nz
> concert-fm.radio.sky.co.nz
> country.music.sky.co.nz
> countrytv.sky.co.nz
> crime-investigation.sky.co.nz
> 
> Another way I have thought about for keeping old channel data
> available is to simply create an "oldchannel" table.  No longer
> available channels would be moved from "channel" to "oldchannel".
> Occasionally, housekeeping could be done to scan the recordings tables
> and check if there are any channels in "oldchannel" that no longer
> have matching recordings, and then delete those channels from
> "oldchannel".  That could be done by an external script, as is done
> with find_orphans.py.  Or it could be added to find_orphans.py.  Using
> an oldchannel table greatly reduces the redundant data that might
> otherwise need to be stored in the "recorded" table and allows all of
> the old data for a channel to be kept.  But it complicates the use of
> chanid values as they are now a primary key on two tables and need to
> be unique over both tables.

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.

First, as you noted, channels can change over time.  Sometimes, they
change quite dramatically.  I think Watch Recordings and Previously
Recorded should show the channel information as it was at the time of
recording.  For example, I want my Hee Haw recordings to show as being
on The Nashville Network, not The National Network, not Spike TV and
not Paramount.  We would need to add a time component, probably
starttime, to the table to prevent it from being changed by later
channel updates.

Second, the oldrecorded table is quite the different beast from the
recorded table.  I don't see a new recordedchannel table being a good
fit for the oldrecorded table.  oldrecorded has *a lot* more entries
and I don't see extra, time-accurate, channel information being as
important for oldrecorded as it is for recorded.  Perhaps recorded and
oldrecorded should have different solutions.  Option 3 for recorded
and option 1 for oldrecorded.

David
-- 
David Engel
david at istwok.net