[mythtv] backend from SVN 9761 bangs on mysqld

Daniel Kristjansson danielk at cuymedia.net
Mon Apr 24 20:12:05 UTC 2006


On Mon, 2006-04-24 at 21:36 +0200, Janne Grunau wrote:
> On Monday 24 April 2006 20:04, Daniel Kristjansson wrote:
> > On Mon, 2006-04-24 at 19:24 +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 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.

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

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

> No, with the current code not, the old events have lower table ids. But 
> there's another problem: the eventid has 16 bits. That's together with 
> a nodesize of 48 bits three MB per channel.
> But in the signature is enough space so that if added the endtime in 
> seconds after UNIX epoch.
Hmm, yeah this could be a problem. Even if we are limited to
count(tsid) * count(serviceid) * count(eventid) for the maximum size..

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 :)

Obviously it would take months for the cache to grow this big,
but it would be a problem long before the cache reaches these
proportions.

-- Daniel



More information about the mythtv-dev mailing list