[mythtv] Use callsign for scheduling

David Engel gigem at comcast.net
Thu Apr 15 20:20:20 EDT 2004


On Thu, Apr 15, 2004 at 02:19:37PM -0700, Bruce Markey wrote:
> I've been watching this thread (in horror ;-) for the past
> couple days and I believe there are two mis-understandings
> that lead to much of the confusion:

I was wondering where you were. :)

> the callsign field is supposed to be just for display. This
> is not true. There is a field, 'channel.name' that is for
> display only but the callsign is the field for the unique

I had forgotten about channel.name.  Unfortunately, I think most
screens and themes don't use it.  Also, I didn't like the redundant
(IMO) "Channel" prefix on every name, so I turned anything that may
have used it off.  Perhaps we should remove channel.name from the
database and replace its use with a run-time, configurable value, ala
timeformat and channel ordering.

> 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'm no database expert, nor do I aim to be one, so I don't feel too
strongly on this either way.  However, I can imagine that some
database operations might be more efficient using integers instead of
strings, especially if the keys are set up properly.

> in CVS. Despite dozens of people giving there "expert" ;-)
> opinions during planning, once David posted a patch for testing
> the new scheduler, precisely zero people tried it and sent
> feedback(!). steve at one47.co.uk and I did daily testing, patches

Let's not rehash that, please.  All I will say on this matter is that
if people want to influence the direction Myth takes, they need to be
at least somewhat active on the -dev list.

> I, for one, would like to publicly thank David Engel for his
> hard work, dedication, and sense of reason that lead to a
> system that continues to amaze me. There is logic in this

Gee, I'm almost blushing! :) While I think most people will agree the
new scheduler is an improvement, let's be honest and say that it isn't
perfect.  For example, the MoveSchedHigher logic only makes a modest,
single-pass attempt at moving things around.  A "TryEvenHarder" option
would be useful for some people.

David
-- 
David Engel
gigem at comcast.net


More information about the mythtv-dev mailing list