[linux-dvb] Re: Transport errors on Twinhan DST tuners (both DVB-S and DVB-T)

["Werner Johansson" <wj@yodel.net>]

> Hi,
> 		Have you tried the windows based stuff ? Make a 
> comparison between the 
> windows based stuff and the linux version.

Yes, briefly. The status is that the Windows driver in many ways produce
results that are worse than the linux stuff as of today (!). When I ran
kernel 2.6.5 with the stock dvb drivers, I had lots of errors giving me
marginal reception, but this has changed now that I'm using kernel 2.6.8.1
with the stock drivers in there. I had continuous errors before upgrading,
and just a few transport packet errors an hour now (over sat), so yes that
would be considered very much OK for me. This is a grab of the full
transport stream, which means that I got a few _billion_ packets through and
the number of corrupted packets was in the low 100s.

For DVB-T the situation is different, I can't get error free reception in
either Windows nor Linux with that, even though I live quite close by the
transmitter. 

I have looked at the tuners/frontends just now, and indeed the DVB-S
frontends are LG, just as you guessed last time. LG TDQC-S001F to be exact.
The DVB-T tuner on the card I have is a ComTech (www.comtech-tw.com.tw)
DVBT-6K08P1T (Nxt6000 based).

> 		I got a reply from the company stating that in 
> most of the cases it could be 
> a software problem.
> 
> 		When i pointed out that it could be problem 
> with the frontend, they also 
> seemed not to rule out the possibility of the same. What they 
> say is that "we 
> do not do anything much in the ASIC, we hab=ve some 
> initialization stuff and 
> we just get the stuff from here and pass it there ..... ". 
> They also said 
> they will take a look into the ASIC code. I can't ask them to 
> open up the 
> ASIC code though.

For DVB-T it might be a frequency offset issue perhaps, the modulation seems
to be quite picky about getting the receiver onto the correct frequency to
begin with?

> 		Transport errors once in a while could be 
> considered common in a satellite 
> link ? I'm not talking about large losses here.
> 
> 		Patrick had a patch, that looked good, he tried 
> to solve the issue, but the 
> only problem was that patch was causing buffer overflows for 
> me and a couple 
> of other people. There could be some other way the same idea could be 
> implemented.

But wasn't that patch for the section filter code? If I'm requesting the
entire TS then it would not be called, right? I'm seeing these TS packets
flagged with the error bit no matter what I do it seems.

Somehow the frontends seem to perform better when I removed the stickers on
them (thereby unblocking the vents on the top of the shield box). Might be a
heat issue, even though it's pretty cool inside the box. 

/Werner