[mythtv] backend from SVN 9761 bangs on mysqld

[Janne Grunau]

On Tuesday 25 April 2006 22:53, Daniel Kristjansson wrote:
> On Tue, 2006-04-25 at 18:02 +0200, Janne Grunau wrote:
> > On Monday 24 April 2006 22:12, Daniel Kristjansson wrote:
> > > On Mon, 2006-04-24 at 21:36 +0200, Janne Grunau wrote:
> >
> > The best we can probably do is synchronize the cache through the
> > database. We do an INSERT/UPDATE for every update we see. So adding
> > the data we need for the cache shouldn't cost that much. If the
> > event was not up to date in the cache of one backend query the db.
> > If the db is up to date fine, if not continue with normal
> > insertion/update of events.
> > Positive aspects of this are that we can initialize the cache on
> > startup and synchronizing the cache is much cheaper than one real
> > insertion of each event.
> > Negative is the amount of memory used. Full cache size on all
> > backend plus DB.
>
> When two or more scans go in parallel and they cross-list
> each other almost every lookup will end up hitting the DB.

No, events from the other transport won't get much updates since we have 
seen most likely the same event with a lower tableid.
But the ultimate goal should be to dynamicly distribute the channels in 
such a way that cache overlapping is avoided.

> > It's not exactly the same. At least the tableids differ
> > (0x4e,0x50-0x5f for actual transport, 0x4f,0x60-0x6f for other
> > transports). But the need the cache.
>
> Hmmm, if we have a coordinated scan we could tell any one scanner
> to ignore network id's that are being handled directly in a parallel
> scan? We could even decide which multiplex has the least conflicts
> with other in progress scans when we change to a new multiplex...

Yeah, I have something similar on mind. Use per channel cache statistics 
to decide wich multiplex should scanned by wich backend.

> > Never configured or worked with DVB-S. Then that must be changed.
> > It's a simple extension to the active scanner part. It's probably
> > better to scan first all channels on one source and then switch to
> > the next source (for the people with rotors).
>
> Yep, this is currently handled in StartActiveScan by just putting the
> sourceid first in the ORDER BY clause.
>
> I think it is more likely that a multicard setup
> has multiple dishes and a NxM DiSEqC switch so that any card can
> access any dish.

Fixed in patch 5 except for a segmantation fault in vector::erase(). 
Working now.

> > I thinking of expiring old entries once a day.
>
> I think this makes sense. I'll apply your expiration patch to
> the eit branch after Stuart Auchterlonie has had a look at it.

Please wait, the patch is incorrect. I got something with the time 
calculation wrong.

Janne