[mythtv] backend from SVN 9761 bangs on mysqld
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
> > 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
More information about the mythtv-dev