[mythtv] backend from SVN 9761 bangs on mysqld

[Daniel Kristjansson]

On Mon, 2006-04-24 at 16:37 +0200, Janne Grunau wrote: 
> On Monday 24 April 2006 16:03, Daniel Kristjansson wrote:
> > I was thinking of a separate table, so that those without EIT
> > don't need to store this data. Storing this by transport
> That is for DVB not correct. EIT with TableID 0x60-0x6f and 0x4f are for 
> service not on the actual transport. So you don't know which parts of 
> the cache are redundant.
Let me clarify, the cache as it exists with the service keying would
be saved to a table with an mplexid key, so that all the data pertinent
to an mplexid could be pulled in at once. And with the cross source EIT
needed for some DVB-S setups, some data structure gymnastics would be
needed. The cache would read in once when we start scanning a transport
and written once when we stop scanning a transport, it would not be
read or saved for each program table update (that would be crazy :).

> > > I seriously doubt it is in the region of hundreds of megabytes...
> > I think the only way we'll know is if we implement the persistent
> > cache and monitor it's size. 
> Nearly done.
Cool, I just created a branch to try this out on.

> Together with a centralised EIT scanner on the master backend.
I'm not sure about this, it depends on the implementation whether
I like this. Part of the reason for breaking the DBEvent<->current
channel dependence was so that the scanner could be centralized
on a particular backend. But I'm reluctant about centralizing it
across backends, it seems like there would be some scalability
problems. Can you make this a separate patch?

> I can't see a significant difference in memory usage. Do you know a 
> simple way to show the allocated memory of one QMap?
Umm, no. Approximate size should be simple though.
  ( map.size() + log(map.size())/log(2) ) *
    sizeof(QMapNode<uint64_t,uint64_t>);

sizeof QMapNode is approx (8 + 8 + 8 + 4 + 8 + 8 = 48)

The size of a hash_map would be:
   map.size() * (4 + 8 + 8 = 20) * hash_factor

> I'll attach my patches against #1035 later today. The control of cards 
> in the slave needs updates to Myth_PROTO_VER and a method to prune old 
> cache entries is missing.
>From what Stuart said this might not be needed...

> > We could also switch to another data structure as Janne suggests.
> > A hash_map would probably save some space, at least on 64 bit
> > systems. hash_map is not available on Microsoft Windows, but it
> > has the same interface as a regular STL map, so an ifdef on the
> > declaration could handle this in a WIN32 port.
> I would guess it isn't needed but it should be tested on a DVB-S setup.
We'll see how big it gets before we start worrying about this.

> I had a nearly working solution for RST and EIT running_status but it is 
> outdated after some of the heavier EIT-refactorings
How did you tell tv_rec and tv_play that it's program had changed?

-- Daniel