[mythtv] backend from SVN 9761 bangs on mysqld

[Janne Grunau]

On Monday 24 April 2006 16:03, Daniel Kristjansson wrote:
> On Mon, 2006-04-24 at 11:31 +0100, Stuart Auchterlonie wrote:
>
> I was thinking of a separate table, so that those without EIT
> don't need to store this data. Storing this by transport
> wouldn't just save memory during the scan, but also when
> recording. EIT collection is only going on on that single
> transport in that case, so the rest of the cache data is
> redundant.

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.

> > 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. Together with a centralised EIT scanner on the master 
backend.
I have 93 channels and less than 20000 events in the cache. Quite some 
have only less than 100 events. The average of the main TV channels is 
something like 400.
I can't see a significant difference in memory usage. Do you know a 
simple way to show the allocated memory of one QMap?
 
> I don't really want to do this in 
> SVN-head, but I'm game for creating a branch with this in it.

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.

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

> > If the program data changes it is MANDATORY to change the version
> > number on the EIT data table.
>
> My point was that this change is post EIT cache, so it would get
> past the cache, and then possibly be ignored by this code if it
> didn't check everything. I should probably point out that the
> point of this code is not to find exact matches, but to find
> partial matches with DataDirect/XMLTV data; so that the data
> can be merged. At the moment Janne's extension for exact matching
> code makes sense for EIT, but only because we aren't saving the
> cache. If we were, any EIT update that made it through the cache
> would be an improvement, and there would be no need to preserve
> old EIT data. The listingsource field should allow the EIT only
> case to be optimized in the future so that old EIT only data could
> just be deleted instead of being updated (unless it was for an
> in-progress recording).
>
> The reason for partial matches is not only so that extra data
> from each can be merged, I'd also like to give the user some
> controls, such as always using the program title from DataDirect,
> so that if a recording rule is set up using the DataDirect
> data (which extends out to two weeks), one week EIT data
> doesn't overwrite this with a slight variation which prevents
> the recording from happening at all.

Yeah, this makes sense, but not in the current state. Go ahaed, the 
persistant cache is nearly finished.

> > There is also talk of rolling out Running Status Table (RST)
> > support which is designed to indicate that a program starts early
> > or late etc.
>
> Handling this is a bit different though, it is more like monitoring
> the XDS during a recording to determine if the program has changed,
> right? i.e. it isn't announced until the program is in progress.
> I should point out that there are two reasons I'd like to support
> things like RST, XDS monitoring and last minute listings changes.
> One is that this might help those poor folks in Australia where the
> networks habitually go off schedule, and the other is that my wife
> watches baseball, which often goes into extra innings. At the moment
> I'm recording an extra hour on baseball games, and even then a rain
> delay + extra innings = lost end of game on the more exciting games.

I had a nearly working solution for RST and EIT running_status but it is 
outdated after some of the heavier EIT-refactorings

Janne