[mythtv] Current SVN DVB-S zapping problems (diseqc?)

Yeasah Pell yeasah at schwide.com
Tue Aug 29 13:59:25 UTC 2006


Lukas Kasprowicz wrote:
> Am Dienstag, 29. August 2006 01:15 schrieb Yeasah Pell:
>   
>>>> What kind of card do you have? Have you noticed any dvb-related failures
>>>> (i2c especially) in the kernel log (i.e. dmesg)?
>>>>         
>>> I am using 2x Skystar2 there were no messages in kernel logs.
>>>       
>> Would you mind re-loading the stv0299 kernel module with the "debug=1"
>> module parameter, running the test sequence again (with at least one
>> good and failed tune), and report the results of the kernel messages?
>> There should be a bunch of messages starting with "stv0299:" that should
>> correspond with every operation done on the frontend (and register reads
>> & writes), and that should hopefully shed some light on exactly what
>> commands are going to the card and whether there are any problems or not.
>>     
> I attached two files.
> working is made with r10131 and the not working with r10132.
>
>   
Interesting. Well, a few things come from this document:

1) The symbol rate is ok in the bad case.
2) There aren't any register failures shown in the log.
3) The good log shows the card with a relatively solid lock, whereas the 
bad log shows the card bouncing around between a locked state and a 
carrier-only state.

It's still possible the tuning command is failing and wouldn't show up 
in the log, but I have a different idea now after seeing the log. This 
card doesn't support auto-inversion. However, most people (including 
yourself) still use auto-inversion when tuning -- the reason it works is 
that the core frontend thread will retry with alternate inversion 
settings until it works.

But even in the bad state, the card does in fact reach a FE_HAS_LOCK 
state, just not for a very long period of time (in the kernel logs you 
provided, when VSTATUS contains at least the bits of 0x98) -- and the 
way the software auto-inversion works, the first time it gets such a 
lock, it fixes the inversion at whatever the setting is at that time, 
and thus no further spectral inversion searching is done. Whether it 
successfully tunes would depend on whether it has switched to the 
correct inversion state before it saw the first FE_HAS_LOCK.

Please try this: set the spectral inversion values for your multiplexes 
(or at least the ones that you are using for testing) to the explicit 
correct value (instead of auto), and see if it gets any better. (In the 
db, the inversion field has one of three possible values: '0' for no 
inversion, '1' for inverted, and 'a' for auto -- anything else, 
including NULL, gets treated as auto)



More information about the mythtv-dev mailing list