[mythtv] [PATCH] Use callsign for scheduling

[Brian May]

>>>>> "David" == David Engel <gigem at comcast.net> writes:

    David> Well, the scheduler has been using callsign, in addition to chanid,
    David> since the big overhaul 6 weeks ago.  The intention to switch to just
    David> callsign has been discussed intermittently since then.  Some of the
    David> reasons for doing this are:

Can I take it that the long term intention is to remove the chanid
field? Or will it be kept as a unique ID?

    David> Cleaner, simpler code -- fewer bugs?

I will take your word for it ;-)

    David> More flexibility -- some people have the same station/network on
    David> multiple sources (cable, satellite) or even on the same videosource
    David> (analog, digital).

This seems to imply that you will be able to have several channels
setup to use the same callsign. In which case, MythTV needs to decide
which one to use.

(It would seem that this is where MythTV could do with more work,
eg. I would like to be able to tell MythTV to prefer HD DVB, then SD
DVB, then analog, in that order. It isn't quite that simple though, as
some HD channels (at least here) are experimental, and only broadcast
limited shows.)

    David> More friendly to stations changing channels -- it doesn't happen
    David> frequently, but it does happen, at least on U.S. cable.

This reason seems flawed; The unique identifier was (and AFAIK still
is) the chanid, if the station changes channels surely it simply be a
matter of updating the channel in the existing table, and leave chanid
the same?

    David> I don't remember where the screen is, perhaps in the setup
    David> program, but you have the ability to edit the callsigns
    David> yourself and make them meaningful.  That's partly why
    David> callsign was chosen instead of creating a new field that
    David> would be hidden from view.

If I edit the callsign though, what references am I going to break
with other tables are going to break?

My interpretation based on my current understanding:

I think I can see the reason for the change now, the issue with the
previous system is that it ties recordings to a specific
{source,station}, but you only want (and need) to tie it to a specific
{station}.

A complication in the above, if I understand correctly, each channel
can have its own callsign, and each channel can have its own xmltvid.
Are there any checks to ensure that two channels with the same
callsign must have the same xmltvid? Having two channels with the same
callsign but different TV guides would appear to be invalid. Probably
any two channels with the same xmltvid should also have the same
callsign too (but this may not be as bad)?

It would seem that there are two concepts that you are trying to fit
into one table, a channel (unique reference to a particular tuning on
a particular source), and a station (broadcasts shows according to a
schedule using a number of different technologies)[1].

Have you considered splitting them up into two? eg.

channel
-------
chanid  channum  ...  stationid ... 
12000   9             100
12001   7             101
12002   99            100

station
-------
stationid  callsign  xmltvid
100        NINE      C9.au.tv.yahoo.com
101        SEVEN     C7.au.tv.yahoo.com

This would mean that all information related to a "station" is pulled
out of the "channel" table and no longer duplicated. So there is only
one place to edit "callsign" and "xmltvid". I only have two fields
here, possibly there could/should be others. Another possible field
might be priority, so I can give "NINE" lowest priority on all
channels, for example (not very important in Australia, might be
useful for other countries with more stations).

The scheduler would use "stationid" instead of "chanid" to uniquely
refer to the station instead of the channel, so you get the benefits
of referring to the callsign without the disadvantages.

A possible compromise would be to use "callsign" instead of
"stationid", I won't dispute this issue, but tend to feel it is safer
using IDs for internal use only, so it is possible to change the
displayed ID without breaking references.

Anyway, just my thoughts at the present time...

I hope I have explained this in a clear manner, if not please ask for
clarification where required.

Notes:

[1] these definitions could use some fine tuning; for instance,
currently a single channel can represent both digital and analog
reception.
-- 
Brian May <bam at snoopy.apana.org.au>