[linux-dvb] : Partly fixed: Twinhan VP-3040 (DTT-CI) Scanning (and tzap) problems

Fredrik Ax xmltv at axnet.nu
Wed Aug 17 09:14:41 CEST 2005


On Sun, Aug 14, 2005 at 11:01:43PM +0200, Fredrik Ax wrote:

> Hey folks,
> 
> I have a TwinhanDTV Ter-CI (VP-3040) which I can't get to work.
> I have browsed the mailinglist archives and see that a lot of work
> have been done for this card from May and on, so I hoped that it would
> be possible to get it to work now.

Well if I had read the mailinglists more carefully, it would a saved
me a few days trouble ...

It certainly took me a big step forward to change the definition for
the DTT-CI card in dst.c. so .dst_feature is DST_TYPE_HAS_CA, instead
of 0, and also needed to replaced DST_TYPE_HAS_TS204 with
DST_TYPE_HAS_NEWTUNE in .type_flags.

My configuration is, kernel - 2.6.13-rc6, cvs dvb-kernel from Aug 16
2005 with the above changes and the dst_ca-0001 patch (and toolbox.h)
from http://www.linuxtv.org/pipermail/linux-dvb/2005-August/003983.html

Now the channels on most transponpders get correctly found, but
not on all my initial transponders. Eventually I get these error
messages repeatingly in the syslog:
----------------------------------------
Aug 17 08:45:33 localhost kernel: write_dst: _write_dst error (err == -5, len == 0x0a, b0 == 0x09)
Aug 17 08:45:33 localhost kernel: dst_error_recovery: Trying to return from previous errors...
Aug 17 08:45:33 localhost kernel: write_dst: _write_dst error (err == -5, len == 0x0a, b0 == 0x09)
Aug 17 08:45:33 localhost kernel: dst_error_recovery: Trying to return from previous errors...
Aug 17 08:45:33 localhost kernel: dst_error_bailout: Trying to bailout from previous error...
Aug 17 08:45:33 localhost kernel: dst_write_tuna: write not successful
Aug 17 08:45:33 localhost kernel: write_dst: _write_dst error (err == -5, len == 0x0a, b0 == 0x09)
Aug 17 08:45:33 localhost kernel: dst_error_recovery: Trying to return from previous errors...
Aug 17 08:45:35 localhost kernel: dst_get_tuna: checksum failure?
----------------------------------------

The free to air channels seem to work for found channels now, but
on strange thing occurs sometimes.

Even if I tzap to channel and get decent signal (8000) sometimes I
can't get any data at all from the dvr device.

Example:
----------------------------------------
> tzap -r -c se-Malmo-channels.conf 'TV4' 
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file 'se-Malmo-channels.conf'
tuning to 506000000 Hz
video pid 0x0419, audio pid 0x0418
status 1f | signal 8000 | snr 5a00 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 8000 | snr 0000 | ber bfd8ff70 | unc b7f1028a | FE_HAS_LOCK
status 1f | signal 8000 | snr 5a00 | ber bfd8ff70 | unc b7f1028a | FE_HAS_LOCK
status 1f | signal 8000 | snr 0000 | ber bfd8ff70 | unc b7f1028a | FE_HAS_LOCK
status 1f | signal 8000 | snr 5a00 | ber bfd8ff70 | unc b7f1028a | FE_HAS_LOCK
...
----------------------------------------
> dd if=/dev/dvb/adapter0/dvr0 of=/tmp/a.nuv
0+0 records in
0+0 records out
0 bytes transferred in 9.746973 seconds (0 bytes/sec)
----------------------------------------

This have only occured occationally and when it occurs it seem to for
one transponder only. When it occurs it is in conjunction with
write_dst errors in the syslog.

Any ideas on this?


I guess, the next step would be to be able to see the scrambled
channels.  Increasing the buffer size in parse_ter_channel_list
(dvb-apps/lib/libdvbsi/channels.c) got rid of the initial ca_zap
errors, but now I sometimes get a segmentation fault in after parsing
the descriptor (dvb-apps/lib/libdvbsi/descriptor.c) ... I'll do some
debugging and keep you posted on the progress on this.

/frax




More information about the linux-dvb mailing list