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 <[EMAIL PROTECTED]>
_______________________________________________ mythtv-dev mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
