I decided to do some tests using kernel 2.6.13.3, with following results:
1) locking problems occur using "dvbscan -v" (nut also ("vlc -v") in the
following situations:
=> 2.6.13.3 kernel with downloaded snapshot 20051202: locks fine,
dvb-scan returns 0x1f and dumps PMT quickly
=> 2.6.13.3 kernel with downloaded snapshot 20060115: locks fine,
dvb-scan returns 0x1f and dumps PMT quickly
=> 2.6.13.3 kernel with downloaded snapshot 20060715: no lock, dvb-scan
returns 0x00 + timeout!
=> 2.6.13.3 kernel with downloaded snapshot 20060717: no lock, dvb-scan
returns 0x00 + timeout!
=> 2.6.13.3 kernel with downloaded hg snapshot: no lock, dvb-scan
returns 0x00 + timeout!
So it seems that something has gone wrong between snapshots from January
and July, with these locking problems as a result.
The strange thing is that the locking problems do not prevent xine or
vlc from coming up with streaming data (picture), however in between
"vlc -v" prints 'no lock' every 15 seconds or so, but keeps going anyway
....
Of course I would prefer to use the latest dvb-version, but I cannot get
it to work for reasons mentioned above.
What could possibly be wrong?
Can someone tell me who has a more recent working combination (recent
kernel + recent dvb-snapshot)?
2) in all dvb-snapshot versions that have I tested, I always need to
remove the DST_TYPE_HAS_TS204 flag from the "DCT-CI" record in dst_list
(dst.c), or I will not get a picture; only a long list of TS
discontinuities. Aren't the necessary patches (Sept 2005) present in
recent snapshots? I don't understand why I keep running into this
problem ....
3) whenever I use a "working combination (eg. 2.6.13.3 + snapshot
20060115), I still have other tuning problems. When I change frequency,
I need to start vlc 2 times: the first time there seems to be no lock.
Ctrl-C, restart and ... locked ! If I pick another PID in the same TS,
there works the first time, so it seems clearly tuner related.
Any help is very much appreciated!
Z.
======
Zoilo Gomez wrote:
I still have some weird problems with the Twinhan Cab/CI (2031).
In the mean time I have upgraded to kernel 2.6.17.8.
1) When I compile the included 2.5.17.8 drivers (no hg) then the
following happens:
=> dvbscan works fine, returning tuning status=0x1f and dumping PMT
tables
=> gxine displays garbage (green / purple squares etc)
=> vlc dumps lots of TS discontinuities
2) When I compile latest hg and install, the following happens:
=> dvbscan is no longer working, returning tuning status=0x00 and not
dumping any PMT tables
=> gxine and vlc more or less work, i.e. if you select the same freq
several times (maybe 5 times or so); however the signal is not stable
with CI, where vlc dumps a couple of dozen 'invalid header
[0x30:d2:c5:7c] (pid: 2001) lines every few minutes and lock seems lost.
After some browsing in the archives (sept 2005), and comparing source
code for both versions, I found that removal of DST_TYPE_HAS_TS204
from dst_tlist[] seems to more or less fix 1):
=> dvbscan is working fine
=> vlc working too (!), but unfortunately not always: usually when I
change freq, vlc gets stuck after dumping some initial 'TS
discontinuities' .... If I stop vlc at this point and restart the same
command once more (ie. with same freq) it works immediately. If I
change freq+pid, the same problem repeats: first time it is wrong, but
second time it works.
So it looks like there is one small tuning problem left.
Any suggestions what is going on here? I do not understand very well
what is happening. How can I debug it? What do the macro's
DST_TYPE_HAS_FW_2 etc mean?
Thank you and best regards,
Z.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
