[mythtv] backend from SVN 9761 bangs on mysqld

[Stuart Auchterlonie]

On Mon, Apr 24, 2006 at 10:03:19AM -0400, Daniel Kristjansson wrote:
> On Mon, 2006-04-24 at 11:31 +0100, Stuart Auchterlonie wrote:
> > On Sun, Apr 23, 2006 at 06:43:44PM -0400, Daniel Kristjansson wrote:
> > There are two ways of doing this. Either do nothing and take
> > the hit for the first 15min or so while the cache is build, or
> > add some extra fields to the program table, and insert the cache
> > key & value into those fields when the data is inserted in to the
> > DB. On a new startup we can just read all this info back into the
> > cache.
> 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. Also a smaller cache would also save some CPU,
> but this probably isn't significant.

The point of the cache is to reduces accesses to the DB.
Using a separate table means that there would then be 2 inserts
rather than 1 for each event. Not good.

> 
> > 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. I don't really want to do this in
> SVN-head, but I'm game for creating a branch with this in it.

As Janne said, this is just about finished. Lots of us will
patch up and do some testing.

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

this is a good idea, and is on my list of 'good things' to
have in the EIT data handling. But it currently needs quite
a bit of work...

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

it's basically a way of saying, Oy! your program is about to start,
is still running (so don't stop) etc.

Australian providers cannot even get more than now/next eit data
happening, so there is a 0.01% chance of them implementing RST.
They haven't even finished sorting it out here in the UK, where
they do pretty much everything correctly.

Stuart