Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
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 2750, 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 2750, 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 2750, 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 2750, 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 2750, 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 2750, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
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 2750, 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 2750, 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 2750, 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 2750, 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 2750, 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 2750, 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html modified_szap_s2.tar.gz Description: GNU Zip compressed data
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
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 2750, 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 2750, 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 2750, 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 2750, 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 2750, 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 2750, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions to ngene/dvb_frontend driver [Original email was "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)"]
Hi list, in addition to my previous tests, I found that the problems with long tuning delays only occurs when switching to an SD channel. If I switch to an HD channel, e.g., using adapter 0, I always get fast tuning times (see my tests below). Since the large delays only occur when switching to an SD channel, I have the following questions. 1) Is there different code for tuning to an HD channel or tuning to an SD-channel? 2) If yes, which which methods in which modules are repsonsible for tuning to an SD/HD channel? 3) Are there any methods wihtin the dvb_frontend oder ngene Modul (or anywhere in the DVB driver) that have to differ between SD- and HD channels? It would be realy great, if somone can answer these questions or give me some hints to find the problem. Best regards Michael Tests (channels_DVB-S2_transponder_switch_HD.conf and channels_DVB-S2_transponder_switch.conf are attached to this email): 1) Tune to a TV channel and forward data to dvr device ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r 2) In paralle to1) use adapter 0 to tune to an HD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 2 -x -S 1 | grep Delay Delay : 0.569672 3) In paralle to1) use adapter 0 to tune to an HD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 1 -x -S 1 | grep Delay Delay : 0.581712 4) In paralle to1) use adapter 0 to tune to an SD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay Delay : 1.760880 Michael Repplinger wrote: > Hi, > I read the problems described in email thread "Problems with ngene based > DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 > Dual)". Unfortunately, I just subscribed to this list so I cannot > respond to the original mail directly but it can be found at the end of > this mail. > > For tracking down the described problems with high delays, I tried to > understand the dvb_frontend and ngene driver and added some output > messages. The added output messages are attached as a ptach to this > email. Since this was the first time I read the source code of the > module I was not able to find a real problem or bug. > > However, I found 3 issues that I would like to report. Especially issue > 1) could be a problem. Here the irq handler of ngene module is still > triggered for 60secs if the last application using the DVB devices > terminates. > In Issue 2) I describe the methods that need more time when the > described problem occur. Unfortunately, I could only determine that > these methods need more time but was not able to find a reason. > Issue 3) could be related to issue 1). Here I saw that the ngene module > is not informed if the DVB frontend device is closed. > > Again, since I read the source code of a driver for the first time I > don't know if the described issues are OK or not. It would be great if > some of you could check the described issues. Maybe this information > helps to find/solve the problem. > > Thanks in advance > Michael Repplinger > > Testsystem: > -Kernel: 2.6.25.20-0.5-pae (Suse 11.0 distribution) > -Driver: following endriss/ngene DVB driver + attached patch > *Repository URL : http://linuxtv.org/hg/~endriss/ngene > *Revision : 14413:510e37da759e > > *Issue 1) IRQ handler is triggered for 60 seconds after last > application stops using the dvb device:* > > Reproduce Test: > a) load dvb modules as follows: > rmmod ngene > rmmod dvb_core > > modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1 > dvb_demux_tscheck=1 dvb_net_debug=1 > modprobe ngene debug=1 one_adapter=0 > > b) tail -f /var/log/messages > c) In parallel to b) start >./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x > > *Observation 1: * > In b) one can see the following output messages: > Mar 20 14:18:01 dvb_host kernel: ngene>: irq_handler IRQ 16 > Mar 20 14:18:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED > Mar 20 14:18:01 dvb_host kernel: ngene: demux_tasklet > Mar 20 14:18:01 dvb_host kernel: ngene: tsin_exchange > > => The following mehtods of ngene-core.c are called > - static irqreturn_t irq_handler(int irq, void *dev_id) ( produces the > first two lines of the above output messages) > - static void demux_tasklet(unsigned long data) ( produces the third > lines of the above output messages) > - static void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, > u32 flags) (procudes the last output message) > > => IRQ handler of ngene-core module is periodically triggered as soon as the > first application using DVB device has been used > > *Observation 2: * > Exactly 60 seconds after executing c), the IRQ handler is no long
Questions to ngene/dvb_frontend driver [Original email was "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)"]
Hi, I read the problems described in email thread "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)". Unfortunately, I just subscribed to this list so I cannot respond to the original mail directly but it can be found at the end of this mail. For tracking down the described problems with high delays, I tried to understand the dvb_frontend and ngene driver and added some output messages. The added output messages are attached as a ptach to this email. Since this was the first time I read the source code of the module I was not able to find a real problem or bug. However, I found 3 issues that I would like to report. Especially issue 1) could be a problem. Here the irq handler of ngene module is still triggered for 60secs if the last application using the DVB devices terminates. In Issue 2) I describe the methods that need more time when the described problem occur. Unfortunately, I could only determine that these methods need more time but was not able to find a reason. Issue 3) could be related to issue 1). Here I saw that the ngene module is not informed if the DVB frontend device is closed. Again, since I read the source code of a driver for the first time I don't know if the described issues are OK or not. It would be great if some of you could check the described issues. Maybe this information helps to find/solve the problem. Thanks in advance Michael Repplinger Testsystem: -Kernel: 2.6.25.20-0.5-pae (Suse 11.0 distribution) -Driver: following endriss/ngene DVB driver + attached patch *Repository URL : http://linuxtv.org/hg/~endriss/ngene *Revision : 14413:510e37da759e *Issue 1) IRQ handler is triggered for 60 seconds after last application stops using the dvb device:* Reproduce Test: a) load dvb modules as follows: rmmod ngene rmmod dvb_core modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1 dvb_demux_tscheck=1 dvb_net_debug=1 modprobe ngene debug=1 one_adapter=0 b) tail -f /var/log/messages c) In parallel to b) start ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x *Observation 1: * In b) one can see the following output messages: Mar 20 14:18:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:18:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:18:01 dvb_host kernel: ngene: demux_tasklet Mar 20 14:18:01 dvb_host kernel: ngene: tsin_exchange => The following mehtods of ngene-core.c are called - static irqreturn_t irq_handler(int irq, void *dev_id) ( produces the first two lines of the above output messages) - static void demux_tasklet(unsigned long data) ( produces the third lines of the above output messages) - static void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags) (procudes the last output message) => IRQ handler of ngene-core module is periodically triggered as soon as the first application using DVB device has been used *Observation 2: * Exactly 60 seconds after executing c), the IRQ handler is no longer triggered and no more output messages appear in b). Here the last output messages are: Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene: demux_tasklet Mar 20 14:19:01 dvb_host kernel: ngene: tsin_exchange Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_master_xfer Mar 20 14:19:01 dvb_host kernel: ngene: > ngene_i2x_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: < ngene_i2x_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: num = 1 ngene_command_i2c_write Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command_i2c_write Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command_mutex Mar 20 14:19:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_master_xfer succeeded => In this case, the mehtod ngene_i2c_master_xfer is invoked and successfully processed (additional invoked methods can also be seen from the output). *Conclusion: * Since I dont understand whats going on here, I don't know if this is correct or could cause problems. However, I would expect that the IRQ handler is not triggered, if no application accesses the DVB device. Moreover, after 60 seconds the IRQ trigger is no longer triggered. This looks like the kernel (or any other module) stops the ngene-module. *Issue 2) High delay ~(1.7-18 seconds) when switching the channel * By enabling and adding additional output messages in used dvb modules, I was able to find the mehtod that causes a higher delay. Reproduce Test: a) load dvb modules as follows: rmmod ngene rmmod dvb_core
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
Devin Heitmueller wrote: > On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
On Thu, Mar 18, 2010 at 11:07 AM, Marco Lohse wrote: > Devin Heitmueller wrote: >> On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
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 agai
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 modified_szap_s2.tar.gz Description: GNU Zip compressed data
