[linux-dvb] Problems with twinhanDTV Sat-CI and new HlCI Api

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



sigmund@xxxxxxx wrote:
> sigmund@xxxxxxx wrote:
>>>Hi,
>>>I'm trying to make a TwinhanDTV Sat-CI card work with cam and the new api, 
>>>but have a few problems. I can't say if all these are related, and I'm not 
>>>sure what more info should be supplied, but here goes:
>>>
>>>*Scanning works with dvbscan, and tuning works with szap, but no data comes 
>>>out of dvr0, even with -r and -x in various combinations and positions for 
>>>szap. I do however get FTA channels with vlc(which does it's own tuning).
>>>
>>try using test_dvr and see whether the same problem persists in 
>>dvb-apps/test
> works. 0x2000 gets lots of data, using a video pid gets some data, pat and 
> pmt pids get no data as long as I care to wait, but this is probably because 
> test_dvr doesn save anything before it has 65535 bytes 
> 
>>>*I've tried to replicate the calls of ca_zap inside vlc's dvb module, and 
>>>all seems to work, however the channel stay scrambled.
>>>
>>Let's stick on to a minimalistic thing to get this going else, would be 
>>a real pain ..
>>
>>Try running ca_zap alone, you might not be able to identify anything at 
>>all if the initial problems are not solved ..
> ca_zap does not finish, even when run before any of my code after a clean 
> reboot. There is nothing interresting in dmesg.
> 

That means probably wrong PMT_PID use dvbsnoop to get the PAT dump to 
check whether what you have in your channels.conf is the same as what is 
parsed from the PAT ..

You can post whatever you are seeing on the console, to know what's 
happening ..

>>Which provider is it ?..  Some providers even if they do descryption at 
>>Program level, the have all the descriptors at Stream level . TPS is 
>>known for that . In this case the descriptors from the Stream level have 
>>to be moved to Program level ..
> Telenor/canal digital, I do not know how they implement this stuff.
>>This thing i have not implemented yet ..
> That's ok, I heard there is a hacked version of ca_zap flowing around that 
> does this. Is this correct? Could the hacks be integrated as an option 
> perhaps?

I don't know whether it is the same way .. We would require a dump of 
the PAT and PMT to know for sure ..

I have put a placeholder for such gimmicks, just need to put it in .. 
Since people were too impatient, i thought i will have a quick preview 
too, or maybe fix it up straight as well on the list itself ..

>>Try to get a dvbsnoop output for the PAT and PMT
> I will try that, I'll be back with the information.
>>>I hope this information can be of help, and can help someone find give me a 
>>>hint as to what is wrong.
>>>
>>>As a side note, I've had several problems with these drivers, after some time 
>>>the signal strength and SNR values returned goes to 0000 in szap, and some 
>>That's okay for the moment, nothing to get upset ..
> Not upset, just mentioning it in case it might be related. I assume things 
> will play nice once I figure out how to use them.
>>>large negative value in vlc, even though tuning works. And after some more 
>>>time tuning stops working. Even though the tuning calls complete without error
>>>the data returned are still from the old transponder. Reloading the drivers 
>>>sometimes help, other times a reboot is needed.
>>Hmm .. junk data was written to the card, the MCU crashed .. most 
>>probably ..
> A reboot should fix that? Or is there some utility to reset/jump start it 
> again?
>

If the MCU crashed only a cold boot will help. Not even a reset ..

There is a software reset, dst-test -r tries to reset the MCU, but that 
is in software .. not hardware, so sometimes that should help too ..

Get a dump of the PAT and PMT tables, without which it will be just 
useless .



Manu



[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux