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. 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. *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, ..) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
