Talk:DVB-T USB Devices
How come more HAUPPAUGE that have MPEG2 Hardware support acording to HAUPPAUGE dont apear on this site as working.. HAUPPAUGE WIN TV-PVR USB2 says its got MPEG2 hareware "Turn your PC into a Digital TV recorder. Record TV programmes or home videos using high quality MPEG-2 hardware compression!"
Im looking to build a MythTV system but i want the a good card, good meaning good and cheap. As I've only found one card that this site says has hardware mpeg2 support but it costs about £50
- This wiki is currently focused towards digital devices. The wintv-pvr usb2 is strictly an analog device. Any information on it should appear in the V4L wiki. However, there isn't any info on it even in there. Why not? Because wiki's depend upon user submitted information. No submissions, no information. Its as simple as that. Anyway, you can find info about the pvrusb2 devices on www.isely.net. If you want an internal PCI based hardware mpeg2 encoding solution, then look to IVTV. In the future, the V4L and DVB wikis will be merged, but for now exist as two separate entities. Perhaps after the merger (no exact time frame for completion), the other information sources could also be drawn into the fold. However, that would be entirely up to agreement from those projects. --CityK 20:37, 19 September 2007 (CEST)
I think the Afatech section shouldn't be here, instead a separated page for it and here the devices themselves, for example its difficult to find that the Avermedia Volar X is supported because it doesn't appear in the index. One who knows that it have an Afatech 9015 could find it, but the rest of the users? --howl 2:08, 2 January 2009 (CET)
- I think the whole page is a bloody mess! Its a wonder anyone can find anything on it. Silly DVB-T users, can't they do anything right :P --CityK 03:07, 8 January 2009 (CET)
---
Technaxx DVB S4
Can somebody help me with this stick? There's probably no topic with technaxx products. Yes, they are cheap stuff, but good enough on windows for a little soccer match. When I plug it into the PC, log says "af9015 detected, not supported". MythTV can't find the stick. Installed a propietary driver, which Xubuntu told me to install. Still not recognized. Again a problem with linux =|
Bloody Mess
Regarding the bloody mess... I am willing to put some work into reorganizing it but I would like to have some input before I start. Any suggestions about the format the page should have?
vision
I am a strong advocate of a clean table with maybe only three columns.
| manufacturer | device name | supported |
|---|---|---|
| foo inc. | bar dvb-t receiver | kernel (>=2.6.16)+fw? |
| bar ltd. | goo dvb-t receiver | mainline dvb |
| blah | something tiny | experimental |
| baz | mini foo | mixed |
| baah | itsy | unsupported |
manufacturer is of little informational value to the developers but helps locating devices for the mortal user.
device name would be a link to a page that would hold the whole messy details that now clutter the page. There is no need for one page per device. I'd call the page something like DVB-T_USB_Devices_drivername and current sections with their small tables and the stuff that is above and sometimes below the table would be moved to those pages.
supported would be
- either the a kernel version from which the device is supported out of the box (firmware link where needed).
- mainline if it was supported in the main v4l-dvb repository sources
- experimental if there is a special branch for that device that is not yet merged into main, or an external source repository.
- mixed if the device is sold under the same name with different hardware. details are on the device page to which mixed would also link.
--- Hlangos 01:36, 7 April 2009 (CEST)
- * Have a look at the ATSC device tables.
- * The list of devices should be alphabetical by manufacturer ... as you can see organization along the lines of usb bridge categorization was a HUGE mistake
- * There IS a need for one page per device -- this is precisely where the messy details belong and discussions about that particular device ... devices can be highly dissimilar despite a shared commonality of using the same bridge IC --- and, in fact, even when two devices entirely use the exact same components, they can still differ enough (i.e. GPIO pin configurations) that having a single page does not do justice in regards as to describing how to get either of the particular devices working etc...--CityK 21:46, 12 April 2009 (CEST)
- * The ATSC device table is nice but with 15 devices it is relatively small. In DVB-T USB Devices we are dealing with 70+ devices? Oh, wait, dib0700 alone supports close to 40 devices and that does not count OEM devices that use the same USB IDs. Forget 70+, I guess we are dealing with more than 150 devices. I don't see anybody with the time to research the amount of detail that is in the ATSC table for each of those devices. :-) As that information will definitely be part of a more detailed page (be it a driver centric or a device centric page) I'd rather not duplicate it here.
- * Listing alphabetic by manufacturer is fine with me. How do we deal with OEM devices that differ only by the name printed on the box? I'd list them with that new name but link to the original device page where a short list could show the different names that the device is sold under. After that the technical details of that device could follow.
- * One page per device makes sense if devices differ sufficiently. Sometimes they do, sometimes they don't. Take the "LiteOn USB DVB-T TV Tuner", the "Intuix Tv Tuner Tnt S800" and the "Toshiba USB DVB-T Tuner PX1211E-1TVD". They are all the same device, just rebranded. Then take a look at the MSI_DigiVox_mini_II_V3.0 . The only things on that page special to that device are the remote control parameter and the list of owners. Other than that everything applies to the other af9015 devices and could help users of other af9015 devices a long way. Thats why I'd propose to have the different devices that use more or less the same hardware on one page. There sections could be devoted to the particularities of each device but a general section could deal with driver issues. Having different sections would also create a TOC that would list the supported devices. If we add a page for each any every little device we end up with thousands of pages that hardly contain any information. Not to speak of current information. Or am I too pessimistic about it? Hlangos 14:55, 13 April 2009 (CEST)
- For devices that are simply just OEM rebrands, then you could set up one page for housing the info and redirects for the others to that page. If, in the case like the af9015 devices, the information is equally applicable to the other devices, just use a template for that information and apply it across the different device articles. --CityK 04:55, 17 April 2009 (CEST)
I could do with a little help regarding Templates and Tables. Adding supported information into the comment field is not satisfactory. Also adding the vendor name into the device field is not a good idea in the long run. In a perfect world I would like to have a Table that contains all the information that Template:DvbDeviceCommented entries contain, plus a vendor and supported field. But the only columns visible by default should be vendor, device, and supported. The other fields should be hidden by default but accessible without going into edit mode. If this is possible we might need a new content type for Template:DvbDeviceList named Template:DvbDeviceSupported. This would allow moving most of the content that already is here into one table with minimal editing and without losing information that we currently have in the table. This table should obviously be sortable by the user but I guess thats no big deal. --Hlangos 14:20, 22 April 2009 (CEST)
--
I moved this sample over to the talk page in order to discuss and modify this before adding one more layer of confusion to the article :-)
| Vendor & Model | Added to Kernel |
Frontend | Bridge Interface |
COFDM | Whatever | Analog | Other Features & Comments |
|---|---|---|---|---|---|---|---|
| Anysee E30 |
in Hg since 05.2008 |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
| Anysee E30 Plus |
in Hg since 05.2008 |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
| DViCO FusionHDTV USB DVB-T |
2.6.?? (probably around 2006) |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
| DViCO FusionHDTV DVB-T Dual USB |
2.6.?? (probably around 2006) |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
- I like the general appearance better than the current one. more open space, less crammed.
- agreed
- formating information naturally needs to go into a template so that editors can concentrate on content.
- yes, I agree that ideally one should just be able to add their content without worrying about table formating etc etc
- sortable table is the way to go but I've read that there are limitations regarding colspan and rowspan. So we are a little limited there but sorting capability is worth it.
- yes, sortable definitely ... I am ignorant of the limitations
- here's the detailed information on that: http://en.wikipedia.org/wiki/Table_markup#Sorting
- we definitely need to hide columns. Here is an example of how to do it with CSS and JS. I am not sure if we can do that in
a mediawiki though. As an alternative we may be able to put the table content into a separate article and include that article into two different articles. One article for the lowly user that contains a table template that would hide the details and one article for the developer or interested geek that would show all the details. The data for both articles would be kept in one place only and therefore be much easier to maintain. I think Conditional tables are one way of getting the result we need.
- I don't know about "definitely" need to hide columns -- it all depends on the amount of detail that is to be included. The e.g. you provided shows some promise for some applications. No idea about ability to incorporate it into Mediawiki, though (I'm answering as I go), at a glance, it looks like you may have discovered how to later on. Okay, I see where you are going ... and yes, there is a lot of utility in that idea ...
- After working on the first scale try at HLPlayground2 I realized that a lot of data is duplicated between the overview table at DVB-T USB Devices and the device specific pages and most of the duplicated data was out of sync. I would therefor suggest to include a lot of detail in the data but only show a subset of this detail on the overview page. The device article would contain a wider view (more columns) of the table but only the relevant rows (i.e. the rows that contain the device(es) that the article is about). Then, if e.g. somebody opens up his device and finds out exactly which type of demodulator is inside, he can decide to edit the table that is embedded in a device specific article or the overview table on DVB-T USB Devices. In either case he gets forwarded to the data storing template and thus updates the data wherever it is used.
- regarding details:
- how much detail do we want/need here? In my vision this page becomes the go-to-place for lowly linux users to check if a device is supported at all (preferably before buying it). details for driver developers should either be hidden by default or go to a separate page. IMHO the default would be vendor, model, supported, picture. Using 'supported' instead of 'supported since' would allow to include information on unsupported devices in the same dataset. I've seen devices in the unsupported section of the page that already had experimental support. Having them in the same dataset would avoid some duplicates and wrong entries.
- i like the tuner, demodulator in one column and usb bridge in separate columns. looks good and especially the separate usb bridge allows to sort in a way that is similar to the way the page is organized now.
- I think that your default case would be too limited unless its made really clear that the table is expandable/collapsable for other details ... a lot of people like seeing the IC info and the ability to compare it across devices -- that said, I note that there is a wider audience then just "lowly linux users" on one side and "driver developers" on the other side; specifically, plenty of grey users in between ... but anyways, that's the whole point of the exercise -- nailing down what an acceptable level of detail would be (i.e. appreciable to the target audiences) ... this is probably something that would be best answered by a wider audience (like the mail list -- a poll of what people deem appropriate .. and hopefully not run into the classic case of too many differing opinions over what is considered appropriate. .... just remembered something else too, that is entirely applicable to this discussion -- M.Krufky had expressed, several months back, an interest in integrating a support database. I didn't really have a feel for what he was intending, but would hate to waste either his or our time by making large sets of changes for nothing -- as its my opinion that the easist to integrate and manage (both from user and admin points of view) solution should be adopted .... I haven't heard anything further on this, so will have to check with him
- Ok, and please point him to the HLPlayground2 page.
- on "supported" ... this is a difficult point, cause sometimes support means partial (like as in OTA digital is now supported, but we haven't yet added cable yet or analog support ) ... though, even when explicitly stated, I still see end users making mistakes along the lines of "I thought this device was fully supported ? blah blah blah ")...
- I guess we'll have to live with that kind of misunderstanding. The comment field could be used for remarks and the device specific article should handle the rest.
- I think that your default case would be too limited unless its made really clear that the table is expandable/collapsable for other details ... a lot of people like seeing the IC info and the ability to compare it across devices -- that said, I note that there is a wider audience then just "lowly linux users" on one side and "driver developers" on the other side; specifically, plenty of grey users in between ... but anyways, that's the whole point of the exercise -- nailing down what an acceptable level of detail would be (i.e. appreciable to the target audiences) ... this is probably something that would be best answered by a wider audience (like the mail list -- a poll of what people deem appropriate .. and hopefully not run into the classic case of too many differing opinions over what is considered appropriate. .... just remembered something else too, that is entirely applicable to this discussion -- M.Krufky had expressed, several months back, an interest in integrating a support database. I didn't really have a feel for what he was intending, but would hate to waste either his or our time by making large sets of changes for nothing -- as its my opinion that the easist to integrate and manage (both from user and admin points of view) solution should be adopted .... I haven't heard anything further on this, so will have to check with him
- the analog feature might as well go into the comments. there are few devices and analog tv is going to go the way of the mammoth anyway. I liked analog a lot but .. I come to bury Caesar, not to praise him.
- careful -- analog TV is just one aspect, analog video inputs is another ... additionally, I'd think that the number of hybrid devices is more then a few
- Hmmm, ok. We can add a separate variable for it in the data set but in an overview table I would rather make it show up in the comments. ParserFunctions would allow us to only add a Has analog input comment where analog input is present instead of adding Analog input: YES/NO to every device.
- careful -- analog TV is just one aspect, analog video inputs is another ... additionally, I'd think that the number of hybrid devices is more then a few
- If we accept a comments field here (instead of "on the device's page"), we might as well accept pictures. I'd prefer a separate column for it with size and frame settings in the template. Pictures may help users identify their device, or even more important, stop them the frustration when buying a device who's name is the same as a supported one but the device is completely different one. (Yes, there are devices that look the same but aren't but I like pictures, ok ? :-)
- actually, after seeing the pics in the tables you constructed, I like them in the table ... only concern here is that for a good number of devices there might not be a pic, nor do we really want to have users start uploading propietary pics (i.e. ripped of the vendors websited without permission) ... yeah, comments section should probably go on the device page
The result would look something like this:
| Vendor | Model | Supported | Frontend | Bridge Interface |
COFDM | Whatever | Analog | Other Features & Comments | Picture |
|---|---|---|---|---|---|---|---|---|---|
| Anysee | E30 | in Hg since 05.2008 |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
|
| Anysee | E30 Plus | in Hg since 05.2008 |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
|
| DViCO | FusionHDTV DVB-T Dual USB | 2.6.?? (probably around 2006) |
|
some usb bridge | ✔ Yes | ? | ✘ No |
|
| Vendor | Model | Supported | Picture |
|---|---|---|---|
| Anysee | E30 | in Hg since 05.2008 |
|
| Anysee | E30 Plus | in Hg since 05.2008 |
|
| DViCO | FusionHDTV DVB-T Dual USB | 2.6.?? (probably around 2006) |
- I liked the first example ... not big on the, condensed, second
variable based data selection
I tried to understand [1] but it gives me a headache. :-(
- Lol. Yes, I know what you mean -- I try to avoid reading the mediawiki stuff unless necessary
I want to find a way to separate data and presentation. I can't seem to find a way that will result in a page where editors would only have to deal with the parameters for a new device and users have two different views on the data... something like a structure like this
short table
{{DeviceListFrame
| content = {{DeviceListData}}
}}
full detail table
{{DeviceListFrame
| detail=full
| content = {{DeviceListData|detail=full}}
}}
Now 'DeviceListFrame' would decide based on the existence of detail whether to include headers for the detail columns. 'DeviceListData' would contain all the parameters like this:
{{Device
| detail={{{detail}}}
| vendor=[[DViCO]]
| device=[[DViCO]]<br/>[[DViCO FusionHDTV USB|DViCO FusionHDTV DVB-T Dual USB]]
| type=USB2.0
| fw=dvb-usb-bluebird-01.fw
| comment=Supported in Kernel since 2.6.?? (probably around 2006)
| pic=[http://www.fusionhdtv.co.kr/ENG/Products/DualDigital.aspx]
}}
{{Device
| detail={{{detail}}}
| device=Easylite<br/>[[Easylite DVB-T stick|Easylite DVB-T Stick USB 2.0]]
| type=USB2.0
| comment=Supported in ?? since ??
}}
Where detail is passed on to the Device template that would finally render the table row.
- This is why I have to get back to M.Krufky, as his idea for the database was essentially that -- easy to add info, no worries/hassles on editing, and lots of database searchability goodness
I tried to implement it in HLPlayground1 but it seems like the Extension ParserFunctions is missing. Without it, there is no if-then-else branching and without branching there is no different usage of the same data.
template based data selection
There still may be another possibility without the ParserFunctions extention. It would mean to pass a template name as a parameter as described here. We would have two different templates for the table header and the table content rows each. One for the table with details. one for the table without details. The template name would have to be passed down to 'DeviceListData' and instead of being used as a value for the detail parameter (detail={{{foo}}}, it would name the template i.e. 'Device' would be replaced by {{{foo}}}.
- Lol. As Johannes said -- Template Voodoo!
- Yeap. Template Voodoo goes a long way. It helps to do get vertical slices (columns) out of the table. Some examples are on HLPlayground2. To go all the way I would also need the Extensions ParserFunctions and StringFunctions. Those would allow to do the horizontal (row wise) slices that I mentioned above.
proof of concept
Can be found at HLPlayground2.
Eureka! I managed to do it as described above. I use ONE data storage with named parameters and for both types of view I use two templates. One for the table headers and one for the table rows. The only thing that is slightly bothering, is the fact that when editing the data you don't get a nice preview. But I guess I can fix that with some noinclude stuff. --Hlangos 17:26, 24 April 2009 (CEST)
- Preview while editing doesn't work since (at least the way i tried it) it requires inclusion of the page that you are still editing. Thus your preview will show the last published state, not the one your are currently producing. But it's better than nothing and keeps the data page from looking crapy. --Hlangos 11:10, 28 April 2009 (CEST)
- Okay, I'm a little confused from above, but I'll head over to the playground, as it looks like you've continued/expanded upon things there --CityK 06:07, 5 May 2009 (CEST)
- Yes. Have a look at HLPlayground2. It contains the proof of concept tables as well as a first scale try with tables of several different degrees of detail. I will probably not add more data until there is some consensus about the degree of detail that the data template should contain and some feedback regarding the semantics. --Hlangos 13:19, 5 May 2009 (CEST)
TOC misleading
the table of contents is very misleasing as it lists only a very small part of the devices supported. I would suggest to remove the toc alltogether and instruct people on how to use their browsers search function.
---Hlangos 13:29, 7 April 2009 (CEST)
- The TOC should contain two sections: Supported and Unsupported (which it does). Correcting the improper entries/properly formating within those sections (as discussed above) would resolve any case of the TOC on this page appearing to be misleading. --CityK 21:46, 12 April 2009 (CEST)
- Ok, then we need to find a way to separate paragraphs with information on different supported/unsupported devices without resorting to sections. Or is there a way to limit the depth of the TOC that is displayed? Hlangos 14:55, 13 April 2009 (CEST)
Devices Order By
There are some devices order by their modulator chip and other ones only by their complete Vendor plus Model name. Now that there is a consistent way to have the information thanks to Hlangos I think that the best order for this page could be first vendor section and then the USB DVB-T models for the vendor, it could be more easy for the users that don't know anything about the chips of his/her product to find if it's supported or not. --howl 18:49, 27 September 2009 (UTC)
- Agreed. Order by "vendor + model" should be the default. Unfortunately this can't be done by default. So we'll have to reorganize the data. I'd like to leave that sorting until all the data on this article has been ported over.
- One advantage of having it organized as it is right now (by driver), is the relative ease with which one can add devices that are already in the driver but still missing in the data here. I already did that for the af9005 and af9015 driver and it wasn't all that painful. Just head over to the linux kernel git repository and take a look at the drivers to see whats currently supported. If you feel extra nice, take a look at the driver's history to find out when support for a certain device was added. I've just found out (well, googled) a way to find the kernel version that a certain commit was added to. Just go to the commitdiff than on the raw link. Now you'll see an X-Git-Tag: header with the relevant information. (The manual way is to have a look at the commit date and then compare it with the timestamps of kernel ChangeLog files and hope for the best :-) ) --Hlangos 15:55, 29 September 2009 (UTC)
- I will try to help, but don't promise anything xD --howl 00:43, 1 October 2009 (UTC)
Devices edit link
Great! BTW, what do you think of the e links in the last column of the low detail table that I included in the Afatech AF9015 article. I am not yet happy with the space that it wastes. Maybe I'll try to shrink it down a bit or merge it into one of the other columns. --Hlangos 10:05, 1 October 2009 (UTC)
- Yesterday I was thinking about changing the e with a little typical block+pencil icon. I not sure about merging it with another column because the edit will be for the whole row of a given device affecting the edit to all the columns. Another possibility could be an approach like the DVB-T USB page, but with a link relative to the AF9015 section in this case [2]. With the whole edit approach there is a problem, could not be the same solution for all the tables, for example, a table with DVB-T USB devices for the same vendor, there is no way to link to edit only the pertinent devices, or if when finish the devices porting if the order is changed to manufacturer first, the problem will be when trying to provide edit link for whole devices of a chipset. --howl 12:50, 1 October 2009 (UTC)
- Changing the "e" to an icon would be great! Go for it! I would have done it but I was to lazy to hunt for an icon. I guess the kde and gnome projects both have lots of useful icons that we are allowed to use. And you are right about the problems that merging would mean in regard to usability.
- I tried to implement a direct edit link like the one you included up there. The problem is that those links are always "numbered" and if somebody adds or removes a device, the links will break. That was the reason for making one subsection per device in the data page, and part of the reason to add the "did" field. Subsections can be linked to by name and making this name part of the device record made it possible to use the name in templates that render the table rows.
- I don't think we need the capability to edit a group of devices that badly. I can live without it. In cases where you need to edit a whole set of devices you usually do "search and replace" type of edits and those are a pain in the browser anyway. (I copy the whole page content from the wiki's edit window over to a descent text editor, make my changes there and paste the result back into the wiki's edit window. Than I do a quick "Show changes" to make sure I only made the changes that I wanted, and thats it.)
- Cheers --Hlangos 16:28, 1 October 2009 (UTC)
- Its Looking good --CityK 04:09, 2 October 2009 (UTC)
- Trying to make the wiki image title to work but it doesn't
[[Image:Edit-16x16.png|link=Template:USB Device Data#{{{did|}}}|Edit Entry]]this code works in the wikipedia's wikimedia, but here the title shown is the url instead "Edit Entry". Tomorrow I will try to find something about it, one solution could be hardcode it in html, but, I prefer to avoid it. --howl 00:37, 2 October 2009 (UTC)- I tried this
[[Image:Edit-16x16.png|link=Template:USB Device Data#{{{did|}}}|alt=Edit Entry]]
- But it doesn't work ( at least not in firefox ) maybe you'll have to do some html as I had done before ... [3]
- Could be a MediaWiki issue in this version? Edit links of images as core feature of MediaWiki has been introduced in 1.14. Don't know which version uses wikipedia but the sintaxis works well there. I have tried to use span but it works with text and not with images, also I have tried a css trick specified in MediaWiki to make links with images in 1.14 pre but the only possible caption with the css method is the same url. --howl 13:56, 3 October 2009 (UTC)
- Ah, well. It's not that important. The nice thing is, that it can be fixed in a single place. BTW: This mediawiki installation is version: 1.39.11 --Hlangos 07:02, 4 October 2009 (UTC)
- Could be a MediaWiki issue in this version? Edit links of images as core feature of MediaWiki has been introduced in 1.14. Don't know which version uses wikipedia but the sintaxis works well there. I have tried to use span but it works with text and not with images, also I have tried a css trick specified in MediaWiki to make links with images in 1.14 pre but the only possible caption with the css method is the same url. --howl 13:56, 3 October 2009 (UTC)
- I tried this
- Trying to make the wiki image title to work but it doesn't
Adding supported devices from kernel sources
In order to complete the list of supported devices I've gone through some of the dvb-usb kernel drivers.
Here's a reduced list of files that need to be checked and double checked (to include the stuff learned during the first round and maybe to either create similar articles for the non-"DVB-T USB" devices supported by those drivers) :
| Filename | Checked | Second check |
|---|---|---|
| a800.c | ✔ Yes | ✔ Yes |
| af9005.c | ✔ Yes | ✔ Yes |
| af9015.c | ✔ Yes (one DVB-T PCI device?) | ✔ Yes added one PCI32 device |
| anysee.c | ✔ Yes (also DVB-C DVB-S) | ✘ No |
| au6610.c | ✔ Yes | ✘ No |
| ce6230.c | ✔ Yes | ✘ No |
| cinergyT2-core.c | ✔ Yes | ✘ No |
| cxusb.c | ✔ Yes 12 DVB-T (1 DMB-TH seems to be listed already as MagicPro) | ✘ No |
| dib0700_devices.c | ✔ Yes (also added one PCI and two ATSC devices) | ✔ Yes |
| dibusb-mb.c | ✔ Yes phew .. almost 30 devices | ✘ No |
| dibusb-mc.c | ✔ Yes | ✘ No |
| digitv.c | ✔ Yes | ✘ No |
| dtt200u.c | ✔ Yes | ✘ No |
| dtv5100.c | ✔ Yes | ✘ No |
| dw2102.c | ✔ Yes DVB-S DVB-C | ✘ No |
| friio.c | ✔ Yes ISDB | ✘ No |
| gl861.c | ✔ Yes | ✘ No |
| gp8psk.c | ✔ Yes DVB-S | ✘ No |
| m920x.c | ✔ Yes | ✘ No |
| nova-t-usb2.c | ✔ Yes | ✘ No |
| opera1.c | ✔ Yes DVB-S | ✘ No |
| ttusb2.c | ✔ Yes DVB-S | ✘ No |
| umt-010.c | ✔ Yes | ✘ No |
| vp702x.c | ✔ Yes DVB-S | ✘ No |
| vp7045.c | ✔ Yes | ✘ No |
I'll update this table as I go along.
If somebody feels like helping out, please mark the file above as "work in progress" to avoid duplicate work.
Translating source files into entries in the device database is quite easy.
Just look for .devices and .name in the source file and then look above for .frontend_attach and .tuner_attach for further information on the hardware.
Merge data
Next task will be to merge the date on this page with the database and removal of those devices from this page. I guess I'll better put just one big mid-detail table in here and clean up the rest of the mess as time permits.
Thinking beyond USB devices
I have renamed the "type" field into "hostinterface" it may now cover not just "USB1.1" and "USB2.0" but also "ISA" "PCI32" "PCI64" "PCI-X" "PCIe" "PCMCIA/PCCARD" "CardBus" "ExpressCard" "IEEE1394"
The information about which device is "USB1.1" or "USB2.0"-only and which device does both is probably wrong in 80% of the cases. I tried to err on the conservative side, so devices that are labled as USB2.0 may also work on USB1.1 if they have a PID filter and there is support for it in the driver/firmware.
Tinkering with multi selection
I've now created a row rendering template that takes zero or more (currently up to four) attribute-value pairs to do AND-based filtering on.
So you can create tables that list all hostinterface:USB1.1 devices that use the demodulator af9005 and where made by the vendor TerraTec.
You can also call it without any filter so that it returns all rows. So the non filtering templates were replaced.
This is another step towards one big table with all the device data ... if mediawiki can handle it :-) (The device page for USB DVB-T devices is already over 100kb but apart from slightly longer loading times, it seems to hold.)
Thinking beyond DVB-T
I already think about adding another field, called "supported broadcast standards" to unify the structure a little further. Possible values would be the analog encodings "PAL" "NTSC" "SECAM" as well as digital encodings "DVB-T" "DVB-C" "DVB-C2" "DVB-S" "DVB-S2" "DVB-H" "DVB-SH" "ATSC" "ATSC-M/H" "ISDB-S" "ISDB-T" "1seg" "ISDB-C" "SBTVD/ISDB-Tb" "DMB-T/H" "ADTB-T" "CMMB" "DMB-T" "T-DMB" "S-DMB" "MediaFLO". Even "fm" and "am" radio could be included in this list.
- Update: Been there, did that, looks ok.
- Actually I added ANALOG-PAL, ANALOG-NTSC, and ANALOG-SECAM, and RADIO-FM, and RADIO-AM, that will make it easier to filter for "ANALOG" or "RADIO".
Separating Data
Having all data on all devices in one place may be nice but currently it slows down the editing process.
I decided to split device data along the lines of hostinterface.
It would have been possible to split along the supported broadcasting standard to e.g. have one table that holds all ATSC devices, one for all the DVB-T devices and so on, but there are lots of multi standard devices that would have been hard to classify while there is hardly any device that offers more than one host interface. (The PCI cards that internally have USB host controllers and onboard USB DVB-T devices will be classified as PCI devices since their USB interface is not exposed to the machine's hardware).