[mythtv-users] channel musical chairs

[Stephen Worthington]

On Sat, 18 Nov 2023 16:11:17 -0800, you wrote:

>Even though the big repacking is done, it seems channels just can't
>sit still.  I've written a program to deal with it, but am now getting
>nervous about using it.  I'm in the US, get signals OTA via HDHomeRun,
>and use Schedules Direct.
>
>For example, virtual channel 4.1 changed frequency and program #.  I
>was going to go in and update the associated mplexid and program # in
>the channel table.
>
>All subchannels for 4 used to be on the same frequency, I think, but
>now they aren't.  Some of them have changed callsign as well.
>
>44.5 has disappeared entirely.
>
>I'm concerned about how this will interact with
>1. SchedulesDirect: do I need a new xmltvid for the new channel?  Is
>that automatically updated from SD, or do I need to do something?
>2. Existing Recordings: If I delete a virtual channel, like 44.5, or
>change the callsign I assume the old recordings will either have
>nowhere to point for the channel or will have the wrong idea about the
>callsign (and icon) of the station.
>Since I create a new channel id to reflect the new configuration, and
>leave the old one in place.  E.g., 4.3 in my channel table points to
>the old frequency and callsign and has chanid 10403,  Should I leave
>that as is, and created an entry with chanid (e.g.) 20403 for the new
>configuration?

Virtual channels are simply channels - there is no difference between
main channels and virtual channels except the name and number.  Each
is just a group of streams of packets broadcast on a multiplex.  In
DVB-T regions, there is no differentiation made - it is just done in
ATSC, probably for political reasons.

There is a fairly recent new feature that keeps old deleted channels
around (marked as deleted) until all the recordings referring to the
channel are deleted.  So after you create a new channel under a new
chanid, use mythtv-setup to "delete" the old channel, which will stop
it from being used for new recordings or the Guide/EPG data, but will
retain it for showing which channel was used for old recordings.  To
see which channels are deleted, use SQL and select on the
channel.deleted field, which is a timestamp or NULL.  Any recordings
before that timestamp match against the deleted channel, any
afterwards match the new channel, so you can have deleted and current
channels with the same callsign and/or xmltvid.  So you can have
multiple deleted channels with the same callsign.  The chanid field is
a unique key so each version of a channel has to have a different
chanid.  This is enforced by MySQL/MariaDB.

>3. Existing Recording Rules: what happens to them?  People have
>reported that, at least for rules that are "record on this channel"
>things may stop working.

When channels change, the recording rules are not updated to match,
unfortunately.  In the record table, there is a field called "station"
which is the callsign used to match against a channel.  When channels
change callsign, you need to manually run SQL to change the matching
record.station fields to the new callsign.  When I do this, I make my
SQL update both the record.chanid and record.station fields, although
I believe the record.chanid field is not actually used for matching
anything.

>Like others I have found rescanning from mythtv-setup to be pretty
>cumbersome; in particular I recall it tends to recreate many channels
>I deliberately deleted.

Yes, some people have written scripts to delete all these channels
again whenever they get re-created.  The script needs to be manually
altered from time to time.  It normally just sets the channel.visible
flag to 0, so the channel will not be re-created on each new scan but
will not be used for anything.  If you do not use a script, it is
better to just set channels to not visible rather than deleting them.

>Virtually every conceivable pattern seems to have occurred: channels
>that weren't there get added; those that were there get dropped; any
>of frequency, program number and call sign change for a given virtual
>channel; and sometimes a given channel/callsign jumps to a different
>virtual channel.

Channel numbers (channel.channum in DVB-S/T and
channel.atsc_major_chan/channel.atsc_minor_chan in ATSC) are not used
for anything except humans to select a channel.  The things that
matter are channel.chanid (which is used internally and not intended
for human use), channel.callsign and channel.xmltvid.  The
channel.name data is not used for matching the EPG data, although I
think it may be used to originally match xmltvid values to channels
when the xmltvids are created.

>Part of the  problem is that what seems like a simple, unitary
>concept, a "channel", actually has many elements, which may not change
>in sync: the major and minor channel number (virtual channel), the
>frequency, the program #, call sign, xmltvid, and chanid as used in
>the channel table (among other places).  One post suggested that for
>purposes of "record this channel only" the sourceid was also part of
>the identifier.

Yes, the channel updating procedure in MythTV is still not capable
enough to handle all these problems.  Since the introduction of
deleted channels it is much better than it was.  But more work is
still needed.

"Record this channel only" will match on the callsign/station values,
so if the same channel (with the same callsign) is available on
multiple sources (eg free-to-air, satellite and cable), then MythTV
will record from any matching channel on any source.  You set channel
priorities to tell which of the matching channels to prefer, so if you
get a channel in HD on FTA, you would give the FTA channel a higher
priority.  If there were insufficient tuners to record from the
highest priority channel, a lower priority one might get used - it
depends on how much higher you set the channel priority compared to
other sources of priority used by the scheduler.

>Thanks for any guidance.
>Ross