[mythtv] Preparing for 0.8

[Isaac Richards]

On Saturday 08 March 2003 07:25 pm, Bruce Markey wrote:
> I spent some frustrating time yesterday trying to grok the
> scheduler.cpp code. It certainly iterates through all the
> inputs per sourceid. However, it seems to only "secondmove"
> to move conflicts from the first input to the second input
> in DoMultiCard(). I don't see how it should iterate moving
> conflicts from the second to the third, third to fourth, etc.
> I would be a shame if multi-backends could still only schedule
> two recordings so I'd appreciate any help to resolve this
> issue this week.

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

> > 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?  Watching live's always been a "remote" operation, in that the data 
goes through the network code (mainly since I haven't wanted to write the 
code necessary to share the ringbuffer object in ram between the two 
processes yet, planning on that post 0.8 sometime).  Or did you mean 
something else and I'm way off base? =)

Isaac