[mythtv] [PATCH] Use callsign for scheduling

David Engel gigem at comcast.net
Thu Apr 15 00:52:22 EDT 2004

On Thu, Apr 15, 2004 at 09:15:27AM +1000, Brian May wrote:
> Can I take it that the long term intention is to remove the chanid
> field? Or will it be kept as a unique ID?

It will probably be removed from the record and recordoverride tables
eventually, but not for a release or two.  If your asking about the
program and channel tables, I don't know.

>     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.

Yes, in fact, Myth already does this.

> (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.)

You can already do this by setting the recpriority for a channel in
Setup/TV Settings/Recording Priorities/Channel Priorities or the
preference for a cardinput in the setup program.

>     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?

I don't know if Myth is or can be that smart.  It falls down because
Myth is at the mercy of whatever xmltv gives it to identify channels.
In my experience, xmltv doesn't provide good enough information to
recognize when a station is moved to another channel or when two (or
more) channels are really 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?

You would have to change the record and recordoverride tables to match
the new callsign.  I'll put it on my todo list to do that if I find
the screen.  It may actually be in mythchannel, in which case, it's
not part of myth proper.

> 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?

No, and in fact, there can't be.  In one example I know of, the same
station has two channels in the same videosource.  One channel is
analog and the other is digital and both have different xmltvids.
This is what I was talking about above about xmltv not providing good
enough information.

> Having two channels with the same
> callsign but different TV guides would appear to be invalid. 

In the strictest sense, yes, this would be somewhat invalid.  However,
it probably wouldn't have adverse effects because other factors such
as title and time are also checked when scheduling a recording.

> 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.

There has been some very light talk of this, but just talk.  I
certainly don't have any immediate plans to do anything.  FWIW, the
zap2it labs Data Direct service (U.S. only) follows the approach you
describe.  Once it gets integrated (this week?), we'll see if someone
picks up the ball and takes the next step.

> 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.

That's why the new fields added to the record and recordoverride
tables wound up being called station instead of callsign so as to not
be confusing when/if this is done.

> 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.

Your thoughts are perfectly clear, and make sense too. :) There's only
so many hours in the day, though, for voluntary, free-time efforts
like Myth, so things have to be done in small steps.  Also remember
that most of the active developers use the CVS code as their
production version so breaking things for any extended period of time
for a big change probably isn't feasible.

That being said, code tends to speak louder than words in open source
projects.  So if you'd like to contribute...  FYI, please take this as
an invitation to help out if you can and not a "fix it yourself if you
don't like it".

David Engel
gigem at comcast.net

More information about the mythtv-dev mailing list