[mythtv] backend from SVN 9761 bangs on mysqld

[Janne Grunau]

On Monday 24 April 2006 22:12, Daniel Kristjansson wrote:
> On Mon, 2006-04-24 at 21:36 +0200, Janne Grunau wrote:
> > I was not so concerned since I thought one query per backend and
> > event is not that bad.
>
> It's pretty bad, think about when there is an EIT only channel,
> like with some DVB-S implementations, those events come fast
> and furious.

The best we can probably do is synchronize the cache through the 
database. We do an INSERT/UPDATE for every update we see. So adding the 
data we need for the cache shouldn't cost that much. If the event was 
not up to date in the cache of one backend query the db. If the db is 
up to date fine, if not continue with normal insertion/update of 
events.
Positive aspects of this are that we can initialize the cache on startup 
and synchronizing the cache is much cheaper than one real insertion of 
each event.
Negative is the amount of memory used. Full cache size on all backend 
plus DB.

> > > The only problem is that when you are recording you might not
> > > be able to collect any EIT if the transport is not assigned to
> > > that backend.
> >
> > And EIT for multiple transports from one transport is also a
> > prolem.
>
> So the same data is transmitted on different transports?
> Yeah that would be a problem for my suggested implementation.

It's not exactly the same. At least the tableids differ (0x4e,0x50-0x5f 
for actual transport, 0x4f,0x60-0x6f for other transports). But the 
need the cache.

> > I'm iterating over the cards in the eventLoop. So I choose for
> > every card after time x a new channel of the source that belongs to
> > the card. So I make the assumption that each card has only one
> > source. As far as I know is this assumption for DVB correct.
>
> Ah, this assumption is not correct, you can have a DiSEqC switch
> or a DiSEqC rotor, and some hardware like the pcHDTV HD-2000 have
> two inputs would usually be attached to two different sources; one
> connected to an antenna, and another connected to a Cable TV source.

Never configured or worked with DVB-S. Then that must be changed. It's a 
simple extension to the active scanner part. It's probably better to 
scan first all channels on one source and then switch to the next 
source (for the people with rotors). A rotor does work well if it has 
more than one card attached to it?
I'm going to implement a priority list of sources. Each cards begins to 
scan the next channel for the first source on the priority list that is 
attached to it. If the last channel for one source is reached the 
source gets moved to the end of the priority list.

> > That will need some serious thought. The rate of updates is also
> > too high to just synchronize updates in the data.
>
> Yeah, I hadn't thought about cross-listing except on DVB-S where
> one multiplex has all the data. But I understand is the norm in
> the UK. We could ignore cross-listed data when it isn't all on
> one transport, but that is a bit of a waste.

Ignoring them is easy, we simply specify mask and filter appropiate in 
the sectionreader. And if the have seen the events on the real 
multiplex, we are ignoring them due to the higher table ids.
But it's a nice feature if there's no data from actual multiplex.

> If we plug that into the memory formulas with say 500 * 65536,
> for a 500 channel source... We get 1.5 GB for a QMap and
> 1.3 GB for a hash_map with a hash_factor of 2.0..
>
> It starts to make sense to expire these once in a while :)

I thinking of expiring old entries once a day.

Janne