[ivtv-users] What does "filter timeout" mean?

[Dale Pontius]

Devin Heitmueller wrote:
> <snip>
> 
> If you haven't already, you should install the latest v4l-dvb code.  I
> did some fixes which significantly improve the signal quality for
> ClearQAM tuning.
> 
I'm running your drivers that you announced back on Oct 29, and I
downloaded on Nov 1.  I never got a decent chance to A-B them against
the standard drivers, so I never reported anything.  It was only a few
weeks ago that I got back into messing with the digital side, again.

>> These are only 2 channels, but everything else is like this - encrypted
>> channels get a solid lock, clear ones done.
> 
> It is very common for a cable provider to multiplex *all* the ClearQAM
> channels onto two or three frequencies.  So you shouldn't expect to
> see ten or twelve unencrypted frequencies just because there are ten
> or twelve "must-carry" ClearQAM channels.
> 
When I said "only 2 channels", I meant listings and information for 1
clear, 1 encrypted.  For the clear stuff, Comcast has generally stuffed
2 HD and 2 SD channels on several frequencies, 7 SH channels on another,
etc.  The SD and clearQAM counts don't match up because some of our HD
channels have an extra SD channel (or 2, for one PBS) attached.

>> So to boil this down to a question: How do I interpret the results of
>> azap?  If I try searching, all I get is people talking about using it
>> to look for "FE_HAS_LOCK".  I find nothing about how to interpret the
>> various fields, for instance "status", "signal", "snr", "ber", "unc".
>> It's kind of obvious what "signal" and "snr" mean, but not how to
>> interpret the hex numbers presented.  It equally seems like an obvious
>> guess that for signal and snr the bigger the better, but in some cases
>> I have seen clear channels have decent numbers, as high as 014a, but
>> not sticking there, and still not getting a decent lock.
> 
> The SNR and strength values vary in terms of how they are interpreted,
> which is why everybody says that you can only rely on the FE_HAS_LOCK
> field across different products.  For your product, both the SNR and
> strength field return the SNR in 0.1dB increments.  A value of 0x014a
> translates to an SNR of 33.0 dB.
> 
Which leaves me wondering, what is "good" and "bad" for SNR?  It looks
to me as if it takes a consistent 146+ to lock and stay there, but is
that really "good", or just "adequate?"

>> I need to script all of this up, so I can do a more thorough jobe, but
>> so far every encrypted channel I've looked at is good, every clear
>> channel bad.  Given a pattern like this, I'd say that Comcast is doing
>> this on purpose, to nudge people into getting set-top boxes.
> 
> Doubtful.  While I don't trust Comcast any further than I can throw
> them, I suspect in this case you will find that your situation is
> greatly improved once you update your driver.
> 
Have there been more changes since Oct 29/Nov 1?  I'm a little behind on
my kernel, and wouldn't mind refreshing.  Is your stuff into the v4l
mainline, or still just in your space?

Thanks,
Dale