[mythtv] Use callsign for scheduling
quintesse at palacio-cristal.com
Sat Apr 17 17:50:13 EDT 2004
Bruce Markey wrote:
> 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.
Aha, the "problem" here then is the fact that some grabbers fill tis
field with "long" names, her in The Netherlands for example it gets
filled with things like "The Cartoon Network", "National Geographic
Channel", which are way too long. It also isn't the field that gets
shown in the program guide but the callsign is so I think lots of people
here "fixed" the callsign so it would fit better in the program guide
(and similar screens with little space for the name).
>> 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.
Agreed, if the callsign was always supposed to have been a non-display
field it should remain that way but it should then also be removed from
the GUI and be replaced by something else. I still don't know if the
name field would be the right choice though because obviously some
grabbers fill it with names which are too long for display purposes in
tight spaces. So either we make sure that the name is displayed
everywhere instead of the callsign or we add a new field called shortname.
>>> 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.
Yes, makes perfect sense, but you can see the gist of my suggestion
stays the same: we may need another field in the channel table. You
might still want a short name for the program guide and a longer name
for the places that have room for a more descriptive name (which I
thought the name field was for).
>> 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 callsign.
> 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
Please read carefully, I'm talking about name CHANGES. You yourself said
that you should avoid making changes to the name, and I'm ginving you an
example why people would maybe have a reason to change it. But that
still had to do with the fact that the callsign was also a display field
(as it is used now in some places!). If we can just make sure that the
callsign is not used as a display field I agree that there is no reason
to care much about its value.
>> 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.
Exactly, the confusion probably arises as well becuase there are
obviously grabbers out there who don't care about the callsign (I think
the Dutch grabbers leave the field pretty much alone).
>>> 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
Yes, there was absolutely a misunderstanding on my part about the
function of the callsign field, but that doesn't change the fact that
it's meaning is currently being "overloaded" because it's also used as a
displayfield. It isn't a show-stopping issue anyway but we might want to
make sure that there is an alternative for using it as a display field
>>> 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.
For The Netherlands I doubt it because I've actually seen some of the
"official" sources of programming data and the only unique
id/callsign-like piece a data they contain is some kind of database id
they use internally. The only thing that comes close is what gets stored
as the xmltvid, unfortunately that depend on the source of the data and
is not guaranteed to stay the same (just guaranteed to be unique within
one batch of data). Anyway, the Dutch channel list has to be edited
manually anyway so making sure this field gets useful values want be too
much work (good documentation of what the field does might be useful
> 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
Sloppyness that caused a lot of confusion and I'm sorry you had to
explain this so many times, hopefully these discussions will have made
it clear for everyone now.
Just one last thing, will making sure that the callsign won't be used as
a display field anymore be made part of the coming(current?) changes? Or
will you expect others to pick that up?
> -- bjm
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev