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

Hello,

we discovered several problems with the ngene based dual DVB cards. The problems occur with the Digital Devices Cine S2 Dual DVB-S2 device (Linux4Media cineS2 DVB-S2 Twin Tuner), the clones like Mystique SaTiX S2 Dual should also be affected.

We are using the ngene drivers from the linuxtv repository
http://linuxtv.org/hg/v4l-dvb and the firmware version 15 provided by Digital Devices.

*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)

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?

1) in one shell, run

./run_szap-s2_adapter0.sh | grep Delay

You will see

Delay : 0.560508
Delay : 0.545771
Delay : 0.609781
Delay : 0.593796
Delay : 0.649772
Delay : 0.614023
..

2) in parallel in another shell, run

./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r

Immediately, you will see in 1)

Delay : 1.525178
Delay : 1.781971
..

*Problem B* *******************************************

After reproducing Problem A, we terminate process 2) by hitting Ctrl-C.

Even then, channel tuning time stay high in process 1), you will still see

Delay : 1.773303
Delay : 1.781734
Delay : 1.749948
..

This is not good.

*Problem C* *******************************************

What is even worse:

Very often, you will soon run into trouble: After a very iterations, you will see:

Delay : 21.616521
Delay : 21.773475
Delay : 21.765678

This means that tuning was not possible anymore at all. In this situation, it always helps to re-load the module by runing:

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

*Problem D* *******************************************

When terminating process 1) and immediately restarting it, channel tuning times - again - stay high. This is not good.

Often you will also see Problem C then.

*Problem E* *******************************************

Go back to reproducing Problem A (process 1 and 2 are running), and the continuously start and terminate process 2) by hitting Ctrl-C again and again. Sooner or later, you will see Problem C occur then.

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

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.

thanks for your help,
Andreas Besse

Hello,

We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz :
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334
and
http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin
)

Quoted 10 lines · Devin Heitmueller

Quoted 8 lines · Andreas Besse

Hello,

We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz :
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334
and
http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin
)

Quoted 7 lines

This is pretty interesting.  I'm doing some ngene work over the next few weeks, so I will see if I can reproduce the behavior you are seeing here.

I noticed  that you are manually setting the "one_adapter=0" modprobe setting.  Does this have any bearing on the test results?

I will try to answer this one:

No, leaving out this parameter does not change the test results; you will only need to use different and additional parameters for szap-s2 for specifying the correct adapter and sub-devices.

By now, we also found out that the problems can be reproduced much easier:

0)

szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay

Delay : 0.573021

1)

szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -x | grep Delay
Delay : 0.564667

2)

szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay
Delay : 1.741931

Instead of 2) you can also run the included script

2')

./run_szap-s2_adapter0.sh

which will result in the device timeout after 30-40 iterations

To summarize

=> When opening and closing adapter0, then opening and closing devices of adapter1, this will immediately result in problems.

And there a lot more variations of this bug, for example: actually read data from adapter0, tune adapter1 using szap-s2, which will result in adapter0 to be 'blocked' and not produce any more data after around 60 secs.

We are currently trying to dig into the source code of the driver to solve the problems and would appreciate any help.

Quoted 8 lines · Andreas Besse

Hello,

We are now able to reproduce the problem faster and easier (using the patched version of szap-s2 and the scripts included in the tar.gz :
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334
and
http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin
)

This is pretty interesting. I'm doing some ngene work over the next few weeks, so I will see if I can reproduce the behavior you are seeing here.

I noticed that you are manually setting the "one_adapter=0" modprobe setting. Does this have any bearing on the test results?

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.

Quoted 1 line

Quoted 1 line

Das Erste

Quoted 1 line

Quoted 1 line

ZDF

Quoted 1 line

Quoted 1 line

Das Erste

Quoted 1 line

Quoted 1 line

ZDF

Quoted 1 line

Quoted 1 line

Das Erste

Devin Heitmueller wrote:
[..]

Quoted 2 lines

Hi Marco,

Quoted 5 lines

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'

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

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:

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 9 lines · Marco Lohse

Devin Heitmueller wrote:
[..]

Quoted 7 lines

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.

Quoted 3 lines

We made some more tests and found some additional issues that we would like to report.

Sorry, I forgot the attachment (modified szap-s2)

Quoted 92 lines

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'

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

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:

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

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.

Quoted 19 lines

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