[mythtv] backend from SVN 9761 bangs on mysqld

[Daniel Kristjansson]

On Mon, 2006-04-24 at 19:24 +0200, Janne Grunau wrote:
> On Monday 24 April 2006 18:25, Daniel Kristjansson wrote:
> > That sounds reasonable. Are you sharing the cache or just
> > making sure the channel scaned on each backend don't overlap?
> Sharing the cache would be insane, I see 2 million calls to the cache 
> per hour.
You can see why I was concerned. :)

If you don't share them then you risk inserting an event once for
each backend, but sharing them per event would mean a lot of very
inefficient myth protocol calls.

> But a static assignment of channels to backends is a 
> interesting idea.
The only problem is that when you are recording you might not
be able to collect any EIT if the transport is not assigned to
that backend.

> > Also, does this scan all the sources with independent tuners
> > at the same time, or just one source at a time?
> 
> It makes per source a list of channels/multiplexes and uses all 
> available cards to scan the channels. So it's all source at once. Every 
> card scans a different channel (as long there are more multiplexes than 
> cards).
That is a problem, if you have three sources you would be on average
leaving 2/3 of the cards idle. It will take three times as long for
the scan to complete...

How about having the scanner on each backend request the next
transport to scan from the master backend. And having the master
backend split up the transport list so that each backend
generally scans the same transports, but any scanner can request
a specific transport, in which case it gets ownership the cache
for that transport, and whichever backend normally scans that
transport is told to scan some other transport instead. This
allows the recorder to collect EIT when recording on a specific
channel, but also minimizes EIT cache copies.

> > > That gives something less than 1MB for my cache.
> > Which sounds very reasonable. Lets see if it ever grows to
> The cache will 'leak' memory since there is currently no method to prune 
> done events. But it is almost done, I have to think how often we should 
> call this method. The offset needs probably also some tests. 
Don't the old entries get overwritten with new entries?

-- Daniel