Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)

[Marco Lohse <mlohse@motama.com>]

Marco Lohse wrote:
> Marco Lohse wrote:
>> Devin Heitmueller wrote:
>> [..]
>>> Hi Marco,
>>>
>>> Ok, great.  Like I said, I will see if I can reproduce it here, as
>>> that will help narrow down whether it's really an issue with the ngene
>>> bridge, or whether it's got something to do with that particular
>>> bridge/demod/tuner combination.
>>>
>> We made some more tests and found some additional issues that we would
>> like to report.
>>
> 
> Sorry, I forgot the attachment (modified szap-s2)
> 
>> Have fun, Marco
>>
>> *Problem A revisited * *****************************
>>
>> It was suggested that due to a bug the dvr should never be closed (as a
>> work-around)
>>
>> How does this affect channel tuning times?
>>
>> Test (using the latest version of the modified szap-s2)
>>
>> 0) su -c "rmmod ngene && modprobe ngene one_adapter=0"
>>
>> 1) Run szap-s2 using a channels.conf with "Das Erste" and "ZDF" on
>> different transponders
>>
>> szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -i
>> reading channels from file 'channels_DVB-S2_transponder_switch.conf'
>>
>>>>> Das Erste
>> zapping to 1 'Das Erste':
>> delivery DVB-S2, modulation QPSK
>> sat 0, frequency 11836 MHz H, symbolrate 27500000, coderate auto,
>> rolloff 0.35
>> vpid 0x0065, apid 0x0066, sid 0x0068
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>> Opened frontend
>> Opened video demux
>> Opened audio demux
>> status 1f | signal  69% | snr  67% | ber 1 | unc -2 | FE_HAS_LOCK
>> Delay zap_to : 0.586872
>>
>>>>> ZDF
>> zapping to 2 'ZDF':
>> delivery DVB-S2, modulation QPSK
>> sat 0, frequency 11953 MHz H, symbolrate 27500000, coderate auto,
>> rolloff 0.35
>> vpid 0x006e, apid 0x0078, sid 0x0082
>> status 1f | signal  67% | snr  63% | ber 1 | unc -2 | FE_HAS_LOCK
>> Delay zap_to : 0.580473
>>
>>>>> Das Erste
>> zapping to 1 'Das Erste':
>> delivery DVB-S2, modulation QPSK
>> sat 0, frequency 11836 MHz H, symbolrate 27500000, coderate auto,
>> rolloff 0.35
>> vpid 0x0065, apid 0x0066, sid 0x0068
>> status 1f | signal  69% | snr  67% | ber 1 | unc -2 | FE_HAS_LOCK
>> Delay zap_to : 0.553754
>>
>> => Good, you will see low tuning times.
>>
>> 2) in parallel to 1) - and without terminating 1) - run a second
>> instance of szap-s2 that reads from the device
>>
>> szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r
>> reading channels from file 'channels_DVB-S2_transponder_switch.conf'
>> zapping to 1 'Das Erste':
>> delivery DVB-S2, modulation QPSK
>> sat 0, frequency 11836 MHz H, symbolrate 27500000, coderate auto,
>> rolloff 0.35
>> vpid 0x0065, apid 0x0066, sid 0x0068
>> using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
>> Opened frontend
>> Opened video demux
>> Opened audio demux
>> ..
>>
>> 3) while 2) is running, go back to 1) and tune to different transponders
>> again:
>>
>>>>> ZDF
>> zapping to 2 'ZDF':
>> delivery DVB-S2, modulation QPSK
>> sat 0, frequency 11953 MHz H, symbolrate 27500000, coderate auto,
>> rolloff 0.35
>> vpid 0x006e, apid 0x0078, sid 0x0082
>> status 1f | signal  67% | snr  63% | ber 1 | unc -2 | FE_HAS_LOCK
>> Delay zap_to : 1.774598
>>
>>>>> Das Erste
>> zapping to 1 'Das Erste':
>> delivery DVB-S2, modulation QPSK
>> sat 0, frequency 11836 MHz H, symbolrate 27500000, coderate auto,
>> rolloff 0.35
>> vpid 0x0065, apid 0x0066, sid 0x0068
>> status 1f | signal  69% | snr  67% | ber 1 | unc -2 | FE_HAS_LOCK
>> Delay zap_to : 1.772805
>>
>> => Not good, whenver you use both tuners you will see tuning times to
>> increase from approx. 0.5 secs to 1.7 secs.
>>

Was anyone able to reproduce the problem with the increased tuning times?

Thank you for your comments.

Have fun, Marco

>>
>> *Problem B revisited * *****************************
>>
>> We also found that when reading data from the dvr device immediately
>> after tuning was completed (e.g. the lock was successful), then approx.
>> once in 50 iterations, we still get "old" data from the device. With
>> "old" I mean from the transponder previously tuned to.
>>
>> This results, for example, in the wrong "old" PAT received first.
>>
>> Work-around: Simple and annoying. Add a sleep(1) before starting to read
>> from device.
>>
>> *Remark*
>>
>> Both problems can _not_ be reproduced with any other board we tested
>> (Tevii, KNC, ..)
>>
>>