[mythtv] DVB EIT Implementation

[Daniel Kristjansson]

On Wed, 2005-10-12 at 11:45 +0100, Stuart Auchterlonie wrote:
> On Wed, Oct 12, 2005 at 06:28:47AM -0400, Daniel Kristjansson wrote:

> > It should only contain the events for that transport,
> > and emit them when they are known to be complete.

> Ahh, this is where various situations are different.
> UK DVB-T transmits EIT info for all mplexes on all mplexes.
> Aus DVB-T transmits EIT info for 1 mplex on that mplex.
>   (plus the info isn't very good apparently...)
> DVB-S is sometimes like both of these and sometimes has a single
> channel carrying EIT info.

i.c. Well for ATSC it is possible for it to contain info for 
another transport; it doesn't happen in practice except on PBS.
Currently it is not safe to insert data for another ATSC transport.
This is fixable though. I just didn't want to add the DB columns
unless there was a good reason too...
 
> > > 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.
> 
> The data carousel makes sense, so keeping a cache makes sense too.
> There isn't much point to signatures though.
The only point of signatures is to avoid keeping the data around 
once it is complete and sent to EITHandler. If SIParser doesn't
keep the data, a copy does not have to be made in HandleEIT. This
deep copy is only needed because QStrings and QPtrValue<> are not
thread safe, and will SEGFAULT MythTV if two threads try to use
a normal shallow copy. 

Qt makes a shallow copy when you write:
QString a="A", b;
b=a; // <- b contains a pointer to a's "A". "A" has a refrence count = 2

The problem is that "A"'s reference count is not protected by a
mutex, so when you write c=a; in thread 1 at the same time as you
write d=b; in thread 2 the reference count of "A" is only 3 not 4,
delete all 4 QStrings and you get a segfault. Making things worse,
many QString copies are implicit... For instance, passing a QString
variable as a non-reference function parameter.

With the EIT Events, if you did an assignment b=a; in HandleEIT()
and then cleared the SIParser event map you would have a shallow
copy in the clear, because the SIParser thread would never touch
those events again, and HandleEIT has a mutex keeping the eithelper
thread from touching those events before you clear SIParser's version.

> The way it works now is based on the assumption you outlined above,
> that this mplex only has data for this mplex.
That assumption is incorrect in the global scheme of things.

-- Daniel