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

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

[Andreas Besse]

[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]

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



[-- Attachment #2: modified_szap_s2.tar.gz --]
[-- Type: application/x-gzip, Size: 10917 bytes --]

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

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

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

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

2) in parallel to 1)

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

(better: by adding "-Q" the program is terminated, and all devices are
closed after approx. 8 to 9 secs)

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

Delay : 0.541970
Delay : 0.606943
Delay : 1.410069 [ HERE 2) was started ]
Delay : 1.369592
Delay : 1.261879
Delay : 1.766680

3) after 2) has terminated simply let 1) continue for 30-40 iterations. you
will see

..
Delay : 1.845793
Delay : 1.772285
Delay : 2.045703
Delay : 1.817985
Delay : 0.982030
Delay : 1.769856
Delay : 1.769782
Delay : 0.537857
Delay : 21.628382

4) At this point, immediately press Ctrl-C and restart 1) - you will see

Delay : 0.577599
Delay : 0.549717
Delay : 0.593816
Delay : 0.593758
Delay : 0.549584
Delay : 0.546012

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

==> GOOD: we are now able to easily and quickly reproduce both problems
without
Ctrl-C

thanks for your help,
Andreas Besse

Andreas Besse wrote:
> 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
>
>
>   

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

[Devin Heitmueller]

On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse <besse@motama.com> wrote:
> 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?

Dvein



-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

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

[Marco Lohse]

Devin Heitmueller wrote:
> On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse <besse@motama.com> wrote:
>> 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?
> 

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.

Have fun,
Marco

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

[Devin Heitmueller]

On Thu, Mar 18, 2010 at 11:07 AM, Marco Lohse <mlohse@motama.com> wrote:
> Devin Heitmueller wrote:
>> On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse <besse@motama.com> wrote:
>>> 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?
>>
>
> 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.

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.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

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

[Marco Lohse]

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

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

[Marco Lohse]

[-- Attachment #1: Type: text/plain, Size: 4297 bytes --]

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.
> 
> 
> *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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: modified_szap_s2.tar.gz --]
[-- Type: application/x-gzip, Size: 11853 bytes --]

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

[Marco Lohse]

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