[mythtv] DVB Channel Changes

[Kenneth Aafløy]

On Thursday 15 April 2004 01:37, Taylor Jacob wrote:
> > I don't get it. You can just select distinct rows matching on transport,
> > network and provider id in conjunction with frequency, symbolrate and
> > polarity. I would suggest enforcing the use of the transport, network,
> > provider ids.
>
> Here are my thoughts..
>
> For starters it breaks a heiarchy that already exists, and screws up the
> relationship between transport and channel. This makes manually adding
> channels a completly redundant.  Have you ever tried this?  I was adding
> some services here and I don't know how many times I put in the same
> frequency/polarity/symbolrate.

Ok, It's annoying, at least for 19E + 13E, if you want them all :)

> If there was a scanning module (which I want to start working on, but need
> to get an idea whats wrong with a re-work of the tables first) to traverse
> the DVB NIT tables to pull channel information, transport information, etc
> you would have no way of knowing about transports that you do not have a
> channel associated with.

They are linked in the section headers...read the MPEG + DVB specs. But yes, 
iirc, there are some broken providers out there, who don't make sure all 
transponders on a satellite will get visited from a random scan.

> Here is an example with the current setup:
>
> You only are using fta channels and not encrypted channels from some
> satellite service.  Several transponders only have encrypted signals when
> you set it up so there is no reference to the transponders you are not
> currently tuning to.

This is bull, go read the MPEG specs, because they clearly state that 
providers can't encrypt the PAT/PMT amongst others.

> You tell your myth to scan the transponders currently (from this distinct
> query) and unless they happen to mention the other transponders existance
> in the tables you will not scan them, and miss new fta channels in your
> scan..

So you are saying that all current satellites/transponders should be 
pre-stored in MythTV? I belive something like this was argued on this list 
before, but then only for Satellites. This was (iirc) rejected by Isaac, so 
it's either going to be a configuration file (which is lame, since the 
configuration source for MythTV is the database) or hardcoded. To lessen the 
load on the users that don't have DVB, we could hardcode the list itself, and 
only push it onto the database when a DVB card is first configured. Don't 
know if the maintainers would be happy with that?

> > What about bringing in the libsi from vdr? I have not looked very
> > closely, but i belive it contains parsers for about every needed
> > table/descriptor.
>
> This might be an execellent idea.  I have used their code as a starting
> point for a few different dvb tests ive done.

And I've already borrowed the CAM code from him :)

> > Setting up MythTV is not anything like configuring a simple STB. One
> > thing is that your 'always' setting up a remote box, or at least have to
> > make it work in a remote setup. That gives you a lot of extra logic to
> > deal with.
>
> I mean that setting DVB is far more complicated than it should/needs to be.
>  There is no reason to have to manually type in piles of channels when the
> dvb system is sending all of the information you need to set it up already.

Could get a bit tired after a couple of hundred channels..

-- 

Kenneth Aafløy
ke-aa at frisurf.no