[mythtv] Use callsign for scheduling

[Bruce Markey]

David Engel wrote:
> 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. :)

I was sitting back watching you sweating it out trying to play
"good cop" (what a nice guy BTW) until it was time to swoop in
and play bad cop. Once everyone is pissed at me, your word will
be golden ;-). Seriously, I would have chimed in yesterday
but I was working Robert's bug.

>>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.

I agree that this should be cleaned up. Exactly what got stuffed
into the name field has actually changed over time and I agree
that allowing the user to configure what they want to see in the
GUI makes more sense.

>>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.

Care to guess the maximum number of usec difference that would
make in a scheduler run? I'm not sure database efficiency can
be used as a rational for another layer if indirection (there
is LOTS of real low hanging fruit in the current transaction
that would make a much bigger difference).

My point is and has been that there already are unique IDs
for stations. We don't need to add a different contrived field,
just use the existing field intended for the unique station ID.

>>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.

Well, I didn't say it was perfect. The biggest shortcoming
right now is the lack of an obvious way to set a single
overlap. Yes, I know to go to the priorities page, set the
recurring rule to single, get a proglist and set the single,
then back to the priorities list to change the original
rule back from single to the recurring type. I've always
believed that editing a showing for a recurring title and
changing the type to 1 should simply write out a new recordid
and that's that. However, I've never understood the configuration
group stuff enough to do this simple task. I'd be perfectly
happy with your single override idea if it would allow setting
custom attributes for a single showing (even though I don't
believe a single needs any association with a recurring rule).

I think SchedMoveHigher works pretty well in the few cases
where it actually come up for me. The only obvious down side
is that the card sort may not always be right. I think a
"TryEvenHarder" would have to assume that 'I ran and things
didn't fit in this time slot so I'll Later this showing, clear
the reclist and start priority placement from the top again'.
Even then there is the possibility that a show has conflict
at each showing and the second run may be worse than the first.

Even though you can see SMH flaws if you know what to look for,
it's so much smarter than before. The other thing that has
really impressed me is how well Input preference works. I have
card 1 and 2 at +1 and 3, 4, and 5 at 0. This aggressively
fills card 2 because it has the same preference as 1 and
can more aggressively avoid the later cards because shows can
move to 1 or 2(!). This also adds to filling 2 which helps
balance my disk usage. All the higher cards are avoided unless
they are really needed. This is all exactly what I would try
to do by hand before the new scheduler. It now automatically
does things that I would have wanted but I would have never
spotted if I was just looking at the schedule.

--  bjm