[mythtv] Channel scan produces bogus transponder data

[Daniel Kristjansson]

On Wed, 2006-11-15 at 08:25 +0100, Tino Keitel wrote:
> >From my database:
> 10 1 775 8468 714000000 0 NULL NULL NULL qpsk 8 auto a auto 0 auto n auto dvb 7 2006-09-26 20:44:59
> Janne Grunau's transponder entry:
> 10 1 775 8468 714000000 a NULL NULL NULL NULL 8 1/2 8 1/8 0 qam_16 n 2/3 dvb 7 2006-09-26 20:44:59
> 
> I put in the data Janne gave me and then the channel worked with 11748.
> Now I removed that transponder and did a full scan. The transponder
> data now look different, but I still can't use that channel (same
> problem like described above). The transponder data now look like this:
> 
> 11 1 775 8468 714000000 0 0 auto v auto 8 auto a auto 0 auto n auto dvb 7 2006-11-15 07:52:49
>
> 1. Why did the old dtv_multiplex entry stopped to work somewhere after
>    11619?
I don't know, a 'mythbackend -v record,channel' log from the working
and not working mythtv revision would help answer this question.

> 2. Why does my entry look so much different compared with Jannes?
>    Shouldn't thy look the same? He said that he also used the channel scan
>    for this.
Many of your entries are set to "auto" which means it relies on
your card's ability to detect various aspects of how the channel
is transmitted. During channel scans we sometimes use auto-detection,
and then we query the card for the actual tuning parameters. Many
cards/drivers do not support returning the actual tuning parameters,
yours appears to be one of these. Either Janne's card does or he
manually entered or edited his transports.

> 3. Why does the new entry contains different, but still broken data?
I don't know, a 'mythtv-setip -v record,channel,siparser' from a
scan might help, but hopefully Janne can tell us which of these
params are throwing off your tuning. Some of the changes look like
we are just setting NULL entries which we aren't using anyway and
are harmless, but obviously one or more of the tuning params is
giving you trouble...

-- Daniel