[mythtv] Proposed scheduler patch [PATCH]

[Steve Davies]

Steve Davies wrote:

> David Engel wrote:
>>
>> Steve, I've finally started my next set of changes working from your
>> patch.  One incorrect thing I've already noticed is that
>> recordoverrides don't work well with xmltvid because they look for an
>> exact match on chanid.  While I coninue to work on other things, would
>> you mind looking into the recordoverrides/xmltvid issue and send a new
>> patch for just that part?
>>
>> David
> 
> 
> I'll try to get on to this today.
> 

I just took a look at this. As far as I can tell, we need to leave the 
recordoverride stuff alone until the guidegrids, and perhaps other parts of 
the system are taught about xmltvid uniqueness.

It's hard to put into plain English, but here goes...

The xmltvid code basically allows a showing of a program on a different source 
to be treated as if it is being shown on the same source at a different time 
(clearly this is not the case, but that is how it is treated) The upshot of 
this is that an AllRecording will realise that it has found an 
rsOtherRecording, rather than having the old behaviour of recording both 
showings (because chanid does not match), and a ChannelRecording will 
recognise that it can be scheduled on the other source if needed - This fits 
into the current guidegrid behaviour quite nicely.

The alternative, (and perhaps a better solution for the future) is for the 
program on the second source but the equivalent channel be treated EXACTLY the 
same as the channel on the primary source. This has a problem that if "R" is 
pressed on the first source in the grid, but the scheduler schedules it on the 
second source, there will be no indication in the grid under the cursor that 
any action has taken place. I think that before this can work, some underlying 
code needs to know how to collapse equivalent channels into a single 
representation of that channel.

Additionally, being able to set a recordoverride for each of the sourceid's 
(hence chanid's) separately means that a recording can be forced to a 
particular source quite nicely.

Perhaps there is a specific scenario that is broken for you with the code as 
it stands? If so, let me know and I'll get right on it.

It sounds like Bruce is happy to critique the result, so we'll soon know if it 
is acceptable ;-)

Regards,
Steve
-- 
Steve Davies                   steve at one47.co.uk

PGP Fingerprints:
DH/DSS : 5D85 8164 91D7 E9CC 4F80  842B AB86 93D9 8938 7612
RSA    :      4E2E E60F 3D76 9E7E  70F9 901B 70FA 56C8
RSA4096: 02BE 5C0E EFA2 E1E4 EA89  C9CC 1E4F F654 3BC7 B65E