Re: full TS in Linux: known issue or new one?
Hi all, regarding the described problems with capturing a full transponder from a DVB device, I would like to ask if anyone is able to reproduce the described problems? We originally found that problem on a TBS DVB dual tuner board and are able to reproduce these problems very quickly on all TBS cards we have. Please note that Konstantin already described that this problem occurs on several DVB boards as well. So it seems that there is a general problem in DVB driver. It would be great if anybody could try to reproduce the problem and report the results. As far as I understand the problem, it could be a real issue and is not only critical for applications that receive/process a full transponder. If an application requests only specific PIDs, it seems that the driver discards the garbage data in most cases because there is a lesser propability that garbage start with requested PIDs. However, since garbage data can be received from the driver they could also start with a valid/requested PID and thus affect all kind of applications that receive/process DVB data. In this case the application would process data that cannot be well interpreted which cause a very undefined behavior or even damage at the client side (e.g., interpreting garbage data as audio). So any help, suggestions, or reports if the problem can be reproduced (or not) would be appreciated, Thanks, Michael Repplinger Konstantin Dimitrov wrote: hello All, the issue in question is that in case full TS is captured immediately after lock ( without some delay ) then garbage data ( that don't belong to the TS ) are introduced in the stream. initially Michael Repplinger noticed the problem and told me about it. also, he made test script ( 'run_szap-s2_adapter0_record_dvbsnoop.sh' ) for reproducing the problem easily ( you can find it in the attachment, i made some very small changed to it compared to the original script). so, basically, the test script 'szap-s2' to first transponder in your 'channel.conf' file, use 'dvbsnoop' to dump the full TS from that transponder to a file for 30 seconds, then 'szap-s2' to second transponder in your 'channel.conf' file, use 'dvbsnoop' again to dump the full TS to another file for 30 seconds and repeats this in endless loop. if there is no delay ( 'sleep 0' ) or delay is less than 5 seconds ( at least on my setup those are delays i measured ) between executing 'szap-s2' and 'dvbsnoop' then captured stream contains some additional data that don't belong there, i.e. garbage and you can confirmed it with any TS analyzer tool or just use the attached 'test_file_with_dvbsnoop.sh' that Michael Repplinger prepared. i've already tested about 10 DVB devices from different manufacturers using completely different chips and PCI or PCIe interface and even USB interface, just for completeness here is what i've already tested: - Philips/NXP SAA7146 bridge driver - B2C2 Flexcop IIb PCI bridge driver (put in full TS mode with 'options b2c2_flexcop_pci enable_pid_filtering=0') - Booktree bt8xx bridge driver - Conexant cx88 bridge driver - Conexant cx23885 bridge driver - all USB DVB devices i have (all of them use Cypress USB controller) and with all of the above i can reproduce the problem using 'run_szap-s2_adapter0_record_dvbsnoop.sh' script. however, it seems SAA7146 is somehow better than the others, because sometimes it works good, i.e. captures correct data even without any delay between executing 'szap-s2' and 'dvbsnoop'. so, any ideas, please, either for what could be the root cause for the problem or for acceptable workaround? it seems to me at least at the moment it's a general problem with Linux DVB, but maybe it's known issue and someone knows more about it. many thanks, konstantin -- 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
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 modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1
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 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
