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, ..) >> >> -- 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
