[mythtv] backend from SVN 9761 bangs on mysqld

[Janne Grunau]

On Monday 24 April 2006 00:43, Daniel Kristjansson wrote:
> On Sun, 2006-04-23 at 23:58 +0200, Janne Grunau wrote:

> > I don't think using the db for the cache is a good idea. The
> > greatest parts of the EIT-scanning are atm queries. So adding more
> > is not the solution even if these queries are cheaper.
>
> But this is one query per channel, that saves us hundreds of
> megabytes of RAM..

Hndreds of megabytes is a little exaggarated :) even with your 
assumptions. I thought of a 'one query per event' design. Dynamicly 
loading and pruning of the cache will not save that much RAM since 
every multiplex can have EIT-data for all other multiplexes. I think 
there is such an multiplex on Astra.

> > If counted just my program table and the average number of events
> > per channel is clearly below 500. Using 8 kbyte (plus overhead of
> > QMap) memory per program is not that bad.
>
> 500 events is way low, just one set of half hour events for 14 weeks
> is 672. If you then account for two retransmissions as the data gets
> expanded closer to transmission time you are talking over 2000
> events.

No, most programs have only data for one week or less and all versions 
of a specific event accounts only for one entry in the cache.

> Assuming a red-black three the QMap overhead probably 48 
> bytes per entry (including the key on a 64 bit system). This gives us
> more like a minimum of 96 KB per channel,

Yeah, I underestimated the overhead of a map. But since the entries are 
clustered in the key space, it wouldn't be hard to create a data 
srtucture with very low overhead.

> which if you have a few 
> sets of channels, one or more DVB-S setups with 1000 channels. It
> gets significant, plus who wants to have to recollect all this data 
> after we restart the backend?

More than 50MB for the EIT cache is insane but if we can come up with 
something like 10MB per 1000 channels it's in my opinion ok. 

> > No, not really. I changed score_match in such a way that only a
> > perfect match can archieve a score of 12000. But Stuart
> > Auchterlonie and I are both not sure what you want to archieve with
> > the second part of that function. See attached diff.
>
> So if the ending time of the program changed you could pick this up
> by looking at the title or the description? :)

Of course not, but absolute difference between both starting and ending 
time in seconds is subtracted from the score. Look at 
DBwevent::GetMatch. So if one of the times differ, the event can't have 
a score of 12000.

Janne