[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