Talk:DVB-T USB Devices: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
(→‎Devices Order By: new section)
Line 330: Line 330:
== Devices Order By ==
== 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 [[User:Hlangos|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.
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 [[User:Hlangos|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. --[[User:Howl|howl]] 18:49, 27 September 2009 (UTC)

Revision as of 18:49, 27 September 2009

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)

---

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 :-)

Sortable List of Supported DVB-T USB Adapters
Vendor & Model Added to
Kernel
Frontend Bridge
Interface
COFDM Whatever Analog Other Features & Comments
Anysee
E30
in Hg
since 05.2008
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • some firmware
Anysee
E30 Plus
in Hg
since 05.2008
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • some firmware
DViCO
FusionHDTV USB DVB-T
2.6.??
(probably around 2006)
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • firmware=dvb-usb-bluebird-01.fw
  • pic <- which is something that really only belongs on the device's article page, and not on a brief summary table like this
DViCO
FusionHDTV DVB-T Dual USB
2.6.??
(probably around 2006)
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • firmware=dvb-usb-bluebird-01.fw
  • pic
  • 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.
    • 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.
    • 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:

Sortable List of Supported DVB-T USB Adapters with details
Vendor Model Supported Frontend Bridge
Interface
COFDM Whatever Analog Other Features & Comments Picture
Anysee E30 in Hg
since 05.2008
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • some firmware
Dvb-t-usb-msi-digivox-ii-rev3-001.jpg
Anysee E30 Plus in Hg
since 05.2008
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • some firmware
Dvb-t-usb-toshiba-px1211e-1tvd-001.jpg
DViCO FusionHDTV DVB-T Dual USB 2.6.??
(probably around 2006)
  • some tuner
  • some demodulator (D)
some usb bridge Yes ? No
  • blah blah blah
  • firmware=dvb-usb-bluebird-01.fw
  • pic
Dvb-t-usb-sinovideo-sv3420d-v02-005.jpg
Sortable List of Supported DVB-T USB Adapters without details
Vendor Model Supported Picture
Anysee E30 in Hg
since 05.2008
Dvb-t-usb-msi-digivox-ii-rev3-001.jpg
Anysee E30 Plus in Hg
since 05.2008
Dvb-t-usb-toshiba-px1211e-1tvd-001.jpg
DViCO FusionHDTV DVB-T Dual USB 2.6.??
(probably around 2006)
Dvb-t-usb-sinovideo-sv3420d-v02-005.jpg
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)