[mythtv] Use callsign for scheduling
bjm at lvcm.com
Sat Apr 17 15:52:45 EDT 2004
Tako Schotanus wrote:
> Bruce Markey wrote:
>> Tako Schotanus wrote:
>>> But what if you want to change that callsign later on? Reasons might be
>>> as simple as wanting to change "BBC1" to "BBC 1" or because a channel
>>> decides to change their name. Will a change like that somehow mess up
>>> the system? Or will it just continue to work?
>> Astute question. For any record rules that specify a station
>> (Single, Timeslot, Weekslot and Channel) that were created for
>> "BBC1" they would not match a channel with "BBC 1". FindOne and
>> All would not be affected. You would need to add new record
>> rules and could remove the old record rules on the Recording
>> Priorities page.
>> This has always been a problem in another form and while this
>> is a step backward, there are at least two steps forward.
> Ok, but this is something which could easily be rectified by having a
> seperate "short display name" and callsign, wouldn't it?
mysql> describe channel;
| Field | Type | Null | Key | Default | Extra |
| chanid | int(10) unsigned | | PRI | 0 | |
| channum | varchar(5) | | | | |
| sourceid | int(10) unsigned | YES | | NULL | |
| callsign | varchar(20) | | | | |
| name | varchar(20) | YES | | NULL | |
| icon | varchar(255) | YES | | NULL | |
| finetune | int(11) | YES | | NULL | |
There is and always has been a separate short display name. This
could be left empty (NULL) because it is only for decoration. The
callsign may not be NULL because this is the field to identify
who the broadcaster is. See David Engel's post about how we should
maybe make some changes to how and what the GUI displays.
> Or just keep
> the curent callsign for display purposes like it is used now and
> introduce a new "stationid".
This is the key mis-understanding that I'd mentioned earlier. I
presume that your grabber did not fill in the callsign for you.
I guess for anyone who does not see these filled in it must be
obvious to assume that this column is trivial and decorative
because at least three people in this thread have done so.
Several grabbers do fill this in with unambiguous data and this
already is the field for defining which broadcaster is associated
with a channel entry. To say that this field should not be used
for that purpose is either uninformed or insensitive to those
who have grabbers that use this field correctly.
If the question is about how the GUI displays things then the
solution lies in fixing the GUI.
>> So, no, you don't want to go around making little changes if
>> you don't have to.
> Hmm this seems to be even more reason to add a seperate callsign and
> stationid, display names should have _no_ effect on the workings of the
> system whatsoever IMO. You could even make them exactly the same while
> setting it up so people don't have to do even more tweaking.
It already is this way but the stumbling block is simply a mis-
understanding about the field names and purposes. If you see
channel.callsign as what you are thinking of as stationid and
channel.name as the decorative name, then it should make sense.
> One of the reasons why we might be more inclinded to make name changes
> than US-users is the fact that lots of channels here don't _have_ a
> callsign. And I'm not talking about official ones, they don't even have
> unofficial ones. I heard it said before that wherever they went in the
> world there was always something, eg. BBC1, BBC2, MTV whatever. But here
> in The Netherlands there certainly are channels which have no known
Hasn't this been rehashed enough times already? There is no
ominous, hard issue of being required to find a worthy official
designation if your grabber didn't provide one. What ever you'd
like to to call a station is fine. As long as it 1) lets you know
who the broadcaster is 2) fits in a varchar(20) and 3) makes you
> If I would say that I was going to watch TCN nobody here would
> know that I was going to watch The Cartoon Network,
FYI, nor would anyone here. It is TOON and shifted for the Pacific
timezone it is TOONP. However, if someone was talking to a friend
they'd say "Cartoon Network".
> the same for The
> Discovery Channel (people might just call it "Discovery"), National
> Geographic and maybe even some others. Of course I could make up a
> callsign, or just use something that fits in 20 characters no problem
> here. The problem for me is more that I might be _very_ inclinded to
> make changes to these names. Some names are just too long so they mess
> up the displays in the programming guide so I might at some point decide
> to abbreviate them somehow (Hmm Discovery doesn't fit... damn Discovry
> doesn't either, finally Discvry does). Even if you will hardly have to
> do this very often the point is that I would expect to be able to change
> it without having to worry about side-effects.
Well the same issues exists no matter what characters are used
in the name of the column for the channel table. What you may
not have been aware of is that for other grabbers, "callsign" has
always been what you are now starting to think of as "stationid".
So I think the real issue is how the GUI uses the broadcaster
designation (callsign) and the displayable name (channel.name).
I think that for most people who worked on these parts of the
code, the broadcaster designation was exactly what they'd like
to see so maybe callsign is used in places that a cosmetic
display field should be used instead.
>> Any change that breaks record rules is a bad thing. For the
>> environment that I'm in, not using the chanid is a big step
>> forward. I could change cable providers, switch to satellite,
>> the provider could change the channel they use for a station
>> or I might need to change my video source for some other reason.
>> Any of these would break chanid but "KVBC" will be "KVBC" until
>> they go out of business.
> I understand the need for this change perfectly, the only thing I would
> suggest is to take a look again at "overloading" the meaning/use of the
> callsign field.
The "meaning" of the callsign field has always been to designate
the broadcaster. If you were unaware that several grabbers
already fill this in with unambiguous data, that may explain your
>> If myth was using callsigns for record rules at the time, I
>> don't know if I'd change the callsign but I think I would.
>> Realize that if a station was flaky about changing their
>> name you would not be compelled to keep up. You could give
>> it a generic name that you are happy with and stick to it.
> Again, I don't expect a system to adjust itself to whatever flakey
> broadcaster in the world (although in my example I was talking about one
> of the larger commercial ones, so not some tiny local station) thinks of
> because arguably this will happen only in very rare circumstances, but
> that's why I suggested to just keep the callsign as-is and introduce a
> seperate stationid, it will prevent the overloading of the callsign
> field and all this won't be a problem.
> But maybe there is a very good reason for using the callsign for this?
Yes. As I've mentioned earlier in this post and in previous
posts is that grabbers other than yours already use the callsign
in exactly the way you are thinking of for stationid.
There needs to be a column to identify which broadcaster is
associated with a channel. Twenty characters ought to be enough
and it should be a string field so that it can hold letter or
numbers. It shouldn't be NULL and it can't be required to be
unique since they should sometimes match. The user should be
able to edit the field to appear as they'd like and to force a
match or prevent a match. And, it would be nice if someone else
would fill it in initially so that you don't have to do it your-
Your grabber falls short on this last point and maybe you should
check with the XMLTV project to see if they might be able to get
something from the source where the data is grabbed for the sake
of other who will be using the same grabber as you. Xmltv doesn't
always give you everything that is available that you might need.
For example, zap2it has nifty program and episode identifiers on
their pages that would be very useful for myth but xmltv does not
include these. But that's another topic.
Since you need to fill in a column yourself, it doesn't matter
to you if you type into "stationid" or "callsign" or "foobar".
However, "callsign" is already the field that meets all the
criteria above including the fact that it is filled in for many
people. Because these were not filled in for you, you may have
seen this field as being primarily for display and identification
was incidental. This is not true. The primarily function of this
field is identification and it's use in display is, well, maybe
More information about the mythtv-dev