[linux-dvb] Kaffeine universal DVB-T scan file
christophpfister at gmail.com
Tue Apr 17 12:53:10 CEST 2007
Am Montag, 16. April 2007 11:54 schrieb Mauro Borghi:
> Dear Christoph, all,
> Christoph Pfister wrote:
> > Hi,
> > 2007/4/14, P. van Gaans <w3ird_n3rd at gmx.net>:
> >> Say you live in The Netherlands. Frequencies change here all the time,
> >> and QAM settings and stuff also change all the time. Say you're living
> >> on the border, like me. I receive channels from The Netherlands and
> >> Belgium at the same time, but there's no scan file for that. There will
> >> also always be locations missing in the list.
> >> And what if you simply have no clue about where you live? Nobody thinks
> >> of them! Then again, nobody knows where they are ;-)
> >> So here is the solution: a file that'll make Kaffeine scan all UHF
> >> channels with "AUTO" for the QAM and other stuff, will be sufficient in
> >> most countries although scanning takes a bit longer.
> >> I hope it makes it into some next version of Kaffeine :).
> >> Pim
> > <snip>
> > There are enough cases where such a file doesn't work (think of
> > offsets, 7 mhz transponders etc). Responsible for such complete
> > scannings are the apps (kaffeine has auto scan which does pretty much
> > the same as your file does and it tries offsets iirc).
> > Christoph
> I think dvb-t scan files should be organized in 3 "levels":
> 1. specific location
> 2. specific country
> 3. most general case
> For 1. the scan will be fast, because only frequencies known to be
> active will be scanned - and most params will be known.
> For 2., we should refer to the frequency allocation plan of a given
> country, so that all possible frequencies (and bandwidths) are listed -
> with other params left to autodetection.
Hmm ... imho this is either a summation of 1. (means we need to know all
transmitters; would make sense e.g. in places where you can receive data from
different broadcasters) or 3. (I don't see how the the number of
possibilities is significantly reduced for a specific country without knowing
> 3. should be the union of all known center frequencies used somewhere,
> listed more than once if other params may change (e.g. bandwidth 6 or 7
> or 8 MHz). The scan will probably be very slow, but the goal is to
> maximize the chance to get all available muxes.
I'm a bit sceptical about the practical implementation of that and whether it
would work reliably ...
> When the scan file for your specific location (1.) is not present or
> does not work, you can try 2., and if 2. is not enough you could try 3.
More information about the linux-dvb