On Sat, Feb 02, 2008 at 09:22:22PM +0100, Christoph Pfister wrote: > > while gnutv reported this (and no stream was present at dvr0): > > You can run "gnutv -out dvr" or "gnutv -out file <filename>". These are the outcomes of my latest experiments with the various tuning utilities. All tests refer to the tuning of JSTV1 (Cryptoworks). - gnutv, zap: Most of the time unable to lock in the encrypted channel. The status line keeps udating and displays data similar to these: status SC | signal c080 | snr aa88 | ber 0000ff20 | unc 00000000 | In this situation, no stream is available on dvr0, or written to a file. However, once in a while, launching these utilities results in correct locking of the channel. In this case the status line gets displayed only once (no update), as in status SCVYL | signal c440 | snr d119 | ber 00000900 | unc 00000000 | FE_HAS_LOCK and is shortly followed by the "Received new PMT - sending to CAM..." message. In this case, decryption is OK. - szap: always succeeds in locking the channel (but of course, no decryption): status 1f | signal c586 | snr d0f5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK Does the snr play any role in the inability of zap/gnutv to tune che channel in? (To my unexperienced eye, all FE_HAS_LOCKs seem to occur only when snr is above a certain threshold.) Do the tuning mechanisms in gnutv/zap and szap differ somehow? Thanks to anyone willing to shed some light on this. David _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
