[mythtv] Cross source EIT

Daniel Kristjansson danielk at cuymedia.net
Wed Mar 10 15:08:06 UTC 2010


On Wed, 2010-03-10 at 10:14 +0000, Steve Hill wrote:
> I have a DVB-S card and an analogue card connected to a Sky decoder.  Some 
> channels are available through both cards.  Aeons ago, my Myth system was able 
> to schedule recordings on either device for these "shared" channels in order to 
> resolve conflicts, but since I rebuilt my system this doesn't seem to be 
> happening.
> 
> I have "Cross source EIT" turned on for the DVB-S card and all the channels are 
> set to use the on air guide.  There seems to be no documentation at all 
> regarding the "cross source EIT" setting, so I've had a poke around the code - 
> with it turned on, it looks like the EIT scanner inserts the programme guide 
> data into the first channel it finds with a matching service/mux ID.  "First" 
> seems very arbitrary since there is no ORDER BY clause in the statement. 
> However, I'm at a loss to understand how the scheduler then retrieves this data 
> for the channel when it appears on other sources, since the programme guide 
> data was only added for the "first" match, not all matches.
> 
> It looks like http://svn.mythtv.org/trac/ticket/7672 and 
> http://svn.mythtv.org/trac/ticket/7789 discuss this issue, but haven't got much 
> response.
> 
> Can anyone explain what I'm missing or point me at some documentation?

Cross source EIT is only intended to fill in one channel's data with
data from a different mux. The use case is a single DVB-S service
that is split into different "video sources" due to MythTV's DiSEqC
requirements. In other words, it's an ugly hack to get around a design
limitation in MythTV's DiSEqC implementation. Having multiple "video
sources" with overlapping services is not supported by this feature.

Ideally the DiSEqC info that is stored in the videosource table would
be put in the dtv_multiplex table, or another table linked to it, and
then we wouldn't need this feature to fill in the guide data for a
single DVB-S service. But there are few people using MythTV for DVB-S,
and none appear to have the ability or interest in making the changes
required.

PS Due to the low penetration of DVB-S among MythTV users I would accept
a patch that did not convert old tuning data to the new format if the
the new design was demonstrably better. But of course conversion would
be ideal.

-- Daniel



More information about the mythtv-dev mailing list