[mythtv] Tuning problems with V3.1 DVB patch

[John Pullan]

On Sun, 2004-12-19 at 17:35 +0000, David J. Fiddes wrote:
> Hi,
> 
> > So questions that arise are :
> > a) Are there any frequencies in the list ( I think there are judging by
> > the debug)
> 
> Yes. I think so. The code in the "Updating Transports" part of
> SIScan::StartScanner() seems to work fine. I put code to dump out the
> contents of NIT after it has finished. This data seems to mostly make
> sense.
> 
> The main frequency matches that of the main transmitter on the network
> and the extra frequencies match those quoted on www.dtg.org.uk for the
> other transmitters including the one my aerial is pointed at. The order
> of the frequencies is consistent between multiplexes but I guess that
> this can't always be relied on.
> 
> > b) If there are some, do we manage to tune to any ? (Apparently not)
> 
> CheckNIT seems to have no issues in tuning into the other frequencies
> (because of the order it only checks the main one then the correct one).
> 

So the correct frequency should have been placed into the DB. 

> What goes wrong is the next step in the scanning process where it is
> looking for services on each transport. This seems quite disconnected
> from the initial transport scanning phase with all of the tuning data
> coming from the database? I think the database doesn't seem to store
> nearly enough information. 


> It needs to store all of the frequncies that
> CheckNIT is able to glean from the transport scan otherwise how can it
> get back to rescan in the future? 

It surely only needs to store the frequency that worked ? The scan won't
rescan for transports. It will rescan services on those transports
though.

> Also DVBChannel::GetTransportOptions()
> and DVBChannel::TuneTransport() would have to know how to deal with a
> DVB-T multiplex with multiple frequencies. Probably need to store the
> favoured frequency 

As far as I understand it. The frequency list, is just a list of
alternatives. So if you get one that works, for a transport that should
be it. (Of course I might not be understanding this correctly). What I
will say is, that I have had reports of this code working, although
Simon did have to increase the tuning timeouts.

> otherwise changing multiplexes would take
> forever..

See above.

> .maybe a simple metric like: "I got signal lock therefore it
> must be OK to keep using" would be sufficient to start with?
> 
> I'm quite happy to have a hack at getting this running but I'm not sure
> about the codebase or the big picture of where it is going yet. Assuming
> I've got the right end of the stick ;)

All of above is with the huge caveat of, "I'm on a main transmitter so I
don't see these problems"

-- 
John Pullan <jmp at tarantella.com>