[mythtv-users] DVB-C problems

Janne Grunau janne-mythtvusers at grunau.be
Wed Jan 3 03:15:44 UTC 2007

On Wednesday 03 January 2007 01:47, Rudy Zijlstra wrote:
> I've been trying to get my DVB-C card working, or rather, to get
> MythTv working with my cable operator. This means working around the
> assumption on Myth that all cable operators are fully standards
> compliant.

MythTV doesn't assume that the cable providers are standard complient. 
It implements (a subset of) the DVB Standards. It doesn't implement the 
propetary format the cable providers use. 

> Or rather, the assumption that all cable operators use 
> DVB-C in the same manner.

See above.

> One of the assumptions here is that the 
> NIT-Actual will describe the actual network layout.

The DVB standard specifies this.

> On DVB-C it is very common though,

The only other report of broken DVB-C I know of from MythTV users is the 
invalid network id 0 used in finland.

> that several NIT-Other are present, which each 
> describe the network layout for a particular geographical area. STB
> for these operators will present the user with a network-id choice,
> and the user has to type in the network id. The STB then searches for
> the NIT-Other with this network-id, and installs from there.

I don't really get why any cable provider would do that. Alone the 
support for clueless user who don't know the correct network id should 
be more expensive than a dvb complient setup.

> This goes against the MythTv assumptions.

See above.

> I've tried to work around this by manual scanning, and taken the
> following steps:
> - determine the frequencies used on my cable (dvbsnoop of frequency,
> and manual analysis of of relevant NIT-Other(s).
> - enter found frequencies into dtv_multiplex
> - let mythtv-setup perform scan of transports
> - edit found channels to refer to correct transport stream instead of
> to incorrectly assumed transports from NIT-Actual

This is unfortunate. If we can tune to a transport and find channels we 
shouldn't change the data and add the channels to the current 

> - delelete transports from NIT-Actual from dtv_multiplex, so they do
> not clutter the table (and cause confusion for me).

would it help if mythtv would parse NIT-actual and all NIT-others? I 
don't like the approach of entering the correct netwerkid for scanning. 
Could you send a dump of all NITs, it would help to see how the differ 
to find a viable solution.

> End result is that it still does not work, because siscanner will
> work from the NIT, and takes the NIT-Actual (judging from output from
> "-v channel".

I'm not sure if I understand you correctly. You edited the channel table 
in such a way that all channels refer to the correct multiplex through 
mplexid but live-tv/recordings still doesn't work? Please provide a 
backend log with -v channel,record,siparser. My first guess would be 
that the original network id or transport id doesn't match the one in 
the SDT either since there is bogus information in the db or the 
transmitted SDT is also bogus. You could try to set them to 0 if you 
use 0.20 or set the sistandard to mpeg for trunk. You obviously won't 
be able to get EIT after that but Live-TV should work.

BTW which version do you use? Trunk or 0.20(-fixes)?

> As i am no coder, i would like pointers to continue this. I would
> very much like to be able to use my DVB-C card to record.

The scanning issue remains but TV works hopefully now. If you know the 
correct networkid it wouldn't be hard to exchange the NIT-actual with 
the correct NIT-other in DVBStreamData::HandleTables().


More information about the mythtv-users mailing list