[mythtv] Use callsign for scheduling

Bruce Markey bjm at lvcm.com
Thu Apr 15 22:25:40 EDT 2004


Ben Bucksch wrote:
> (quotes rearranged)
> 
> Bruce Markey wrote:
> 
>> This piece of information in the US is the call letters assigned by 
>> the FCC .... callsign
> 
> 
>> the callsign is the field for the unique station identifier assigned 
>> to a broadcaster by regulating authorities.
> 
> 
> US-based, false assumptions again.

Well, no it isn't false assumption. The FCC in the US does
regulate the callsigns assigned to broadcasters. I said nothing
about any other country because I do not live an another country
so I used the US as an example. However, every broadcaster
anywhere is identified by some name, number, acronym, or set of
assigned letters. 

When you tell a friend that a show is on a station, you don't
say "the one with the green background and a globe at an angle
with a line going through it" ;-). Every station has a name that
you know it as, even if it is not assigned by a government
agency. There is something that will fit in a varchar(20) that
tells you who the broadcaster is and that their listings are
associated with this channel. The field in the channel table
that contains the string to identify the broadcaster is the
"callsign" field. That is true even if you had previously
misunderstood and assumed that callsign was merely decoration.
This is a key piece of information that you need to fill in
if your grabber doesn't do it for you. If it's left blank then
myth will have to do what it needs to do to get the job done
which is to use the chanids in it's place.

> I don't think we have something like 
> an authorative, official callsign in Europe, and if so, it's not used by 
> consumers. I certainly don't know them, don't know how to get them, and 
> don't want to see them in display. We are used to freely assign and 
> change the short name (3-5 letters usually) of the station, e.g. "K1" 
> vs. "KABEL", "Pro7" vs. "Pro 7" etc..

There you go. Those are exactly what you need. Fill them as
you see fit.

The chanid field that has always been used in the past but this
is the rowid and must be unique. This is no good for matching
the same broadcaster in two or more channel table entries.
xmltvid is controlled by xmltv. They don't have to match for the
same broadcaster and can't be changed because they are needed
as is by any grabber that uses it.

However, "callsign" is not required or checked by the grabber
and is not required to be unique by the schema. Therefore, you
are free to edit this field as you see fit. However, know that
this field is not just decoration but the field that is used
to determine that two or more channel table entries represent
the same broadcaster. While it is possible to add another
field to serve this purpose, no other field is required as
this one is perfectly suited for the job.

>> For the first point, The way to identify a unique station is to use a 
>> piece of information that that station uses to identify themselves to 
>> the rest of the world.
> 
> 
> You are presenting something as "The way", which is based on false 
> assumptions...

I assume you mean your assumptions about what you assume I'm
assuming even though I was assuming that you weren't going to
assume that I was making false assumptions. What I'm saying
is that if you were to get up from your computer and take a
walk around your neighborhood, you would see lots of people
that have no idea what MythTV is but every single one of them
knows with the "BBC" is!

The problem is that so many people look at the problem of
identifying a station for myth from inside myth and how can
myth figure out that two channels are really the same broadcast
source. However, this isn't a new problem for myth to solve.
Stations identify themselves quite nicely, thank you very much.
Myth merely needs to use the well known information rather
than making up something new or use something made up by a
third party.

> (and additionally goes against good old DB school, BTW).

Crufty and self-righteous, yes, but it doesn't parse as expressing
any cogent thought ;-)

> In fact, mixing data from this source with data from another source 
>> would break channel matching. Switching from the regular grabber to 
>> this source would also break the existing record rules.
> 
> 
> Agreed. You seem to generally agree on the DB stability argument, good. 

Yay! Let's shake on it.

> If you consider that the callsign may indeed change arbitarily on this 
> side of the world, it should follow that you can't use that either.

No, I don't understand that premise. Who is making you change
what you have entered into the callsign field of your channel
table? And when this unseen force does this to you, is it really
still the same station showing more episodes of the same shows?
In my experience, when the name of a station changes it is because
it has changed ownership or format so is it really the same station?
And, if there was another field in the channel table to use a contrived
number or something to identify a station, wouldn't it also suffer
if the station identification/ownership/format changed?

>> For any suggesting that there should be a integer that myth creates to 
>> identify a broadcaster, this would be just an extra indirection that 
>> serves no new purpose.
> 
> 
> I hope I showed that it does serve a purpose.

Nope =). In fact, you betrayed yourself in your previous post
when you posted a URL of your xmltvid's in an attempt to show
that these could be trusted to be unique. The page had two
columns, the ID and the Name that everyone knows the stations
as. It is these names that you should put in the callsign field.
If "Pro 7" is on a terrestrial channel as 576 line PAL at 50Hz and
you also get "Pro 7" from DVB (possibly anamorphic?) myth will
know that these share the same listings and the scheduler can
record your favorite Pro 7 show from either input.

--  bjm



More information about the mythtv-dev mailing list