[Q]: Tevii S480 higher DVB-S2 symbol rate
Hi all, a quick question about the tevii S480: I need to tune to a transponder which does DVB-S2 45MS/s (QPSK). I have a dying TBS 6921 which was able to sustain this rate flawlessly, but the spec of the S480 seems to indicate that it should do it also, but I'd like to know if someone has actually tested it already. Moreover if someone could comment on reliability. TIA Manu -- 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
TBS 6921 supported??
Hi all, I am really interested in buying this board, and I would like to know if someone has already tested it, with success or not! Thx Bye Manu -- 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
TBS 6921 support
Hi all, I have recently contacted TBS support to see if they have new products, and they do have something in the pipeline: the 6921 and 8921, about to be released, IIRC end of november. I am interested in whicether that has good linux support. On this link you can check the specs and chips: http://www.tbsdtv.com/english/product/images/8920_vs_8921.jpg They say they have linux drivers but I would like to make sure they are good and reliable. If anyone here could tell me if these are supported or about to be. I am prepared to do some testing reporting, time permitting. TIA Bye Manu -- 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: Proftuners S2-8000 support
T. Taner a écrit : Hi, I have recently purchased Proftuners S2-8000 PCI-e card which consist of : * CX23885 pci-e interface * STB6100 Frontend * STV0900 Demodulator Vendor company supposed that card has Linux support via additional patch in their support page. I applied patch to v4l-dvb and s2-liplianin repositories. Patched source compiled and modules loaded successfully, but it didn't work properly. I got mass of error messages below, during launching VDR application. Insructions: http://www.proftuners.com/driver8000.html Patch: http://www.proftuners.com/sites/default/files/prof8000.patch So... any news for support and 45Msps DVB-S2 capability? TIA Bye Manu -- 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: Proftuners S2-8000 support
Goga777 a écrit : I have recently purchased Proftuners S2-8000 PCI-e card which consist of : * CX23885 pci-e interface * STB6100 Frontend * STV0900 Demodulator Vendor company supposed that card has Linux support via additional patch in their support page. I applied patch to v4l-dvb and s2-liplianin repositories. Patched source compiled and modules loaded successfully, but it didn't work properly. I got mass of error messages below, during launching VDR application. Insructions: http://www.proftuners.com/driver8000.html Patch: http://www.proftuners.com/sites/default/files/prof8000.patch So... any news for support and 45Msps DVB-S2 capability? the card is working with patch http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=17602#post17602 but why are you interesting so high SR for dvb-s2 ? For me the dvb-s2 channels with sr = 45 000 don't exist Goga Well there is at least one ;-), you can look here: http://www.lyngsat.com/intel903.html, *transponder which says 11495 H. And I can confirm it is not a 3 Msps DVB-S2 as I cant tune to it and alot of other people have confirmed that the high rate is actually 45Msps. And I think that this sort of high symbol rate is probably demanding for the hardware but also for the driver, so I'd like a confirmation by someone who has tested it instead of blindly believing the specs. And as all HD channels are crammed into this transponder, I am desperate to find a capable card. Moreover it is encrypted, but I can do without CI and using a smartcard reader. Anyways if someone can point me to some info in this direction, that would be great! Bye Manu * -- 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: Proftuners S2-8000 support
Sorry to hijack the thread abit, but I have seen this in the specs: # *Multi standard demodulation* * DVBS2 QPSK, 8PSK * Up to 45Msps DVBS, DVBS2 QPSK and 8PSK Is it actually able to do 45 Msps DVB-S2 (in QPSK is sufficient for me)? TIA Bye Manu -- 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: [PATCH] faster DVB-S lock with cards using stb0899 demod
SE a écrit : hi list v4l-dvb still lacks fast and reliable dvb-s lock for stb08899 chipsets. This problem was adressed by Alex Betis two years ago [1]+[2]resulting in a patch [3] that made its way into s2-liplianin, not v4l-dvb. With minor adjustments by me this patch now offers reliable dvb-s/dvb-s2 lock for v4l-dvb, most of them will lock in less than a second. Without the patch many QPSK channels won't lock at all or within a 5-20 second delay. The algo can be tested with a modified version of szap-s2 [4], introducing: * process a channel list sequentially (-e [number] -n [number]) * DiSEqC repetition (-s [number] - the default is 1 sequence + 1 repetition) * faster status polling (poll instantly after tuning, then poll every 10ms instead of 1 poll per second) * some statistics about the tuning success while processing the list Here are the new features of szap2-s2 explained: ## channel lock with instant status poll [last raw still is 0] using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 1f|signal 27948|noise 56032|ber 0|unc -2|tim 0|FE_HAS_LOCK| 0 ## channel lock with the first status poll [last raw is 1] using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 0b|signal 23200|noise 40413|ber 0|unc -2|tim 0| status 1b|signal 23200|noise 37136|ber 0|unc -2|tim 1|FE_HAS_LOCK| 1 ## channel lock with the second status poll [last raw is 2] using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00|signal 245|noise21|ber 0|unc -2|tim 0| status 1f|signal 17347|noise 45219|ber 0|unc -2|tim 2|FE_HAS_LOCK| 2 ## no channel lock - try to lock for 10 seconds, then give up and increase lok_errs +1 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim0 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 100 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 200 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 300 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 400 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 500 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 600 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 700 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 800 | status 00 | signal 0 | noise 4 | ber 0 | unc -2 | tim 900 | ## the tuning statistics look like this: lok_errs =0, runs=3035 of sequ=1207, multi=139, multi_max=2 * lok_errs = amount of lock errors * runs = current channel number while processing the list * sequ = the amount of channels to process you specified with -e [number] * multi = amount of multiple polls * multi_max = the highest status poll of a channel is stored in here Here are the results from ezap2 with an Astra 19.2E list and improved algo: TOT: lok_errs =0, runs=1207 of sequ=1207, multi=48, multi_max=47 real22m52.883s user0m0.004s sys 0m20.297s Here are the results from ezap2 with the same list and v4l-dvb mercurial algo: TOT: lok_errs =233, runs=1207 of sequ=1207, multi=113361, multi_max=987 real135m34.236s user0m0.344s sys 7m52.322s Similar results where reported by testers in vdr-portal.de [5] Feel free to test the improved algo yourself like this: time ./ezap2 -a0 -xHc Astra_only.txt -e 1207 -n 1 zap.log Change adapter to 1 or higher in case stb0899 is a different adapter in your multi card setup. Attachments are stb0899_algo.c.patch, szap-s2-to-ezap2.patch, Astra_only.txt (Astra 19.2E channels list in zap format) Inline posted patches get word wrapped again and again in kmail, even after I followed the suggestions in email-clients.txt [1] http://www.linuxtv.org/pipermail/linux-dvb/2008-September/029361.html [2] http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029455.html [3] http://mercurial.intuxication.org/hg/s2-liplianin/rev/d423b7887ec8 [4] http://mercurial.intuxication.org/hg/szap-s2 [5] http://www.vdr-portal.de/board/thread.php?threadid=99603 Signed-off-by: SE tuxoho...@hotmail.de I will try this with a TT-S2 3200 when I find some time ;-) Do I need a very recent tree? I have a v4l-dvb tree from a year ago I think. Bye Manu -- 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: How to handle independent CA devices
rjkm a écrit : Hi Johannes, Johannes Stezenbach writes: So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. it looks like there isn't much interest from DVB developers in that topic... I'll try... IMHO there are three sub topics: 1. be compatible with existing applications (I guess this means: feed stream from frontend through CI transparently) 2. create an API which would also work for CI-only devices like this Hauppauge WinTV-CI USB thingy 3. how to switch between these modes? This sec0 device is history (unused and deprecated for years), right? Yes, the former DiSEqC, etc. device. I only use it because it is is unused and I do not have to change anything in dvb-core this way. But trivial to change it or add ci0. How about the following: Rename it to ci0. When ci0 is closed the stream is routed transparently from frontend through CI, if it's opened one needs to read/write the stream from userspace. You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. If you can't get responses here I guess you could talk to vdr or other application developers. After all they'll have to use the API. I am in contact with some. Just wanted to check what people think about it on this list. Thanks for your comments. You might also want to check on mythtv-dev list, there was a guy (James Courtier-Dutton) who wanted to hack exactly this in mythtv. I guess he would have the user space point-of-view. Hope you succeed, because having an independant CI would be perfect to enable real multirec for DVB cards by decoding after the fact. Bye Manu -- 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: [Q]: any DVB-S2 card which is 45MS/s capable?
Marko Ristola a écrit : Hi. I have written some Mantis bandwidth related DMA transfer optimizations on June/July this year. They are now waiting for approval by Manu Abraham. Those reduce CPU pressure, increasing the bandwidth that can be received from the DVB card. 45MS/s bandwidth support will surely benefit from those patches. Main features: 1. Do one CPU interrupt per 16KB data instead per 4KB data. My implementation benefits only Mantis cards. https://patchwork.kernel.org/patch/107036/ 2. Remove unnecessary big CPU overhead, when data is delivered from the DVB card's DMA buffer into Linux kernel's DVB subsystem. Number 2 reduces the CPU pressure by almost 50%. This implementation benefits many other Linux supported DVB cards too. http://patchwork.kernel.org/patch/108274/ Those helped with my older single CPU Core computer with 256-QAM, delivering HDTV channel into the network and watching the HDTV channel with a faster computer. The performance bottlenecks could be seen on the command line with perf top. I had to increase PCI bus latency setting into 64 too from the BIOS. Moving DVB device into separate IRQ line with Ethernet card helped too, because Ethernet card did an interrupt per ethernet packet. So if the hardware can deliver 45MS/s data fast enough, software side can be optimized up to some point. My patches contain the most easy major optimizations that I found. If you can test some of those patches, it might help to get them into Linux kernel faster. Best regards, Marko Ristola OK these optimizations look like a step into the good direction. I guess what is also missing is a tuner which can handle that in DVB-S2, which does not seem obvious. The mantis card can do that? Thx Bye Manu -- 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: [Q]: any DVB-S2 card which is 45MS/s capable?
VDR User a écrit : Look at the vp-1041 I think. From what I gathered it is not able to do 45MS/s for DVB-S2. Thanks anyway, Manu -- 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: [Q]: any DVB-S2 card which is 45MS/s capable?
Goga777 a écrit : If someone has tested a DVB-S2 card at 45MS/s (I am interested in QPSK moslty) please speak out ;-). I dont need CI, dual tuner can be a bonus but definitely not mandatory. I already asked the question, so sorry to come back again with it, but I did not get a clear answer: the only thing I know is that STV0900 is able to do it, but I guess that the board itself must be well thought out to achieve these high rates? my hvr4000 card works well with dvb-s transponder with so high SR - 44950 see tp 11044 on http://www.lyngsat.com/eam22.html also, no any problems with dvb-s2 tp with SR 3 Yes that I know, dvb-s up to 45MS/s is OK though I cant test that here, but DVB-S2 is limited to 3 whereas I have one tp here which is DVB-S2, QPSK, FEC 5/6 at 45MS/s. This is why I am looking for a dvb card which is able to tune to these (presumably) extreme rates. Bye Manu -- 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
[Q]: any DVB-S2 card which is 45MS/s capable?
If someone has tested a DVB-S2 card at 45MS/s (I am interested in QPSK moslty) please speak out ;-). I dont need CI, dual tuner can be a bonus but definitely not mandatory. I already asked the question, so sorry to come back again with it, but I did not get a clear answer: the only thing I know is that STV0900 is able to do it, but I guess that the board itself must be well thought out to achieve these high rates? TIA Bye Manu -- 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: Mystique SaTiX-S2 Dual
OJ a écrit : I am using this card: http://www.linuxtv.org/wiki/index.php/Mystique_SaTiX-S2_Dual (v2) According to the wiki I should use the ngene driver, but I am not able to compile it. Downloaded the latest version from Mercury yesterday. Error message when compiling: $ make ngene make -C /home/olejl/src/v4l-dvb/v4l ngene make[1]: Entering directory `/home/olejl/src/v4l-dvb/v4l' cc -I. ngene.o -o ngene /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:202: undefined reference to `__wake_up' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:211: undefined reference to `_spin_lock' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:250: undefined reference to `_spin_lock' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `tasklet_schedule': /usr/src/linux-headers-2.6.32-23-generic/include/linux/interrupt.h:469: undefined reference to `__tasklet_schedule' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:218: undefined reference to `__wake_up' ngene.o: In function `tasklet_schedule': /usr/src/linux-headers-2.6.32-23-generic/include/linux/interrupt.h:469: undefined reference to `__tasklet_schedule' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:239: undefined reference to `printk' ngene.o: In function `demux_tasklet': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:103: undefined reference to `_spin_lock_irq' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `raw_local_irq_enable': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:864: undefined reference to `pv_irq_ops' ngene.o: In function `demux_tasklet': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:173: undefined reference to `_spin_lock_irq' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:139: undefined reference to `printk' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `raw_local_irq_enable': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:864: undefined reference to `pv_irq_ops' ngene.o: In function `demux_tasklet': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:146: undefined reference to `printk' ngene.o: In function `ngene_stop': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1602: undefined reference to `down' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1603: undefined reference to `i2c_del_adapter' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1604: undefined reference to `i2c_del_adapter' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1612: undefined reference to `free_irq' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1615: undefined reference to `pci_disable_msi' ngene.o: In function `ngene_command': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:380: undefined reference to `down' ngene.o: In function `ngene_command_mutex': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:328: undefined reference to `_spin_lock_irq' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `raw_local_irq_enable': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:864: undefined reference to `pv_irq_ops' ngene.o: In function `ngene_command_mutex': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `autoremove_wake_function' ngene.o: In function `get_current': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/current.h:14: undefined reference to `per_cpu__current_task' ngene.o: In function `ngene_command_mutex': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `prepare_to_wait' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `schedule_timeout' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `finish_wait' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:351: undefined reference to `printk' ngene.o: In function `memcpy_fromio': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/io_64.h:151: undefined reference to `__memcpy_fromio' ngene.o: In function `dump_command_io': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:278: undefined reference to `printk' ngene.o: In function `memcpy_fromio': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/io_64.h:151: undefined reference to `__memcpy_fromio' ngene.o: In function `dump_command_io':
Re: CAM Support for Terratec Cinergy S2 HD or Technisat SkyStar HD2
code unknown a écrit :
Hi,
I am using a Terratec Cinergy S2 HD with Mantis driver and so far the
card runs without problems.
The only thing is that CAM seems not to be supported - it is defined
out from the source code:
#if 0
err = mantis_ca_init(mantis);
if (err 0) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis CA initialization
failed %d, err);
}
#endif
My questions are:
1. Is anybody currently working on CAM support? Will it be supported soon?
2. Is there another DVB-S2 HD card which has CAM supported?
I am using a Technotrend S2-3200 with a CAM (Astoncrypt) with no problem
so far.
HTH
Bye
Manu
--
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
[Q]: anybody here knows about this DVB-S2 card?
Hi all, I found this link on a forum: http://www.anysee.com/eng/product/anyseeE30PS2Plus.php which, after more information seems to be a stv0903 based card with CI which is tested (from the info given by the forum guy) at 45MS/s for DVB-S2 (the saint-Graal for me to get my HD pay channels here ;-) So my question: does anybody here know about this card and if there is a driver somewhere? TIA, Bye Manu -- 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
DVBWorldDTV DVB-S2 PCIe 2006?
Hi all, just going on my quest for dvb-s2 card supporting 45MS/s rate for DVB-S2 QPSK. Does this card work reliably (CI included)? And if you know of others working reliably (with or without CI) let me know please. TIA Bye Manu -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
Konstantin Dimitrov a écrit : hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. I have two questions for you: do these board support (or will support in the near future) a CI interface for pay TV, and what is the best symbol rate they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK) RELIABLY. TIA Bye Manu -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
Konstantin Dimitrov a écrit : On Mon, May 31, 2010 at 5:05 AM, Emmanuel eall...@gmail.com mailto:eall...@gmail.com wrote: Konstantin Dimitrov a écrit : hello, i can't comment on your questions about the Wiki, but i made the driver for TBS 6980 and i can ensure you that the driver will be released as open-source under GPL as soon as i have permission to do that, but compared to other cards at least even at the moment you can use the card in Linux and it's very easy to add support for it using the binary modules even to the latest V4L code from repository and so those blobs are actually not so big limitation. also, you are very wrong about the price - as far as i know retails price is less than 200 USD, for example TBS online shop gives a price of 158.99 USD: http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html and i believe the dual DVB-S2 card with price of 1000 USD that you're talking about is the NetUP one and not the TurboSight TBS 6980 dual DVB-S2 card. I have two questions for you: do these board support (or will support in the near future) a CI interface for pay TV, and what is the best symbol rate they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK) RELIABLY. TBS 6980 specifications are: DVB-S QPKS: 1000 - 45000 kSps DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works fine. so, DVB-S2 symbol rate range is still better than what most other cards can offer i believe, which usually support 1 - 3 kSps for DVB-S2. TBS are developing card that will support 1000 - 45000 kSps for DVB-S2 (both QPSK and 8PSK), but i believe it won't be released any time soon. OK Thansks. I am interested in a DVB-S2 card able to tune to 45000kSps rate with CI support (yes my provider here did things so that it is hard to get rid of their STB :( ) The only one for now are the cards based upon stv0900 like the mystique satix, but I am not sure about the driver supporting CI. Bye Manu -- 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
CI support for mystique satix dvb-s2
Hi all, I am looking for a high rate dvb-s2 card with CI support (dual tuner is not a priority). I saw that the mystique seems to be supported, but I am not sure about the CI support. Can someone tell me where we are now or will be in the near future? TIA Bye Manu -- 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: Mystique SaTiX-S2 V2 CI Dual Mystique CI Interface f. Mystique SaTiX-S2 Dual
Ronald Flou a écrit : Hallo, I own the following cards: Mystique SaTiX-S2 V2 CI Dual Mystique CI Interface f. Mystique SaTiX-S2 Dual The Mystique SaTiX-S2 V2 CI Dual is working following the instructions on http://www.linuxtv.org/wiki/index.php/Mystique_SaTiX-S2_Dual and http://www.vdr-portal.de/board/thread.php?threadid=93616hilight=Mystique+SaTiX+S2+Dual The Mystique CI Interface f. Mystique SaTiX-S2 Dual isn't being recognized. Both are connected directly to each other. I even tested with the ci-interface connected, using the pcie bridge, directly to the motherboard. It only see the nGene pcie bridge but nothing else. If I can help in some way with testing the hardware, please let me know. I will not be a great help in programming, but I will help in any way I can. Just to add a me too, or almost: I want to buy a DVB-S2 with high symbol-rates capabilities for DVB-S2 (up to 45MS/s reliably) AND CI support. SO I guess this one or the single tuner version could be great, and I can help for debugging once I know something is in the works. TIA Bye Manu -- 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
Hardware able to reliably tune to high rate DVB-S2
Hi all, I am looking for a DVB-S/S2 card able to reliably tune to high symbol rates DVB-S2 (here I have a transponder with 45MS/s), I also need this with CI support. I have seen that mystix cards could be a good candidate but I am not sure. PCI or PCIe is OK, dual tuner is not mandatory. TIA, Bye Manu -- 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: CI USB
HoP a écrit : I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. /Honza Just a quick note here: you might want to post to the mythtv ML and the VDR one also (probably others but I dont know them off hand) and see how people feel about this. My guess is that quite a few potential users are on these ML, and the CI threads are recurrent there because of good dvb-s cards but without CI support. A usb-CI or equivalent HW + good drivers would allow people to pick the dvb-s(2) cards without worrying about CI support. HTH Bye Manu -- 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: CI USB
Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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 Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu -- 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: CI USB
Manu Abraham a écrit : On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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 Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Well my Astoncrypt is able to descramble 2 channels simultanueously, but here the good thing would be that you could descramble after the recording, so that you would be able for example to capture 4 channels on the same transponder only to descramble one by one later on. Bye Manu -- 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: tt s2-3200: dvb-s2 problem transponders fixed :) concerns SR 30000 3/4 8psk mode
Newsy Paper a écrit : thanks to Andreas Regel + Manu Abraham for their work. I just tested those problem transponders. If I set SR to 29998 instead of 3 they finally work with recent s2-liplian changeset. Thank you for your great work and thanks to all the others involved in v4l driver development. Then I guess this is related to a computation being abit off (3 is probably a threshold also). I any case I still have to add 4MHz to the frequencies (with DVB-S) to get a reliable lock with tt s2-3200 (kernel is ubuntu 2.6.31.4) Bye Manu -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov a écrit : On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fusté wrote: Mauro Carvalho Chehab wrote: In summary, While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up to 16 bytes (since a read loop for 2^16 is not that expensive), the current approach won't scale with bigger scancode spaces. So, it is needed expand it to work with bigger scancode spaces, used by more recent IR protocols. I'm afraid that any tricks we may try to go around the current limits to still keep using the same ioctl definition will sooner or later cause big headaches. The better is to redesign it to allow using different scancode spaces. I second you: input layer events from drivers should be augmented with a protocol member, allowing us to define new ioctl and new ways to efficiently store and manage sparse scancode spaces (tree, hashtable ). Userspace has no business knowing how driver maps hardware data stream into a keycode, only what is being mapped to what. The way is is done can change from driver-to-driver, from release to release. If I come up with an super-smart or super-stupid way of storing key mapping I won't want to modify userpsace tools to support it. But this is the point for IR. Userspace need a stable and universal driver to driver way to represent the hardware data stream. This is needed for only one but very important application: creating and modifying exchangeable remote mappings. The way of storing in kernel key mapping should not have any impacts on usersapce tools. If this is the case, this is because the actual ioctl is too tied to the way these mapping are stored. These need to changed or be expanded for IR. It will allow us to abstract the scancode value and to use variable length scancode depending on the used protocol, and using the most appropriate scheme to store the scancode/keycode mapping per protocol. The today scancode space will be the legacy one, the default if not specified protocol. It will permit to progressively clean up the actual acceptable mess in the input layer and finally using real scancode - keycode mappings everywhere if it is cleaner/convenient. I am unable to parse this part, sorry. My bad, my English is awful, sorry. :-( Best regards, Emmanuel. -- 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: [RFC v2] Another approach to IR
is a multifunction one it should be seen as multiple application. Don't mix IR encoding informations and applications : I don't care if each button of my mono-function remote use a different IR protocol that what the mapping table is for. One simple remote is a group of button, each button is the result of an IR transmission decoded in an internal IR stack representation. Don't mix IR encoding informations and remote representation : that not because a protocol have a concept of vendor/device/command or sort of that we should do automatic grouping by vendor/device/command. These protocol/vendor/device/command informations should only be reported as raw data to simplify the life of the application responsible to create the mapping tableS. We should have one evdev device per mapping table. Each table has a label. For one simple mono function remote, I create one table labeled simplexyz or better, I told to my IR config app that I have the remote model simplexyz and the good mapping is fetched from the database an injected is the simplexyz mapping table, effectively creating the simplexyz device. In my cd player app, in the remote config menu, I chose simplexyz device as the used remote. For my tree in one remote model yamahaxyz , my config app fetch and create tree mapping: yamahaxyz-vcr, yamahaxyz-cd, yamahaxyz-tv, creating tree device. In cdplayer application, I add yamahaxyz-cd as a remote, in mythtv, I add yamahaxyz-tv for the TV part and yamahaxyz-vcr for the recording part. Multifunction application should provide a way to use a different device for each standard as in real world base function. In this example, I could assign the same remote yamahaxyz-vcr for tv and vcr part of Mythtv (because vrc generally include a tv tuner and all the button to use it in the vcr ir group) to control the two functions of Mythtv. In all application, I use standard evdev keycodes, augmented with some new added because of this new kind of input device. Each IR aware application simply use one or more device for each different base profile function. (1)You could even think of an application which use one of your remote (mapping table) to re-inject standard keyboad events to control your other applications with key shortcuts. Don't forget to map alt-tab ;-) With this scheme, we stay in the pure evdev world for more than 90% of the time, even to load mappings/create devices. The only IR-internals aware application is the one to create/modify mappings, a remote editor. Universal remote are emulating a bunch of simple or multifunction remote and are not a natural beast, users take time to set them up. As such they could be views from your application as a collections of standard remote or one or more purely user defined ones. For this later case, I expect to have a great graphical remote mapping editor with auto learn features. This is the most flexible and simple scheme. I could not think of a case it could not handle and it achieve a clean layering between the IR events and the applications. For the other layers, we have the IR receiver device part, and the decoding part. The device part is an in kernel device driver problem. Even for dumb serial and pp devices for which we should have a line discipline and a parport client driver to archive good acquisition timing and low cpu/power usage (no userspace busywait loop). Device with hardware decoding and or no raw capability feed directly the input subsystem to be dispatched to the different evdev devices. lircd could still be used for his scripting part as seen in (1) For the raw receivers, we could have in kernel decoders and/or lircd in user space. It is just the mater of feeding a sort of lirc device instead of the in kernel decoder. But please, raw ir data in the form of pulse event has nothing to do with the input and event layer. Splitting one source of input events into several different evdev interfaces is a very simple thing at the input subsystem layer. And as explain, this splitting should never never never be based on protocol/vendor/device/command scancode groups but only based on mapping table. My two cents, Cheers, Emmanuel. -- 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: [RFC v2] Another approach to IR
Em Thu, 3 Dec 2009 11:50:04 -0500 Jon Smirl jonsm...@gmail.com escreveu: On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Dmitry Torokhov wrote: The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent by any remote (ok, I'm stretching it a bit). Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. On those remotes, if you press TV and then press for example Channel UP and press Radio, then press Channel UP, the channel UP code will be the same. For example, on Hauppauge Grey IR, we have: TV [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 CHANNEL UP [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 Radio [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 CHANNEL UP [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the shipped IR's. The remote is treating everything as a single integrated device which is not inconsistent with what has been said. In this case there really is only one multi-function device not two independent ones. If you want to control two independent devices you need to buy a different remote. Remotes are cheap so that's not a big deal. If you really want to use this remote to control two independent devices you need user space scripting to split the single device into two devices and then inject new events into the input layer. This is a complex case and not in the goal of getting 90% of users to just work. This remote is a typical example of the IR's that are provided together with media boards. On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and this event doesn't change the status of subsequent keys. 100% of the users of such boards will have the shipped IR. Some amount will be happy of just using the provided IR to control different applications at their computer or embedded hardware, and some amount will prefer to buy a multi-purpose IR that will allow him to control not only his computer, but also, his TV, his Air conditioning, etc. Both usages should be supported. All I'm saying is that, in the case where people have only the shipped IR, if he wants to see TV, the produced keycode will be KEY_TV, and then to change a channel, it will receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, he will press KEY_DVB and then KEY_PLAY to play his movie. So, an application like MythTV should be able to work with those keys. Eeeerrrkkk, what a .. device . For such quirky device, we could imagine a special mapping support: We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the input layer to surcharge the vendor or device with a specific value/mask for following keypresses of such remote. The mask could be choose to generate out of bound value in regards of the used protocol for the vendor or the device part to not overlap with another existing remote. Generate a complete map and so a device for each special key and you're done. No special case on the application side. In kernel states are a bit ugly, but this particular case is not too complicated and your dumb shitty remote is promoted to first class one. Regards, Emmanuel. -- 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: [RFC v2] Another approach to IR
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codees like that. Yes, it seem that there is confusion here. Forget my proposition. It is a corner case that could be handled later if needed. Cheers, Emmanuel. -- 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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote control support ? See http://marc.info/?l=linux-kernelm=122591465821297w=2 and all discussions around it. Regards, Emmanuel. --- Laposte.net fête ses 10 ans ! Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... vous aussi, pour votre adresse e-mail, choisissez laposte.net. Laposte.net, bien + qu'une messagerie -- 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
