On Wed, 2005-10-12 at 10:18 +0100, Stuart Auchterlonie wrote: > On Wed, Oct 12, 2005 at 09:57:52AM +0100, John Pullan wrote:
> 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. It should only contain the events for that transport, and emit them when they are known to be complete. > Put another way, there can be event information in the Events > map, but they won't be inserted because of the way GetEmitID > works. That sounds like a possible bug, but keep reading... > 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. The reason they are kept is because they are part of a "data carousel". What that means is there are lots of transmission glitches and the like so you never get all the EIT information when it is first sent to you. But since the it is continuously being fed from a ringbuffer, you just wait for the parts you are missing to come around again. When your data block is complete, you send it along to EITHelper where it is inserted in the DB. But you keep a copy so you know not to try to fetch it off the "data carousel" again and what not to send to the EITHelper again. You would soon have a partial version of you data block if you didn't track the data, and redundant DB inserts are a waste of time. You don't need to keep an entire copy of the data, you could just keep some kind of signature or hash. My guess is that Taylor assumed that the data requirements of keeping a copy for one transport weren't so great and that creating a signature/hash for both DVB and EIT events was prone to error. > IMHO, ideally if GetEmitID is going to say there is nothing > to do then there should be 0 events in the Events map. The partial event data blocks would have to be there, but the complete ones could be represented by an easy to compute signature of some kind. > > > 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. I believe it is doing both. But I haven't read that part of the code, Taylor explained it to me when he was first creating it. It is possible I misunderstood or the code changed... > > > 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. :) -- Daniel
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
