[mythtv] backend from SVN 9761 bangs on mysqld

Daniel Kristjansson danielk at cuymedia.net
Tue Apr 25 20:53:43 UTC 2006

On Tue, 2006-04-25 at 18:02 +0200, Janne Grunau wrote:
> On Monday 24 April 2006 22:12, Daniel Kristjansson wrote:
> > On Mon, 2006-04-24 at 21:36 +0200, Janne Grunau wrote:
> 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.

When two or more scans go in parallel and they cross-list
each other almost every lookup will end up hitting the DB.

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

Hmmm, if we have a coordinated scan we could tell any one scanner
to ignore network id's that are being handled directly in a parallel
scan? We could even decide which multiplex has the least conflicts
with other in progress scans when we change to a new multiplex...

> 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). 
Yep, this is currently handled in StartActiveScan by just putting the
sourceid first in the ORDER BY clause.

> A rotor does work well if it has more than one card attached to it?
I don't think so... But someone with such a configuration would have
lots of problems with MythTV as is. The scheduler could easily schedule
a recording on two separate satellites... If someone ever decides to
make that setup work for recordings, the scanner can be modified as
well. I think it is more likely that a multicard setup has multiple
dishes and a NxM DiSEqC switch so that any card can access any dish.

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

Also, in some cases current/next is the only information available
on the actual multiplex.. I think it makes more sense to prioritize
access to a network's current/next and future program caches.
So that if a scanner is actually getting 0x4e,0x50-0x5f tables
gets priority over one getting 0x4f,0x60-0x6f tables for the same
network. At any one time only one scanner gets access to a
network's portion of the cache so the loser has to ignore all the
tables on a network it does not have cache access to. This makes
saving and restoring the cache easy. If we also separate out the
current/next and future table parts of the caches then DVB-S
systems with current/next on each multiplex and future on a
separate multiplex will not be hampered. We will need to tell
the master backend which networks we are seeing and get permission
to look at the tables. But that information can be cached across
scans so there is only a flurry of activity between the backends
on the first scan of a source.

We could even use the cache of networks sent on a multiplex to
prioritize scanning, so that after the first scan we always scan
for EIT in order from the multiplexes with the greatest degree of
cross-listing to the ones with the least degree of cross-listing.

> I thinking of expiring old entries once a day.
I think this makes sense. I'll apply your expiration patch to
the eit branch after Stuart Auchterlonie has had a look at it.

-- Daniel

More information about the mythtv-dev mailing list