[mythtv] Preparing for 0.8

[Bruce Markey]

Isaac Richards wrote:
...
> Can you see if current CVS is any better?  I think it's fixed, at least, it 
> just correctly used 3 cards to fix a 3-way conflict, instead of bouncing one 
> of the recordings back to the first card..

Verified. I added another system and it scheduled all four
inputs for sourceid 1.

Around Your Home        14 1014 "Sun Mar 9 06:00:00 2003" 1 1 1 -- 1 1 0
The Beverly Hillbillies 16 1016 "Sun Mar 9 06:00:00 2003" 1 2 2 -- 1 1 0
Tiny Toon Adventures    23 1023 "Sun Mar 9 06:00:00 2003" 1 3 3 -- 1 1 0
Destination Outdoors    31 1031 "Sun Mar 9 06:00:00 2003" 1 4 4 -- 1 1 0

I assume then that this should work for N tuners.

>>>It'd also be nice to modify the code that selects a free recorder to
>>>prefer a local backend over a remote one.
>>
>>That would be a good thing for performance. Also, currently
>>a local ringbuffer is treated as a remote file transfer which
>>impairs performance (uncomment cerr << payload in util.cpp to
>>see this). This crept in a few weeks ago. Both of these would
>>be good to fix but I don't think either of these are 'stop
>>ship' bugs.
> 
> 
> Local ringbuffer treated as a remote file transfer?  For live tv, 
> or something else?

Live TV with the frontend on the same box as the master
backend and tuner. Requests for blocks go over the socket
to the backend. I thought it used to read the ringbuffer
directly as a local file for playback but I must have been
mistaken.

--  bjm