[linux-dvb] set hide on
___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
En/na Johannes Stezenbach ha escrit: On Tue, Oct 30, 2007, Luca Olivetti wrote: El Tue, 30 Oct 2007 18:41:27 +0100 is the first complaint since I switched to safe.dnsbl.sorbs.net about one year ago) It doesn't surprise me, since those affected cannot contact you. It's the perfect system to avoid complaints ;-) Bullshit. Just a suggestion: If you run your own mailserver you should probably read RFC 2821. Frankly, I didn't check if linuxtv.org follows rfc2821 (and now that I'm delisted I cannot check), however most of the sites that blindly rely on flawed blacklists don't usually honour rfc2821 either (I suppose you refer to section 4.5.1). Or failing that, you could just ask someone else to forward a message for you, or ask Mauro or one of the other developers for help. Yes, there are workarounds for linuxtv.org. In other cases it may not be so simple to contact the administrador (see above). And, again, I shouldn't go through all this hassle: I did nothing wrong. Bye -- Luca ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Hi Steve, On Wed, Oct 31, 2007, Steven Toth wrote: You've miss-interpreted my comments. I suggested that the API should be defined, but not necessarily implemented. I was suggesting that we define enough API to generate a test tree and make some progress. Supporting your earlier statement, I suggested that the small amount of unimplemented API (which you suggested was inconsequential) could be implemented while other developers were testing the core TV functionality. ... I'm wasting my time here. I was hoping you would outline how you would like to proceed. Instead you ask Manu for his plans and then declare I don't like it -- IMHO that's a bit lame. May I suggest that you create a new tree which uses just the bits from Manu's tree which you intend to reuse (of course keeping copyright/authorship attribution intact), and rebase your HVR4000 on top of it? IMHO the userspace-visible API (i.e. the changes to include/linux/dvb/frontend.h only) was discussed extensively, and while there still are a few missing pieces I don't see the need to restart from scratch. I know that e.g. Felix Domke mentioned he'd prefer a more minimalistic frontend.h API change. Personally I wouldn't mind but I think the time to bang out a complete proposal, and discuss it and find supporters for it will take longer than just going with what we have now in Manu's tree. I haven't looked at Manu's dvb-core changes yet. Currently it is also not clear to me if your problem is with the code or just with the fact that Manu owns the code and you can't go forward without him. But the latter is what I tried to address with my proposal to create a repository which splits API/dvb-core changes from the STB0899 driver. Please outline what your actual problem is, maybe then I can help to resolve it. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
En/na Johannes Stezenbach ha escrit: Fighting spam is always a matter of effort. I didn't do the current setup (Ralf H. did), but I had to choose some replacement DNSBLs because those which were used originally went out of existance. if it's one I had to deal with, good riddance! (I don't remember the name, but I do remember that they didn't listen to you. I was very glad when I saw them disappear). It seemed to be popular in Germany, so maybe it's the same. Maybe there's a better replacement for safe.dnsbl.sorbs.net, I'll try to look into it at the weekend. But I don't have the time to change the whole setup now, and just installing spamd won't cut it as this thing eats too much CPU with the amount of spam that hits linuxtv.org. Greylisting and sender address verification don't suck too much cpu (though the latter may not be advisable on high traffic sites, and the former doesn't work with some broken senders). Both will let some spam through, though they don't give false positives. Bye -- Luca ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
On Fri, Nov 02, 2007, Luca Olivetti wrote: En/na Johannes Stezenbach ha escrit: On Tue, Oct 30, 2007, Luca Olivetti wrote: El Tue, 30 Oct 2007 18:41:27 +0100 is the first complaint since I switched to safe.dnsbl.sorbs.net about one year ago) It doesn't surprise me, since those affected cannot contact you. It's the perfect system to avoid complaints ;-) Bullshit. Just a suggestion: If you run your own mailserver you should probably read RFC 2821. Frankly, I didn't check if linuxtv.org follows rfc2821 (and now that I'm delisted I cannot check), however most of the sites that blindly rely on flawed blacklists don't usually honour rfc2821 either (I suppose you refer to section 4.5.1). Yes. Or failing that, you could just ask someone else to forward a message for you, or ask Mauro or one of the other developers for help. Yes, there are workarounds for linuxtv.org. In other cases it may not be so simple to contact the administrador (see above). And, again, I shouldn't go through all this hassle: I did nothing wrong. Fighting spam is always a matter of effort. I didn't do the current setup (Ralf H. did), but I had to choose some replacement DNSBLs because those which were used originally went out of existance. Maybe there's a better replacement for safe.dnsbl.sorbs.net, I'll try to look into it at the weekend. But I don't have the time to change the whole setup now, and just installing spamd won't cut it as this thing eats too much CPU with the amount of spam that hits linuxtv.org. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] dvb-usb-vp702x-02.fw
Greg Suarez wrote: I'm trying to get my TwinHann Starbox (7021) to work but the driver is looking for the firmware dvb-usb-vp702x-02.fw but I can only find dvb-usb-vp702x-01.fw. Does anyone know where I can get a hold of the -02 firmware? Found it on a German forum: http://www.slackforum.de/forum/index.php?t=msgth=2706start=0PHPSESSID=anenqvsmugl3u985m8366f55i3 Search for the filename - there is a download link. Nils Is there any way we can get this posted on http://www.linuxtv.org/downloads/firmware/ it really is a pain to find thing across multiple languages buried in forums :). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: The design goals for me are: 1) We stop trying to predict what the API will need in 5 years, and focus on building a very simplistic ioctl API for getting and setting generic frontend properties, it should be basic enough to deal with any new modulation type (or advanced tuner) that we know of today. 2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND) to a looser command/sequence definition. (Thereby stepping away from fixed structs that define the ABI). With two new ioctls (get_property/set_property) and a simple property struct which specifies how generic types are passed to/from the kernel. 3) A userland library _may_ offer a number of helper functions to simplify in terms of applications development, turning this: [..] command.id = END_TRANSACTION ioctl(SET_PROPERTY, command); Into a more human readable form like this: int tune_8vsb(frequency); Even before you thought even, we (myself and adq) have had an implementation to do this, in kernel it was called mti and the userspace interface called libdvbapi. The sample implementation was with the stv0299 and the ttpci card. This was more than 18 months back. The reason for that cause was another specific demodulator. You can read through the archives, on the same, tuning algorithms and so on. In that scenario, we additionally had the tuning algorithm in userspace too, simplifying many other things. HTH Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Gigabyte u7000 usb dvb-t support ?
Hi all, I bought the Gigabyte u7000 dvb-t usb key. This device is not supported under linux as far as i know. I put the file u7000.txt as attachment for the output of lsusb -v -s . I think i saw something related to dibcom when installing the windows drivers. The technical overview from gigabyte website shows : Tuner Microtune 2060 Decoder chipDibcom 7700 series Interface USB 2.0 Digital TV DVB-T Analog TV NO Remote sensor Interface IR I tried to modprobe the dib7000* module. dmesg is showing nothing for that device. Is there any documentation to start from for a noob to investigate this device ? @+ dom Bus 002 Device 006: ID 1044:7001 Chu Yuen Enterprise Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1044 Chu Yuen Enterprise Co., Ltd idProduct 0x7001 bcdDevice0.01 iManufacturer 1 GIGABYTE iProduct2 U7000 iSerial 3 001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: The design goals for me are: 1) We stop trying to predict what the API will need in 5 years, and focus on building a very simplistic ioctl API for getting and setting generic frontend properties, it should be basic enough to deal with any new modulation type (or advanced tuner) that we know of today. 2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND) to a looser command/sequence definition. (Thereby stepping away from fixed structs that define the ABI). With two new ioctls (get_property/set_property) and a simple property struct which specifies how generic types are passed to/from the kernel. 3) A userland library _may_ offer a number of helper functions to simplify in terms of applications development, turning this: [..] command.id = END_TRANSACTION ioctl(SET_PROPERTY, command); Into a more human readable form like this: int tune_8vsb(frequency); Even before you thought even, we (myself and adq) have had an implementation to do this, in kernel it was called mti and the userspace interface called libdvbapi. The sample implementation was with the stv0299 and the ttpci card. This was more than 18 months back. The reason for that cause was another specific demodulator. You can read through the archives, on the same, tuning algorithms and so on. In that scenario, we additionally had the tuning algorithm in userspace too, simplifying many other things. Interesting, I'll dig back and read. Why didn't it gain any traction? It was done around 70%, but then the STB0899 got a higher priority. Markus's userspace approach is also similar, not much different, small differences. ;-) When so much is done, then i would say better it is to move all frontends to userspace as well. but mti/libdvbapi had the best of both the worlds, It was to be working with both in kernel and userspace drivers, quite flexible. The whole thing started of with a small thing, an idea from Johannes about a simple user space tuning. I had even pointed it to Greg KH when he introduced UIO and eventually it was on LWN as well. probably if you Google you might find the same. Greg was happy to see such things which were completely different. It wasn't that it didn't gain any traction, Ralph at that time advised me to pay more attention to DVB-S2/STB0899. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
On Tue, Oct 30, 2007, Luca Olivetti wrote: El Tue, 30 Oct 2007 18:41:27 +0100 is the first complaint since I switched to safe.dnsbl.sorbs.net about one year ago) It doesn't surprise me, since those affected cannot contact you. It's the perfect system to avoid complaints ;-) Bullshit. Just a suggestion: If you run your own mailserver you should probably read RFC 2821. Or failing that, you could just ask someone else to forward a message for you, or ask Mauro or one of the other developers for help. it has very low priority for me, sorry. Well, I hope you reconsider. As I said I was wrongly listed. Twice. One day the same could happen to you, then you'll understand. I've made that experience already. Today I entrust my private mail to a buddy who knows his job. But I think the key problem is that if you choose the wrong hoster for your server, you'll gonna have problems... Anyway, I freely admit that I'm rather lame as a mail server admin. Changing the spam filter setup is on my TODO list, but I'm not going to rush it, I need more time to do it than I have atm. I'll add your IP address to the whitelist, though. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: simpler/smaller interface. I made reference to this in my first HVR4000 patches where massive amounts of code were potentially being duplicated. Please point out the duplication. At the time, the demod drivers had to provide a set_frontend() and set_params() ops method. That meant two entry points into every driver (with differing args), the same was true for many other entry points that took the new structures. Btw, before you start complaining about other's code, It is always better to have a look at your own code to have a feel where you are standing. Because of some of your changes we have had long arguments by Markus, (on locking) well this was in kernel. What you are complaining is something not even applied to the kernel and very much pre alpha. Just to talk back on the same tongue. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: simpler/smaller interface. I made reference to this in my first HVR4000 patches where massive amounts of code were potentially being duplicated. Please point out the duplication. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
Which kernel version are you using? I'm running 2.6.20 on Ubuntu Feisty. Mine isn't getting disconnected immediately but my scan always fails and I get usb in operation failed. (-110), looks like the errno is ETIMEDOUT from usb_start_wait_urb(). Has anyone gotten the TwinHann Starbox (7021) working? Thanks, Greg On Nov 2, 2007 4:06 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am also having an issue getting the TwinHan Starbox to work. However aside from the kernel providing a link to a firmware that does not exist... the interface immediately gets deinitialized and disconnected when I connect it see dmesg excerpt. Oct 24 16:41:31 heartofgold kernel: [117625.772000] usb 1-4: new high speed USB device using ehci_hcd and address 3 Oct 24 16:41:32 heartofgold kernel: [117625.904000] usb 1-4: configuration #1 chosen from 1 choice Oct 24 16:41:32 heartofgold kernel: [117626.02] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware Oct 24 16:41:32 heartofgold kernel: [117626.052000] dvb-usb: downloading firmware from file 'dvb-usb-vp702x-02.fw' Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Oct 24 16:41:32 heartofgold kernel: [117626.12] usb 1-4: USB disconnect, address 3 Oct 24 16:41:32 heartofgold kernel: [117626.12] DVB: registering new adapter (TwinhanDTV StarBox DVB-S USB2.0 (VP7021)). Oct 24 16:41:32 heartofgold kernel: [117626.12] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold last message repeated 5 times Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: MAC address: 00:00:00:00:00:00 Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] input: IR-receiver inside an USB DVB receiver as /class/input/input6 Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: schedule remote query interval to 400 msecs. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully deinitialized and disconnected. Oct 24 16:41:32 heartofgold kernel: [117626.268000] usbcore: registered new interface driver dvb_usb_vp702x --- Original Message --- From: [EMAIL PROTECTED]:[EMAIL PROTECTED] Sent: 11/2/2007 6:53:57 AM To : linux-dvb@linuxtv.org Cc : Subject : RE: [linux-dvb] dvb-usb-vp702x-02.fw Greg Suarez wrote: I'm trying to get my TwinHann Starbox (7021) to work but the driver is looking for the firmware dvb-usb-vp702x-02.fw but I can only find dvb-usb-vp702x-01.fw. Does anyone know where I can get a hold of the -02 firmware? Found it on a German forum: http://www.slackforum.de/forum/index.php?t=msgth=2706start=0PHPSESSID=anenqvsmugl3u985m8366f55i3 Search for the filename - there is a download link. Nils Is there any way we can get this posted on http://www.linuxtv.org/downloads/firmware/ it really is a pain to find thing across multiple languages buried in forums :). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: I haven't looked at the example STB0899 driver in a _long_ time, but I would hope those issues have since been resolved. Complain when you are sure about it. Otherwise it is called whining. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
I am also having an issue getting the TwinHan Starbox to work. However aside from the kernel providing a link to a firmware that does not exist... the interface immediately gets deinitialized and disconnected when I connect it see dmesg excerpt. Oct 24 16:41:31 heartofgold kernel: [117625.772000] usb 1-4: new high speed USB device using ehci_hcd and address 3 Oct 24 16:41:32 heartofgold kernel: [117625.904000] usb 1-4: configuration #1 chosen from 1 choice Oct 24 16:41:32 heartofgold kernel: [117626.02] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware Oct 24 16:41:32 heartofgold kernel: [117626.052000] dvb-usb: downloading firmware from file 'dvb-usb-vp702x-02.fw' Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Oct 24 16:41:32 heartofgold kernel: [117626.12] usb 1-4: USB disconnect, address 3 Oct 24 16:41:32 heartofgold kernel: [117626.12] DVB: registering new adapter (TwinhanDTV StarBox DVB-S USB2.0 (VP7021)). Oct 24 16:41:32 heartofgold kernel: [117626.12] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold last message repeated 5 times Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: MAC address: 00:00:00:00:00:00 Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] input: IR-receiver inside an USB DVB receiver as /class/input/input6 Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: schedule remote query interval to 400 msecs. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully deinitialized and disconnected. Oct 24 16:41:32 heartofgold kernel: [117626.268000] usbcore: registered new interface driver dvb_usb_vp702x --- Original Message --- From: [EMAIL PROTECTED]:[EMAIL PROTECTED] Sent: 11/2/2007 6:53:57 AM To : linux-dvb@linuxtv.org Cc : Subject : RE: [linux-dvb] dvb-usb-vp702x-02.fw Greg Suarez wrote: I'm trying to get my TwinHann Starbox (7021) to work but the driver is looking for the firmware dvb-usb-vp702x-02.fw but I can only find dvb-usb-vp702x-01.fw. Does anyone know where I can get a hold of the -02 firmware? Found it on a German forum: http://www.slackforum.de/forum/index.php?t=msgth=2706start=0PHPSESSID=anenqvsmugl3u985m8366f55i3 Search for the filename - there is a download link. Nils Is there any way we can get this posted on http://www.linuxtv.org/downloads/firmware/ it really is a pain to find thing across multiple languages buried in forums :). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] OT: Re: linuxtv.org fell in the blacklists trap
DS == David Santinoli [EMAIL PROTECTED] writes: DS If my server got listed for the reason above I'd rather put my DS efforts in getting a decent reverse lookup, as this is likely to DS cause problems well beyond a rejection by SORBS. The reverse lookup is perfectly decent. It forward resolves, and everything is good. It just matches a regexp that SORBS decides means dynamic. There is nothing to fix, except SORBS. /Benny ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Why does Mplayer repeat ioctl Commads????
Dear: I am using mplayer to play live tv. When I print the debug info, I found that mplayer send the same ioctl commands, I wonder why is this? These commands include VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_QUERY_BUF and also maybe some others i don't find now. :-( ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
There are two versions. Only the StarBox2 is supported. There is no way (at least I don't know it) to figure out whether you have a 2 or a 1. If it it does not work I guess you have a StarBox1. Patrick. On Fri, 2 Nov 2007, Greg Suarez wrote: Which kernel version are you using? I'm running 2.6.20 on Ubuntu Feisty. Mine isn't getting disconnected immediately but my scan always fails and I get usb in operation failed. (-110), looks like the errno is ETIMEDOUT from usb_start_wait_urb(). Has anyone gotten the TwinHann Starbox (7021) working? Thanks, Greg On Nov 2, 2007 4:06 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am also having an issue getting the TwinHan Starbox to work. However aside from the kernel providing a link to a firmware that does not exist... the interface immediately gets deinitialized and disconnected when I connect it see dmesg excerpt. Oct 24 16:41:31 heartofgold kernel: [117625.772000] usb 1-4: new high speed USB device using ehci_hcd and address 3 Oct 24 16:41:32 heartofgold kernel: [117625.904000] usb 1-4: configuration #1 chosen from 1 choice Oct 24 16:41:32 heartofgold kernel: [117626.02] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware Oct 24 16:41:32 heartofgold kernel: [117626.052000] dvb-usb: downloading firmware from file 'dvb-usb-vp702x-02.fw' Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Oct 24 16:41:32 heartofgold kernel: [117626.12] usb 1-4: USB disconnect, address 3 Oct 24 16:41:32 heartofgold kernel: [117626.12] DVB: registering new adapter (TwinhanDTV StarBox DVB-S USB2.0 (VP7021)). Oct 24 16:41:32 heartofgold kernel: [117626.12] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold last message repeated 5 times Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: MAC address: 00:00:00:00:00:00 Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] input: IR-receiver inside an USB DVB receiver as /class/input/input6 Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: schedule remote query interval to 400 msecs. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully deinitialized and disconnected. Oct 24 16:41:32 heartofgold kernel: [117626.268000] usbcore: registered new interface driver dvb_usb_vp702x --- Original Message --- From: [EMAIL PROTECTED]:[EMAIL PROTECTED] Sent: 11/2/2007 6:53:57 AM To : linux-dvb@linuxtv.org Cc : Subject : RE: [linux-dvb] dvb-usb-vp702x-02.fw Greg Suarez wrote: I'm trying to get my TwinHann Starbox (7021) to work but the driver is looking for the firmware dvb-usb-vp702x-02.fw but I can only find dvb-usb-vp702x-01.fw. Does anyone know where I can get a hold of the -02 firmware? Found it on a German forum: http://www.slackforum.de/forum/index.php?t=msgth=2706start=0PHPSESSID=anenqvsmugl3u985m8366f55i3 Search for the filename - there is a download link. Nils Is there any way we can get this posted on http://www.linuxtv.org/downloads/firmware/ it really is a pain to find thing across multiple languages buried in forums :). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
Hi Patrick, Thank you for your the response. I've read that the Starbox one displays the model as 7021 while the Starbox II shows 7021A. Not sure how accurate that is. Thanks again, I'll go get a Starbox II then. Greg On Nov 2, 2007 11:01 AM, Patrick Boettcher [EMAIL PROTECTED] wrote: There are two versions. Only the StarBox2 is supported. There is no way (at least I don't know it) to figure out whether you have a 2 or a 1. If it it does not work I guess you have a StarBox1. Patrick. On Fri, 2 Nov 2007, Greg Suarez wrote: Which kernel version are you using? I'm running 2.6.20 on Ubuntu Feisty. Mine isn't getting disconnected immediately but my scan always fails and I get usb in operation failed. (-110), looks like the errno is ETIMEDOUT from usb_start_wait_urb(). Has anyone gotten the TwinHann Starbox (7021) working? Thanks, Greg On Nov 2, 2007 4:06 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am also having an issue getting the TwinHan Starbox to work. However aside from the kernel providing a link to a firmware that does not exist... the interface immediately gets deinitialized and disconnected when I connect it see dmesg excerpt. Oct 24 16:41:31 heartofgold kernel: [117625.772000] usb 1-4: new high speed USB device using ehci_hcd and address 3 Oct 24 16:41:32 heartofgold kernel: [117625.904000] usb 1-4: configuration #1 chosen from 1 choice Oct 24 16:41:32 heartofgold kernel: [117626.02] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware Oct 24 16:41:32 heartofgold kernel: [117626.052000] dvb-usb: downloading firmware from file 'dvb-usb-vp702x-02.fw' Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Oct 24 16:41:32 heartofgold kernel: [117626.12] usb 1-4: USB disconnect, address 3 Oct 24 16:41:32 heartofgold kernel: [117626.12] DVB: registering new adapter (TwinhanDTV StarBox DVB-S USB2.0 (VP7021)). Oct 24 16:41:32 heartofgold kernel: [117626.12] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold last message repeated 5 times Oct 24 16:41:32 heartofgold kernel: [117626.12] dvb-usb: MAC address: 00:00:00:00:00:00 Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.124000] vp702x: usb out operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] vp702x: usb in operation failed. (-19) Oct 24 16:41:32 heartofgold kernel: [117626.14] input: IR-receiver inside an USB DVB receiver as /class/input/input6 Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: schedule remote query interval to 400 msecs. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. Oct 24 16:41:32 heartofgold kernel: [117626.14] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully deinitialized and disconnected. Oct 24 16:41:32 heartofgold kernel: [117626.268000] usbcore: registered new interface driver dvb_usb_vp702x --- Original Message --- From: [EMAIL PROTECTED]:[EMAIL PROTECTED] Sent: 11/2/2007 6:53:57 AM To : linux-dvb@linuxtv.org Cc : Subject : RE: [linux-dvb] dvb-usb-vp702x-02.fw Greg Suarez wrote: I'm trying to get my TwinHann Starbox (7021) to work but the driver is looking for the firmware dvb-usb-vp702x-02.fw but I can only find dvb-usb-vp702x-01.fw. Does anyone know where I can get a hold of the -02 firmware? Found it on a German forum: http://www.slackforum.de/forum/index.php?t=msgth=2706start=0PHPSESSID=anenqvsmugl3u985m8366f55i3 Search for the filename - there is a download link. Nils Is there any way we can get this posted on http://www.linuxtv.org/downloads/firmware/ it really is a pain to find thing across multiple languages buried in forums :). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: The design goals for me are: 1) We stop trying to predict what the API will need in 5 years, and focus on building a very simplistic ioctl API for getting and setting generic frontend properties, it should be basic enough to deal with any new modulation type (or advanced tuner) that we know of today. 2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND) to a looser command/sequence definition. (Thereby stepping away from fixed structs that define the ABI). With two new ioctls (get_property/set_property) and a simple property struct which specifies how generic types are passed to/from the kernel. 3) A userland library _may_ offer a number of helper functions to simplify in terms of applications development, turning this: [..] command.id = END_TRANSACTION ioctl(SET_PROPERTY, command); Into a more human readable form like this: int tune_8vsb(frequency); Even before you thought even, we (myself and adq) have had an implementation to do this, in kernel it was called mti and the userspace interface called libdvbapi. The sample implementation was with the stv0299 and the ttpci card. This was more than 18 months back. The reason for that cause was another specific demodulator. You can read through the archives, on the same, tuning algorithms and so on. In that scenario, we additionally had the tuning algorithm in userspace too, simplifying many other things. Interesting, I'll dig back and read. Why didn't it gain any traction? It was done around 70%, but then the STB0899 got a higher priority. Markus's userspace approach is also similar, not much different, small differences. ;-) When so much is done, then i would say better it is to move all frontends to userspace as well. but mti/libdvbapi had the best of both the worlds, It was to be working with both in kernel and userspace drivers, quite flexible. The whole thing started of with a small thing, an idea from Johannes about a simple user space tuning. I had even pointed it to Greg KH when he introduced UIO and eventually it was on LWN as well. probably if you Google you might find the same. Greg was happy to see such things which were completely different. It wasn't that it didn't gain any traction, Ralph at that time advised me to pay more attention to DVB-S2/STB0899. Hmm. This is quite possibly the biggest 'crack in the floor / stuff fell through' story that I've heard of in quite a while. If you have had crack, then you will see cracks everywhere . :) I don't understand Ralph's involvement in your Linux projects, and why the alternative direction mattered to him. If you see the initial proposal, there were so many people involved, Ralph too, he used to hang out on IRC along with us. Please see the original post when the STB0899 driver was made public. There were reasons why it mattered to him. He was also involved in an STB0899 based project, which he can disclose if he is interested. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Working DVB-S USB Device
Hi All, I'm looking for a DVB-S device that works with the linux-dvb drivers. Can you send me the name and model of the devices you have confirmed to work? I've looked at the linuxtv.org list but don't know how up to date that list is. Thanks for your help. Greg Suarez ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: simpler/smaller interface. I made reference to this in my first HVR4000 patches where massive amounts of code were potentially being duplicated. Please point out the duplication. At the time, the demod drivers had to provide a set_frontend() and set_params() ops method. That meant two entry points into every driver (with differing args), the same was true for many other entry points that took the new structures. Btw, before you start complaining about other's code, It is always better to have a look at your own code to have a feel where you are standing. Because of some of your changes we have had long arguments by Markus, (on locking) well this was in kernel. What you are complaining is something not even applied to the kernel and very much pre alpha. Just to talk back on the same tongue. You asked for my feedback. So, I gave you all the feedback based on the last time I reviewed your code, I even said that these issue may already be fixed. (Explicitly opening myself up for attack - should you chose). This review took place prior to you removing it from LinuxTV and you doing your own thing. Why are we arguing Manu when we both want the same thing to happen, for multiproto to get traction? Have I not always been polite in all of my offers of help, prior to my recent bitterness and/or sarcasm? Look at the situation from an outsiders perspective. Whenever the subject of finishing the multiproto work comes up, the conversation never ends in a happy place. I keep repeating myself when I'm say this: Nothing would make me happier than seeing multiproto in a test tree, where people inside (and outside) of the LinuxTV team can contribute. It would be a significant step forward but whenever this subject is raised, regardless of how politely I try to ask, it never results in a good conversation. I wish we could find a better way to communicate (and/or work together), for the good of everyone. - Steve Resend. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: Manu Abraham wrote: Steven Toth wrote: simpler/smaller interface. I made reference to this in my first HVR4000 patches where massive amounts of code were potentially being duplicated. Please point out the duplication. At the time, the demod drivers had to provide a set_frontend() and set_params() ops method. That meant two entry points into every driver (with differing args), the same was true for many other entry points that took the new structures. Btw, before you start complaining about other's code, It is always better to have a look at your own code to have a feel where you are standing. Because of some of your changes we have had long arguments by Markus, (on locking) well this was in kernel. What you are complaining is something not even applied to the kernel and very much pre alpha. Just to talk back on the same tongue. You asked for my feedback. So, I gave you all the feedback based on the last time I reviewed your code, I even said that these issue may already be fixed. (Explicitly opening myself up for attack - should you chose). Ok, is it fixed now ? Why should i attack you if you commented on an issue ? If it is some nonsense then sure there is a reason. This review took place prior to you removing it from LinuxTV and you doing your own thing. There was nothing called removing from LinuxTV. There were reasons why i moved my trees. * Johannes expressed concern over crappy trees, such that it was a hurdle for him to backup everything. No one paid heed to his request. (i did explain this earlier too) For me, at that time i had a local high end server, for which push was easy, which the server had lot of free space. Not only the push time reduced for me, but on a small note, i did help by removing whatever clutter i could. (For some people, it is the assumption that having too many trees in a public place is like showing that they work on so many different things. Cheap publicity.) * When you work with a tree (different people work different ways) a shell can be very handy to quickly export a patch, apply to another tree etc. Earlier the people around were easier to work with, before the merger of the trees, look at any discussion, almost like clockwork, one idiot who doesn't even have a single line of code, from V4L land talks crap about the DVB developers. * For the users also it was easy rather than looking at those countless crap of repositories. Ask any normal sane user whether they feel comfortable. But as usual, you were one of the chaps, who just looked at your own convenience or whatever you felt like. Why are we arguing Manu when we both want the same thing to happen, for multiproto to get traction? I gave you the same options what i told Johannes, But you wanted to act different. Is it not true ? Have I not always been polite in all of my offers of help, prior to my recent bitterness and/or sarcasm? Were i any different from your state as you mentioned of, earlier ? When you were struggling to get pilots working, did i got specs from one of my own clients to help you out how it worked for your case, did i not ? What changed ? Why did i have to help you ? I just don't have anything specific issues to anyone, but what i receive, i just give it back in the same platter. Do you think any of the people around will put in so much effort to help you so ? It could have been that you don't find any value in all those help. Look at the situation from an outsiders perspective. Whenever the subject of finishing the multiproto work comes up, the conversation never ends in a happy place. Why does it happen that way ? You need to understand what's in there and what's not. Did i not explain clearly what's the TODO and COMPLETE things etc. Well, before you start arguing on a subject, you need to understand the subject. Otherwise it will sound exactly like a marketplace. For this one needs to put in efforts to understand, nothing comes FOC. When you think that let's have an argument and let's get ideas from that discussion, without any understanding of the same, many a times it results in sparks. As i said earlier there are more demods on the way, if we screw up, all those devices will be screwed up, like the DVB-T HP/LP. But this is something bigger than that. We are talking about 3 different modes, as far as i can think. I will tell you why also. The DVB-S2 specification is damn crazy. It has backward compatibility stuff to incorporate for the old stuff, the current stuff and things yet to come. It is quite a hard specification. When Johannes stated: handling multiple streams is as simple as setting a stream id, well it is not that i blame him, the specs look that way. There are couple of ways the same thing is done for example. You apply a wrong one and the API is screwed
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Fri, Nov 02, 2007, Steven Toth wrote:
The design goals for me are:
1) We stop trying to predict what the API will need in 5 years, and focus
on building a very simplistic ioctl API for getting and setting generic
frontend properties, it should be basic enough to deal with any new
modulation type (or advanced tuner) that we know of today.
good one
2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND)
to a looser command/sequence definition. (Thereby stepping away from fixed
structs that define the ABI). With two new ioctls
(get_property/set_property) and a simple property struct which specifies
how generic types are passed to/from the kernel.
no so good
3) A userland library _may_ offer a number of helper functions to simplify
in terms of applications development, turning this:
many people seem to hate ALSA, there's a lesson to be learned here
command.id = BEGIN_TRANSACTION
ioctl(SET_PROPERTY, command);
command.id = SET_MODULATION
command.arg = 8VSB
ioctl(SET_PROPERTY, command);
command.id = SET_FREQUENCY
command.arg = 59125
ioctl(SET_PROPERTY, command);
command.id = VALIDATE_TRANSACTION
ioctl(SET_PROPERTY, command);
command.id = END_TRANSACTION
ioctl(SET_PROPERTY, command);
Into a more human readable form like this:
int tune_8vsb(frequency);
It's a basic approach, we trade off multiple ioctls (at a very low rate)
entering the kernel, for a very flexible tuning approach to frontend
control.
Once you have those tag/value pairs, you could batch them
together in an array and pass them down in one ioctl. This
avoids the ugly transaction stuff and keeps it atomic.
And I think it wouldn't look too ugly in user code, e.g.:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
But there's more work to do:
- need for .val being variable lenght or a union of different types?
- extend existing enums or define new ones for MODULATION etc?
- how to do FE_GET_FRONTEND
- etc.
I'm sure we could have endless debates over the details ;-)
I hope many others will comment which approach they like better,
or which one they think will be ready for prime time sooner.
Personally I don't care either way. I spent a lot of time discussing
the multiproto API and I believe it could be ready soon with
a few minor tweaks. OTOH this tag/value approach seems to be
more flexible, but who knows how much work it'll take to complete.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Sat, Nov 03, 2007, Manu Abraham wrote: When Johannes stated: handling multiple streams is as simple as setting a stream id, well it is not that i blame him, the specs look that way. There are couple of ways the same thing is done for example. You apply a wrong one and the API is screwed and you have to bear that brunt for a long time to come. Hey, if you know more than I do then please explain it to me. Until proven wrong I continue to believe that there isn't any more magic to handling multi stream mode than choosing one of them by writing the stream id into the appropriate demod register. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
Greg, I have the 2.6.22-14 kernel under Gusty. I have tried fedora slackware knoppmyth and a gentoo derivation. I am unsure if i have the starbox or the starbox 2 I have had some progress. The firmware I had downloaded was messed up. I have tried the one of the german site that was linked to before. I am now able to get the unit to register and create a /dev/dvb/adapter. I seem to be getting the same error as you involving the -110. Any eta on support for the starbox. I am more than willing to help out in any way. Bus 001 Device 005: ID 13d3:3207 IMC Networks Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x13d3 IMC Networks idProduct 0x3207 bcdDevice2.09 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 100 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled [628036.456000] usb 1-3: new high speed USB device using ehci_hcd and address 5 [628036.588000] usb 1-3: configuration #1 chosen from 1 choice [628036.588000] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware [628036.60] dvb-usb: downloading firmware from file 'dvb-usb- vp702x-02.fw' [628036.62] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. [628036.62] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [628036.62] DVB: registering new adapter (TwinhanDTV StarBox DVB- S USB2.0 (VP7021)) [628036.624000] dvb-usb: MAC address: 00:08:ca:15:26:48 [628036.644000] vp702x: system string: USB702X: [628036.644000] DVB: registering frontend 0 (Twinhan DST-like frontend (VP7021/VP7020) DVB-S)... [628036.648000] input: IR-receiver inside an USB DVB receiver as / class/input/input7 [628036.648000] dvb-usb: schedule remote query interval to 400 msecs. [628036.648000] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. [628501.80] vp702x: usb in operation failed. (-110) [EMAIL PROTECTED]:/dev/dvb/adapter0# ls -latr total 0 crw-rw 1 root video 212, 7 2007-11-02 17:05 net0 crw-rw 1 root video 212, 3 2007-11-02 17:05 frontend0 crw-rw 1 root video 212, 5 2007-11-02 17:05 dvr0 crw-rw 1 root video 212, 4 2007-11-02 17:05 demux0 drwxr-xr-x 3 root root 60 2007-11-02 17:05 .. drwxr-xr-x 2 root root 120 2007-11-02 17:05 . [EMAIL PROTECTED]:/dev/dvb/adapter0# scan ~/61.5w scanning /root/61.5w using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 12224000 V 2750 3 tune to: 12224:v:0:27500 WARNING: tuning failed!!! tune to: 12224:v:0:27500 (tuning failed) WARNING: tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Hi Patrick, Thank you for your the response. I've read that the Starbox one displays the model as 7021 while the Starbox II shows 7021A. Not sure how accurate that is. Thanks again, I'll go get a Starbox II then. Greg On Nov 2, 2007 11:01 AM, Patrick Boettcher patrick.boettcher at desy.de wrote: There are two versions. Only the StarBox2 is supported. There is no way (at least I don't know it) to figure out whether you have a 2 or a 1. If it it does not work I guess you have a StarBox1. Patrick. On Fri, 2 Nov 2007, Greg
Re: [linux-dvb] dvb-usb-vp702x-02.fw
Brandon, Considering that Patrick is one of the developers of the vp702x driver and he says that Starbox I isn't supported so not we can do. Patrick, Are there any plans to add support for the Starbox I? Can we help in anyway? Thanks, Greg On Nov 2, 2007 2:32 PM, Brandon Nolte [EMAIL PROTECTED] wrote: Greg, I have the 2.6.22-14 kernel under Gusty. I have tried fedora slackware knoppmyth and a gentoo derivation. I am unsure if i have the starbox or the starbox 2 I have had some progress. The firmware I had downloaded was messed up. I have tried the one of the german site that was linked to before. I am now able to get the unit to register and create a /dev/dvb/adapter. I seem to be getting the same error as you involving the -110. Any eta on support for the starbox. I am more than willing to help out in any way. Bus 001 Device 005: ID 13d3:3207 IMC Networks Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x13d3 IMC Networks idProduct 0x3207 bcdDevice2.09 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 100 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled [628036.456000] usb 1-3: new high speed USB device using ehci_hcd and address 5 [628036.588000] usb 1-3: configuration #1 chosen from 1 choice [628036.588000] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware [628036.60] dvb-usb: downloading firmware from file 'dvb-usb- vp702x-02.fw' [628036.62] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. [628036.62] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [628036.62] DVB: registering new adapter (TwinhanDTV StarBox DVB- S USB2.0 (VP7021)) [628036.624000] dvb-usb: MAC address: 00:08:ca:15:26:48 [628036.644000] vp702x: system string: USB702X: [628036.644000] DVB: registering frontend 0 (Twinhan DST-like frontend (VP7021/VP7020) DVB-S)... [628036.648000] input: IR-receiver inside an USB DVB receiver as / class/input/input7 [628036.648000] dvb-usb: schedule remote query interval to 400 msecs. [628036.648000] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. [628501.80] vp702x: usb in operation failed. (-110) [EMAIL PROTECTED]:/dev/dvb/adapter0# ls -latr total 0 crw-rw 1 root video 212, 7 2007-11-02 17:05 net0 crw-rw 1 root video 212, 3 2007-11-02 17:05 frontend0 crw-rw 1 root video 212, 5 2007-11-02 17:05 dvr0 crw-rw 1 root video 212, 4 2007-11-02 17:05 demux0 drwxr-xr-x 3 root root 60 2007-11-02 17:05 .. drwxr-xr-x 2 root root 120 2007-11-02 17:05 . [EMAIL PROTECTED]:/dev/dvb/adapter0# scan ~/61.5w scanning /root/61.5w using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 12224000 V 2750 3 tune to: 12224:v:0:27500 WARNING: tuning failed!!! tune to: 12224:v:0:27500 (tuning failed) WARNING: tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Hi Patrick, Thank you for your the response. I've read that the Starbox one displays the model as 7021 while the Starbox II shows 7021A. Not sure how accurate that is.
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Hi Johannes, Johannes Stezenbach wrote: On Sat, Nov 03, 2007, Manu Abraham wrote: When Johannes stated: handling multiple streams is as simple as setting a stream id, well it is not that i blame him, the specs look that way. There are couple of ways the same thing is done for example. You apply a wrong one and the API is screwed and you have to bear that brunt for a long time to come. Hey, if you know more than I do then please explain it to me. Until proven wrong I continue to believe that there isn't any more magic to handling multi stream mode than choosing one of them by writing the stream id into the appropriate demod register. ;-) of course. I have learned it the hard way, that proving a person wrong can be disastrous. Nevertheless i will explain my understanding, eventhough not a great one. :) If you see H.2 and H.3, the difference is between CCM and VCM (Note: that both are cases of multiple TS's) H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream selection in some fashion combined with the merger/slicer where stream id is used. It is a combination of both, rather than a simple stream id. (In this case Rolloff=0.20, Pilots do not exist) in this case the QPSK stream is with FEC 5/6 H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar to H.2 exception that (In this case Rolloff=0.25, Pilots do exist) in this case the QPSK stream is with FEC 3/4 and the 16APSK stream is with FEC 3/4 H.2 is playing with the DVB-S signal level (saturating a transponder) where as H.3 is using differential protection. It is not very clear how both of these are distinguished from each other. Also, on the demod other than the MIS flag (according to the specs) there is another bitfield to select the HP/LP stream, which makes it a bit even more confusing. There exists some clarity, but again there are some clouds which hinder how it looks. I am not really very clear on handling this. We will get more clarifications the coming days. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Manu Abraham wrote: Hi Johannes, Johannes Stezenbach wrote: On Sat, Nov 03, 2007, Manu Abraham wrote: When Johannes stated: handling multiple streams is as simple as setting a stream id, well it is not that i blame him, the specs look that way. There are couple of ways the same thing is done for example. You apply a wrong one and the API is screwed and you have to bear that brunt for a long time to come. Hey, if you know more than I do then please explain it to me. Until proven wrong I continue to believe that there isn't any more magic to handling multi stream mode than choosing one of them by writing the stream id into the appropriate demod register. ;-) of course. I have learned it the hard way, that proving a person wrong can be disastrous. Nevertheless i will explain my understanding, eventhough not a great one. :) If you see H.2 and H.3, the difference is between CCM and VCM (Note: that both are cases of multiple TS's) H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream selection in some fashion combined with the merger/slicer where stream id is used. It is a combination of both, rather than a simple stream id. (In this case Rolloff=0.20, Pilots do not exist) in this case the QPSK stream is with FEC 5/6 H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar to H.2 exception that (In this case Rolloff=0.25, Pilots do exist) in this case the QPSK stream is with FEC 3/4 and the 16APSK stream is with FEC 3/4 Also, i forgot to mention one more thing, 16APSK is denoted as 4 + 12 APSK, (for the demod) not sure why either. H.2 is playing with the DVB-S signal level (saturating a transponder) where as H.3 is using differential protection. It is not very clear how both of these are distinguished from each other. Also, on the demod other than the MIS flag (according to the specs) there is another bitfield to select the HP/LP stream, which makes it a bit even more confusing. There exists some clarity, but again there are some clouds which hinder how it looks. I am not really very clear on handling this. We will get more clarifications the coming days. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Manu Abraham writes: If you have had crack, then you will see cracks everywhere . :) I don't understand Ralph's involvement in your Linux projects, and why the alternative direction mattered to him. If you see the initial proposal, there were so many people involved, Ralph too, he used to hang out on IRC along with us. Please see the original post when the STB0899 driver was made public. There were reasons why it mattered to him. He was also involved in an STB0899 based project, which he can disclose if he is interested. There is a nice little PCIe dual STB0899 reference platform I wrote drivers for. But I don't know if it will ever be built by anybody. Ralph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
rjkm wrote: Manu Abraham writes: If you have had crack, then you will see cracks everywhere . :) I don't understand Ralph's involvement in your Linux projects, and why the alternative direction mattered to him. If you see the initial proposal, there were so many people involved, Ralph too, he used to hang out on IRC along with us. Please see the original post when the STB0899 driver was made public. There were reasons why it mattered to him. He was also involved in an STB0899 based project, which he can disclose if he is interested. There is a nice little PCIe dual STB0899 reference platform I wrote drivers for. But I don't know if it will ever be built by anybody. I have the picture here: http://abraham.manu.googlepages.com/mic.jpg Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Sat, Nov 03, 2007, Manu Abraham wrote: Also, i forgot to mention one more thing, 16APSK is denoted as 4 + 12 APSK, (for the demod) not sure why either. See 5.4.3 Bit mapping into 16APSK constellation. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Johannes Stezenbach wrote: On Sat, Nov 03, 2007, Manu Abraham wrote: Also, i forgot to mention one more thing, 16APSK is denoted as 4 + 12 APSK, (for the demod) not sure why either. See 5.4.3 Bit mapping into 16APSK constellation. Right, didn't think of that. Thanks, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Johannes Stezenbach wrote: On Sat, Nov 03, 2007, Manu Abraham wrote: If you see H.2 and H.3, the difference is between CCM and VCM (Note: that both are cases of multiple TS's) H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream selection in some fashion combined with the merger/slicer where stream id is used. What makes you think there is HP/LP involved? All H.2 says is that two DVB-T streams are transmitted using one DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter could then transmit them on two different frequencies in non-hierarchical mode. (Indeed H.2 says two DTT MUXes at 24 Mbit/s each indicating they are not hierarchical because you can't get that bitrate in DVB-T hierarchical mode. But even if it were DVB-T hierarchical mode it has nothing to do with DVB-S2 backwards compatible mode hierarchical modulation.) It is a combination of both, rather than a simple stream id. (In this case Rolloff=0.20, Pilots do not exist) in this case the QPSK stream is with FEC 5/6 H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar to H.2 exception that (In this case Rolloff=0.25, Pilots do exist) in this case the QPSK stream is with FEC 3/4 and the 16APSK stream is with FEC 3/4 H.2 is playing with the DVB-S signal level (saturating a transponder) where as H.3 is using differential protection. It is not very clear how both of these are distinguished from each other. The thing is that you don't need to distinguish them in the demod API at all. DVB-S2 allows changing modulation parameters with every PLFRAME (for VCM), and the only way this can work is if the demod can figure them out by itself. This works because the PLHEADER is sent with a fixed coding and modulation which is independent from the rest of the PLFRAME. That's why you don't have to worry about the details of the transmission parameters, and why they don't exist in the EN 300 468 S2 satellite delivery system descriptor. (Those details are interesting for the broadcaster, of course, who needs to optimize throughput vs. receiption performance.) Also, on the demod other than the MIS flag (according to the specs) there is another bitfield to select the HP/LP stream, which makes it a bit even more confusing. There exists some clarity, but again there are some clouds which hinder how it looks. I am not really very clear on handling this. We will get more clarifications the coming days. HP/LP is only used for backwards compatible (to DVB-S) mode, as one of two options. A DVB-S receiver will only see the HP stream, the DVB-S2 signal will appear as additional noise to it. OTOH a DVB-S2 receiver can choose between HP and LP. I don't know how this is implemented in DVB-S2 demods, it could be a selection bit in a register, or the demod could output the LP stream in DVB-S2 mode and the HP stream in DVB-S mode. That's how I think it works. Most probably you are right, but i still do not feel comfortable, well will see what the vendor has to say. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Sat, Nov 03, 2007, Manu Abraham wrote: If you see H.2 and H.3, the difference is between CCM and VCM (Note: that both are cases of multiple TS's) H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP stream selection in some fashion combined with the merger/slicer where stream id is used. What makes you think there is HP/LP involved? All H.2 says is that two DVB-T streams are transmitted using one DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter could then transmit them on two different frequencies in non-hierarchical mode. (Indeed H.2 says two DTT MUXes at 24 Mbit/s each indicating they are not hierarchical because you can't get that bitrate in DVB-T hierarchical mode. But even if it were DVB-T hierarchical mode it has nothing to do with DVB-S2 backwards compatible mode hierarchical modulation.) It is a combination of both, rather than a simple stream id. (In this case Rolloff=0.20, Pilots do not exist) in this case the QPSK stream is with FEC 5/6 H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar to H.2 exception that (In this case Rolloff=0.25, Pilots do exist) in this case the QPSK stream is with FEC 3/4 and the 16APSK stream is with FEC 3/4 H.2 is playing with the DVB-S signal level (saturating a transponder) where as H.3 is using differential protection. It is not very clear how both of these are distinguished from each other. The thing is that you don't need to distinguish them in the demod API at all. DVB-S2 allows changing modulation parameters with every PLFRAME (for VCM), and the only way this can work is if the demod can figure them out by itself. This works because the PLHEADER is sent with a fixed coding and modulation which is independent from the rest of the PLFRAME. That's why you don't have to worry about the details of the transmission parameters, and why they don't exist in the EN 300 468 S2 satellite delivery system descriptor. (Those details are interesting for the broadcaster, of course, who needs to optimize throughput vs. receiption performance.) Also, on the demod other than the MIS flag (according to the specs) there is another bitfield to select the HP/LP stream, which makes it a bit even more confusing. There exists some clarity, but again there are some clouds which hinder how it looks. I am not really very clear on handling this. We will get more clarifications the coming days. HP/LP is only used for backwards compatible (to DVB-S) mode, as one of two options. A DVB-S receiver will only see the HP stream, the DVB-S2 signal will appear as additional noise to it. OTOH a DVB-S2 receiver can choose between HP and LP. I don't know how this is implemented in DVB-S2 demods, it could be a selection bit in a register, or the demod could output the LP stream in DVB-S2 mode and the HP stream in DVB-S mode. That's how I think it works. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Am Samstag, den 03.11.2007, 00:56 +0100 schrieb rjkm: Manu Abraham writes: If you have had crack, then you will see cracks everywhere . :) I don't understand Ralph's involvement in your Linux projects, and why the alternative direction mattered to him. If you see the initial proposal, there were so many people involved, Ralph too, he used to hang out on IRC along with us. Please see the original post when the STB0899 driver was made public. There were reasons why it mattered to him. He was also involved in an STB0899 based project, which he can disclose if he is interested. There is a nice little PCIe dual STB0899 reference platform I wrote drivers for. But I don't know if it will ever be built by anybody. Ralph Ralph, thanks for your comment, and you never did let a beginner hang into something, when it starts to become serious, iirc. I ask frankly now. Was there really something going that wrong, that Manu still feels he is right intercepting all from v4l, because Mauro did also some harm to you, likely without any chance to avoid it, simply not knowing what it could be all about, since we were on blank bones after Gerd got it sick? That is what I got told from him when it became, hmm, _quite strange_ previously over a long amount of time and tried to ask ... He told me that Mauro crossed your ways somehow too, but it was that abstract still, that I did not understood where the point of it should ever be and after fair and fully understandable explanations, what he has to face too, it ended up within hours then that we are all idiots ... , because I said Mauro is none. Greetings, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
