[mythtv] backend from SVN 9761 bangs on mysqld

[Janne Grunau]

On Monday 24 April 2006 20:04, Daniel Kristjansson wrote:
> 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.

I was not so concerned since I thought one query per backend and event 
is not that bad.

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

And EIT for multiple transports from one transport is also a prolem.

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

I think we misunderstand each other. I'm pretty sure I've implemeted the 
fastest possibility to scan all channels given that you have to listen 
at least time X on each.
I'm iterating over the cards in the eventLoop. So I choose for every 
card after time x a new channel of the source that belongs to the card.
So I make the assumption that each card has only one source. As far as I 
know is this assumption for DVB correct.

> 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 will need some serious thought. The rate of updates is also too 
high to just synchronize updates in the data. 

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

No, with the current code not, the old events have lower table ids. But 
there's another problem: the eventid has 16 bits. That's together with 
a nodesize of 48 bits three MB per channel.
But in the signature is enough space so that if added the endtime in 
seconds after UNIX epoch.

Janne