[mythtv] backend from SVN 9761 bangs on mysqld

[Stuart Auchterlonie]

On Sun, Apr 23, 2006 at 11:58:42PM +0200, Janne Grunau wrote:
> On Sunday 23 April 2006 18:07, Daniel Kristjansson wrote:
> 
> > basically you just need to make sure that if you reuse the version
> > data, it hasn't been too long since you last used it. If you don't do
> > EIT data collection for a week the EIT table version numbers will
> > have wrapped around and your cache will be out of date.
> 
> I think it's best to start with a clean cache but the problem persists 
> then too. If we miss the update to the maximum version number we won't 
> update until the next time.

It is highly unlikely that you will miss the maximum version number
of an EIT table. The version number is only changed when the
broadcaster updates the information. The whole EIT carousel is
transmitted fairly often, so you will see the maximum version number
numerous times before if changes....

> 
> > BTW The data 
> > does need to be stored in the DB, even the EIT version cache becomes
> > too big after a while. (But not nearly as big as the cache of the
> > entire EIT event that 0.19 uses.)
> 
> 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.
> 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.
> The cache needs some method to prune old entries though. In the 
> signature are 32 bits left so we can save the seconds since UNIX epoch.

I don't think that the in memory cache is going to become too
big. 7 day EPG in the UK takes about 30000 events, which is in the
region of 128bytes (key + data) * 30000 ~= 4Mb

A satellite system may have significantly more events cached than this
but really the only way to tell would be to printout cache statistics
every half hour or so and include the size of the cache. This will let
us know exactly how much our cache takes...

> 
> > > A 'if (match == 12000) return 0;' in UpdateDB(MSqlQuery, int)
> > > reduces the number of inserted events and the DB load significantly
> > > (together with other changes).
> >
> > Which pretty much disables updates; it only allows inserts to go
> > ahead. This means you will never get the longer program description
> > present in EIT tables transmitted closer to the broadcast time.
> 
> 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.

The way I wrote the cache includes the tableid as well as the version
in the cache. In ALL cases in DVB land the events that are transmitted
are on a lower tables id the closer the event is to occuring.

ie. Now & Next events are on tableid 0x4e/0x4f
0-4 day events are on tableid 0x50-0x5f,
4-7 day events are on tableid 0x60-0x6f.
Dishnet 7-10 day epg are on table id 0x90+ (IIRC)

so while you are using this functino to detect if descriptions have
been updated, in DVB land we only need to check tableid & version.

if (tableid < cached tableid)
  use this event data
else if (tableid == cached tableid && (version is better))
  use this event data



Stuart