On 12/10/05, Stuart Auchterlonie <[EMAIL PROTECTED]> wrote: > On Wed, Oct 12, 2005 at 09:57:52AM +0100, John Pullan wrote: > > On 11/10/05, Daniel Kristjansson <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-10-11 at 23:26 +0100, Stuart Auchterlonie wrote: > > > > > > > > Can anybody explain why the EIT processing in siparser > > > > contains all those section trackers & the rest? > > >
> > > > > > John Pullan and I know a bit about it, but it is Jacob's baby. > > > > > > > I'm just trying to decipher the code myself. see > > http://svn.mythtv.org/trac/ticket/344 > > That's what got me back looking at this. > > Something I noticed while looking at the memory leaks is the > Events map contains events for EVERY channel available, but > GetEmitID only ever picks events from the channels on the > current mplex. > > Put another way, there can be event information in the Events > map, but they won't be inserted because of the way GetEmitID > works. > I don't believe this is true. Empirically at least, it adds all the EIT data seen on the mplex (at least it did). I.e it should read the 60-6F tables for other mplex's and use them as well. Note the use of "should" and "did". > It would also be nice to clear each set of events after we > have inserted them in the database. At the moment we only > do that when siparser is deleted. > > IMHO, ideally if GetEmitID is going to say there is nothing > to do then there should be 0 events in the Events map. > Seems reasonable. WRT #344 I plan on writing a debug patch in EmitRequired to try and work out why it's not emitting. It's hard to see from logs what's happening just at the moment. > > > > > > Why don't we just > > > > 1) Decode event(s) (ParseDVBEIT, ParseATSCEIT etc) > > > > 2) Queue event(s) directly into eithelper. > > > You need to assemble the TS packets into PES packets before > > > you can call the parse functions, which is what the section > > > trackers do. > > I have to say, this was not obvious at all from the code. > > It looked like it was just trying to keep track of which > tables it has seen. > > > > > > > > After looking for those memory leaks and analysing that > > > > code it made me want to get out the hatchet and perform > > > > some surgery in that area. > > > > Unless there is a good reason I'll start sharpening > > > > the hatched :-) > > > > > There is one reason, this is scheduled for 0.20... > > Cool. > > > > > > > I for one would like to get 0.19 out before the Linux > > > Journal article on MythTV comes out next month... > > > > > > > That's a good plan. > -- John _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
