Andrew beat me to this, but here are my thoughts:
The attached patch attempts to do a full scan for channels
Applied about a week ago, have tested in a "difficult"
(poor reception) environment and also a strong reception area
with a few different cards. No real problems in either,
but I haven't tried scanning with the second card in a twin
setup yet. The only unusual thing is incorrect or "ghost"
frequencies entered in dtv_multiplex.
Australia is annoying, frequency-wise. Most of the DVB-T
transponders are at the centre frequencies, but some are 125KHz
higher. I have tried two different FrequencyTable setups:
1) The ranges with an offset, and
2) Extra ranges just for the offset transponders.
Here is frequenciesAU for each setup:
FrequencyTable frequenciesAU[]=
{
// VHF 6-12
{177500000,226500000,7000000,INVERSION_OFF,
BANDWIDTH_7_MHZ,FEC_AUTO,FEC_AUTO,QAM_64,
TRANSMISSION_MODE_8K,GUARD_INTERVAL_AUTO,HIERARCHY_NONE,125000,0},
// UHF 28-68
{529500000,809500000,7000000,INVERSION_OFF,
BANDWIDTH_7_MHZ,FEC_AUTO,FEC_AUTO,QAM_64,
TRANSMISSION_MODE_8K,GUARD_INTERVAL_AUTO,HIERARCHY_NONE,125000,0},
{0,0,0,INVERSION_AUTO,BANDWIDTH_AUTO,FEC_AUTO,FEC_AUTO,QAM_AUTO,
TRANSMISSION_MODE_AUTO,GUARD_INTERVAL_AUTO,HIERARCHY_AUTO,0,0},
};
After scanning with this, every transponder is recorded
with the wrong frequency (e.g. 177666000 instead of 177500000,
191666000 instead of 191625000). I have no idea how this can be,
but channel data is populated, and the backend seems to work OK
with it.
FrequencyTable frequenciesAU[]=
{
// VHF 6-12
{177500000,226500000,7000000,INVERSION_OFF,
BANDWIDTH_7_MHZ,FEC_AUTO,FEC_AUTO,QAM_64,
TRANSMISSION_MODE_8K,GUARD_INTERVAL_AUTO,HIERARCHY_NONE,0,0},
// UHF 28-68
{529500000,809500000,7000000,INVERSION_OFF,
BANDWIDTH_7_MHZ,FEC_AUTO,FEC_AUTO,QAM_64,
TRANSMISSION_MODE_8K,GUARD_INTERVAL_AUTO,HIERARCHY_NONE,0,0},
// A few transponders are 125KHz higher than the centre frequency.
// Instead of possibly doubling the scan time with a single offset,
// add a few small ranges:
{191625000,205625000,7000000,INVERSION_OFF,
BANDWIDTH_7_MHZ,FEC_AUTO,FEC_AUTO,QAM_64,
TRANSMISSION_MODE_8K,GUARD_INTERVAL_AUTO,HIERARCHY_NONE,0,0},
{536625000,557625000,7000000,INVERSION_OFF,
BANDWIDTH_7_MHZ,FEC_AUTO,FEC_AUTO,QAM_64,
TRANSMISSION_MODE_8K,GUARD_INTERVAL_AUTO,HIERARCHY_NONE,0,0},
{0,0,0,INVERSION_AUTO,BANDWIDTH_AUTO,FEC_AUTO,FEC_AUTO,QAM_AUTO,
TRANSMISSION_MODE_AUTO,GUARD_INTERVAL_AUTO,HIERARCHY_AUTO,0,0},
};
Even though this is less general (higher maintenance),
I recommend it. It is a little faster, and seems to record
mostly the correct frequencies.
(except for a "ghost" of 191625000 at 191500000)
I am surprised at the difference in total scanning time
between the strong/weak/noisy reception environments.
* Strong environment finishes in 3 min, 39 sec for 1),
and 2 min, 40 sec for 2).
* Weak signal takes about 11 minutes
for 1) and about 6 min 40 sec for 2).
P.S. I had an insane idea. On machines with multiple cards,
we could round-robin between them to speed up the scan?
P.P.S. Affter re-reading the spectrum allocation document,
I have taken VHF69 out (as Andrew had in his scan ranges).
Scans should be a few secs faster now!
--
Nigel Pearson, [EMAIL PROTECTED] | "Now the world has gone to bed,
Telstra BI&D, Sydney, Australia | Darkness won't engulf my head,
Office: 8255 4222 Fax: 8255 3153 | I can see by infrared,
Mobile: 0408 664435 Home: 9792 6998 | How I hate the night." -Marvin
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
