*Setup* *******************************************

OpenSuse Linux 11.0
Linux anna 2.6.25.20-0.5-pae #1 SMP 2009-08-14 01:48:11 +0200 i686 i686 i386 GNU/Linux
DVB drivers: http://linuxtv.org/hg/v4l-dvb (ngene)
2e0444bf93a4 (changeset 14233:2e0444bf93a4, date: Mon Feb 22 10:58:43 2010 -0300)
firmware 15

or

endriss_ngene_changeset_14413_510e37da759e-20100318/   
firmware 15


module loaded with
  modprobe ngene one_adapter=0

*Usage* *******************************************

We slightly modified the latest version of szap-s2 (available from
http://mercurial.intuxication.org/hg/szap-s2/ ); see attached .tar.gz

tar xvfz modified_szap_s2.tar.gz

make

Most importantly, the modified version prints out the total delay in
seconds of main() to allow for easier debugging.

*Problem A* *******************************************

Two running instance of szap-s2 are used:

a) one for changing channels between "Das Erste" (Astra 19.2E) and
"ZDF" (Astra 19.2E)

b) the other one for recording from "Das Erste" (or any other channel)

Result:

When only a) is running, channel tuning times between the two
different transponders of "Das Erste" and "ZDF" are around 0.5
secs. This is really good.

However, when b) is started in parallel, these times increase to 1.5
to 1.8 seconds. This is not good.

How to reproduce?

0) su -c "rmmod ngene && modprobe ngene one_adapter=0"

1) ./run_szap-s2_adapter0.sh | grep Delay

..
Delay : 0.537630
Delay : 0.577866
Delay : 0.593999
Delay : 0.539668
Delay : 0.541793
..

2) in parallel to 1)

szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r -Q 1 -s 10 

(better: by adding "-Q 1 -s 10" the program is terminated, and all devices are
closed after approx. 11 to 12 secs)

=> while 2) is running 1) will show increased tuning times

..
Delay : 0.541970
Delay : 0.606943
Delay : 1.845682 [ HERE 2) was started ]
Delay : 1.765595
Delay : 1.786177
..

=> Larger tuning times are caused by both devices being used in parallel

=> The problem is independent of which device tuner is used for
recording or tuning

3) Even if 2) has terminated and all devices are closed, you will see
increased tuning times:

Delay : 1.785685
Delay : 1.769362
Delay : 1.769727
Delay : 1.781476
Delay : 1.749553
Delay : 1.017948

=> This indicates a bug in the driver itself due to closing on of the devices

4) wait another 30-40 iterations. you will see

..
Delay : 10.876533
Delay : 10.964964
Delay : 10.981659
..

=> The device timed out

=> This indicates a bug in the driver itself due to closing on of the devices

==> Problem seems to happen due to one adapter being opened and closed
again

==> A variation of the problem is: Tune and record data from one
device "cat /dev/dvb/adapter0/dvr0 | mplayer -" and open and close the
other device with szap-s2: After approx. 60 secs. no more data is
received from /dev/dvb/adapter0/dvr0

==> These problem can also be reproduces with 2 boards (4 tuners)
installed in one system: If a tuner on board is opened and then
closed, this causes both tuners of the _other_ board to timeout after
approx. 60 secs.

==> The only "work-around" seems to be to _never_ close any device to
avoid problems with any other device. However, we do not see this
problem for any other DVB board / driver we ever tested.

*Problem A revisited * *****************************

It was suggested that due to a bug the dvr should never be closed. 

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.

*Remark* *******************************************

- By reloading the ngene module, the problem disappears.

- It _seems_ that, after terminating all szap-s2 processes, and
waiting 1 to 2 minutes, and then restarting szap-s2 again, the
failures/problems seem to be gone _without_ reloading the module.