User talk:CityK: Difference between revisions
m (→Help with wiki integration: Some thoughts....) |
(comments comments comments... we need a mailinglist !!!) |
||
Line 125: | Line 125: | ||
:: I agree with most of your choices for data to collect. However, there are three areas where I can see some wrangling will be necessary. |
:: I agree with most of your choices for data to collect. However, there are three areas where I can see some wrangling will be necessary. |
||
::# The support status of the devices. Your suggestion of the status of drivers with regard to the kernel/v4l/experimental/branch/external support takes account of all the possible values at present. However, support for devices also varies according to the level of support and I think it might be prudent to indicate that in the table. As I mentioned before, there could be five different levels of support: not working, partial support for some features, support unknown, most features working or fully supported. |
::# The support status of the devices. Your suggestion of the status of drivers with regard to the kernel/v4l/experimental/branch/external support takes account of all the possible values at present. However, support for devices also varies according to the level of support and I think it might be prudent to indicate that in the table. As I mentioned before, there could be five different levels of support: not working, partial support for some features, support unknown, most features working or fully supported. |
||
::: Agreed. There needs to be more detailed information on the support for different features. The data about where to find which level of support (vanilla kernel or developer VCS) can be left to the device's page. However I'd like to have one overall "supported" field. Question is: should the field contain the highest level of support available, even if that support is only available for people who compile their own kernel, or should it be the vanilla kernel support of the latest stable kernel? (I am a bit worried about the amount of work this generates.) |
|||
::# The use of machine-readable fields. I can see that this might offer the only option bearing in mind the limitations of the wiki backend. However, I wonder how likely it is that two chips will have the same part number from different manufacturers? |
::# The use of machine-readable fields. I can see that this might offer the only option bearing in mind the limitations of the wiki backend. However, I wonder how likely it is that two chips will have the same part number from different manufacturers? |
||
::: ''We'' give those names. If a conflict occurs and we need to rename an existing chip, we run a simple search and replace on the existing data and on the pages that do queries with that selectionvalue. |
|||
::# The comments field. Given that the table is meant to be a summary of the data available about various devices, is this field really necessary? I can see it being filled with fairly similar comments, which would suggest that another field would be more appropriate. In particular, I think that remote control support would dominate the comments and the addition of a field for remote control status (perhaps using the five-level system I proposed above with the addition of a 'not applicable' value for devices without remotes) might be a good idea. Any informatiive comments beyond this are surely the realm of a device page? |
::# The comments field. Given that the table is meant to be a summary of the data available about various devices, is this field really necessary? I can see it being filled with fairly similar comments, which would suggest that another field would be more appropriate. In particular, I think that remote control support would dominate the comments and the addition of a field for remote control status (perhaps using the five-level system I proposed above with the addition of a 'not applicable' value for devices without remotes) might be a good idea. Any informatiive comments beyond this are surely the realm of a device page? |
||
::: Agreed. |
|||
: b) to decide on the details that go into the different versions of the table and where to deploy which version (the stuff on [[HLPlayground2#first_scale_try]] is just my first idea) and |
: b) to decide on the details that go into the different versions of the table and where to deploy which version (the stuff on [[HLPlayground2#first_scale_try]] is just my first idea) and |
||
::As we discussed before, users can be split into three broad categories depending on their level of tech-savvy. However, their reason for looking on the wiki could be for: |
::As we discussed before, users can be split into three broad categories depending on their level of tech-savvy. However, their reason for looking on the wiki could be for: |
||
Line 134: | Line 137: | ||
::#Programming information for drivers |
::#Programming information for drivers |
||
::#Programming information for software |
::#Programming information for software |
||
::and probably others (please add to this list!!). |
|||
⚫ | :: |
||
::: When talking about the data on devices, we can skip the programmers and concentrate on the less tech-savvy users. They will always be the majority. |
|||
⚫ | ::I suppose that the most immediately useful page would be a page of fully supported devices, regardless of the method by which support is offered. This could eventually include devices from all architectures and would fulfil the criteria of 1. above. I think this would probably be the most visited page on the site. |
||
:::Agreed and it can be easily done. Take a look at the "tuner : mt2060 or vendor : TerraTec" table at [[HLPlayground2#Low_Detail_Table_2]]. You can combine data from different sources as long as it arrives in table rows with the right number and order of table cells. This way you don't need to throw all devices into one "database" article. You can keep USB DVB-T devices separate of PCIe DVB-S devices and of PCI Analog-TV devices. |
|||
: c) add the data of at least all the devices that are in [[DVB-T_USB_Devices|the old article]] into [[Template:DVB-T_USB_Devices_ListData|the "database"]]. |
: c) add the data of at least all the devices that are in [[DVB-T_USB_Devices|the old article]] into [[Template:DVB-T_USB_Devices_ListData|the "database"]]. |
||
: cheers -henrik --[[User:Hlangos|Hlangos]] 11:18, 11 June 2009 (UTC) |
: cheers -henrik --[[User:Hlangos|Hlangos]] 11:18, 11 June 2009 (UTC) |
||
Line 142: | Line 148: | ||
:: Cheers |
:: Cheers |
||
::Jim |
::Jim |
||
::: Maybe we should hijack the linux-media mailing list and flood it with our talk of reoganizing the wiki until ''they'' offer to make a mailinglist for us :-) |
Revision as of 22:42, 17 June 2009
CityK 19:46, 3 February 2007 (CET)
Spent a bunch of time last night and this morning creating and rearranging ATSC devices stuff. There is a LOT of work that could be done.
CityK 01:02, 5 February 2007 (CET)
I got to find a WYSIWYG wiki editor, else using code takes me ages
CityK 08:23, 7 February 2007 (CET)
made a mess of the categories tonight ... will clean that whole thing up soon. Started with the renaming and relinking of the DVB pages ... a lot more work than I thought. Oh well, it will be nice to have a consistant look and nomenclature across the board.
Definitely several months of work to get this thing ship shape!
JGXenite 14:25, 20 April 2007 (CEST)
Hi CityK,
Sorry about that :(. I'll make my changes to Mplayer now.
JGXenite 14:56, 21 April 2007 (CEST)
No worries with the countries thing - I thought it would make more sense moving it to channels.conf, as that is the correct file name. I then decided to make a "Europe" sub-category as there were quite a few European entries. I've also contributed one for United Kingdom (Sheffield) detailing my experience with setting it up :).
howl 00:01, 27 July 2007 (CEST)
I like the look of the page that you purpose and also i think that this can benefit a lot for people who only want information, actual desing is more confuse.
- Thanks Howl. If you did not see the message previously, here is a (more-or-less) recent status report: http://www.linuxtv.org/pipermail/linux-dvb/2007-June/018429.html --CityK 07:03, 27 July 2007 (CEST)
- I like a lot the idea and also the Nick Andrew's one in the reply of making a database. I don't know if there is a system to integrate a SQL db style like MySQL in wiki but if it exists it could be a powerful tool that will help to test different templates for the devices pages making the data independient of the style. --howl 01:08, 30 July 2007 (CEST)
- I do too, but I have no idea (or time to investigate, let alone implement) about a db in a wiki ... maybe in the future --CityK 19:14, 30 July 2007 (CEST)
Specto 20:34, 2 January 2008 (GMT)
Hi CityK,
I noticed that you reverted my additions to the "How_to_install_DVB_device_drivers" page of the Linux TV Wiki.
I just wondered why you decided to do this ?
Thinking about it in more detail I realise the statements I added might well have been wrong in which case I apologise for polluting otherwise clear instructions.
I am a bit of a Linux-newbie and was finding with v4l enabled within the kernel (configured from menuconfig) and trying to use the latest v4l sources I received a large number of warnings in dmesg output (something about the kernel defining symbols which the modules did as well). A reboot did not remove these errors. I fixed this by disabling v4l in my kernel and rebuilding it before proceeding to the 'make install' phase. (Drivers for my device already existed within the kernel but I need to use the newer ones which supported the remote control).
- Hi Spectro ... yes, it was just a case of being that the statements were incorrect -- what you had written shouldn't be necessary, and what is outlined in the Hg instructions is all that is required (make, make install, make unload, modprobe drivers). That said, I believe that there was an error in the driver set from last week or so -- I remember seeing a number of postings on the m/l, and also on the irc channel, about errors similar to the ones you encountered. But that's what you have to expect with the bleeding edge -- from time to time, regressions unfortunately crop up/get introduced. In any regard, I think those problems have likely been amended now. As an aside, when I rolled back the article from your edit to the previous state, I forgot to note a reason (like: "inaccurate statement" or whatever), and hence that's why a comment/explanation is missing in the article's history feature for the rollback or from the wiki's list of "recent changes" feature. --CityK 17:04, 4 January 2008 (CET)
Bpringlemeir 06:26, 27 November 2008 (CET)
Do you have a place to put module parameters. Ie, proc/module/tuner/parameter/ntsc can be one of M,J,K setting special frequency bands for user in ???, Japan and Korea. Case doesn't matter.
- Hi Bpringlemeir ... Some parameters might already be documented in some of the articles remaining in the old V4L wiki (http://www.linuxtv.org/v4lwiki/index.php/Special:Allpages); perhaps in one of the tuner articles or in the chip interface (i.e. bt878 etc etc) articles. All these articles will be transfered into here in the near future. There are also the duplicate articles for some of the interface chipsets found here, in this wiki.
howl 20:52, 31 December 2008 (CET)
C'mon man, take a rest, is the last day of the year :)
- Ah, but I had! (The wiki is on Grenwich MT. I'm on -5GMT, so the edits you saw were from the day prior)
Hlangos 10:16, 7 April 2009 (CEST)
Hi there, could you remove DVB-T_USB_Devices_Table ? It doesn't add any information, and the information it duplicates from DVB-T_USB_Devices is not more readable or more accessible.
- I'll archive the page...its a shame that person elected to create a new page instead of working on the original, as they likely spent some time on it. Oh well.
- Same goes for MSI_Digi_VOX_mini_II_v3.0 . I Informed the author about MSI_DigiVox_mini_II_V3.0 , asked him to add his information there and to ask one of the wiki admins to remove his new page. pity... --Hlangos 15:07, 13 April 2009 (CEST)
- Doh! Thanks. I haven't anything from them yet. I'll see about cleaning it up soon, otherwise.--CityK 04:41, 17 April 2009 (CEST)
- Same goes for MSI_Digi_VOX_mini_II_v3.0 . I Informed the author about MSI_DigiVox_mini_II_V3.0 , asked him to add his information there and to ask one of the wiki admins to remove his new page. pity... --Hlangos 15:07, 13 April 2009 (CEST)
Also, you seem to have removed the DVB_USB page a while back but the Talk:DVB_USB page still exists. It only contains a redirect, but so did DVB_USB. So how about getting rid of that artifact, too?
- DVB_USB got moved to DVB_via_USB. When you use the wiki's "move" feature on an article, the old page automagically gets set up as a redirect to the new page -- similarly with the associated article Talk page. I then deleted the DVB_USB page (as I don't like to have useless redirects cluttering up the wiki's index), but obviously forgot to also delete the Talk:DVB_USB page...its gone now. --CityK 20:16, 12 April 2009 (CEST)
- Thanks! BTW: Is there a way to make redirect pages invisible for the index without deleting them? They might still be useful for old links from the outside.. --Hlangos 15:07, 13 April 2009 (CEST)
TechniSat AirStar USB / Air2PC DVB USB link on DVB-T USB Devices
A long time ago you added this to the "supported" section:
The article itself says the device is still not working properly. Can you confirm it is supported? --Hlangos 12:37, 28 April 2009 (CEST)
- Hi Henrik, I believe that the original device did indeed work (if IIRC, Patrick added suppport for it), but I think that are a couple of different revisions (i.e. differing slightly by tuner and/or demod), and that the later revisions were problematic at some point....I really have no idea otherwise about the current support status
Sysop status
Hi,
Thanks for the extra privileges! I'm pretty much finished with categories; most of the remaining pages are incomplete with regard to their interface and whether they are analogue or digital etc. Is there anything else that needs attention that I could have a look at? I've had a look at your user page and that all seems in hand.
Hope you're well
Cheers
Jim
- Hi Jim, I'm good (just very busy). Thanks again for the cat. work! A nice little project would be to implement graphical boxes for stub pages or needs expanding etc type features like wikipedia and other wikis employ. Examples:
- http://en.wikipedia.org/wiki/PCIe
- http://en.wikipedia.org/wiki/Template:Ambox
- http://en.wikipedia.org/wiki/Wikipedia:Stub
- --CityK 02:04, 11 May 2009 (CEST)
Help with wiki integration
Hi CityK,
I've had a quiet week or so on the wiki front. I've been holding out while Henrik gets his ParserFunction project sorted out as I think it will be replicated across the site if all goes well. In the meantime, can I help with the V4L wiki integration? Just let me know if there's anything I can do.
I've also started to prepare a document showing the current structure and content of LinuxTV.org. I notice in your user page that you have given some consideration to the layout of LinuxTV.org and I think that the site as a whole could use some updating/beautification. I'll start a new page and insert the document into it or something and send you the link. Again, any thought that you have would be gratefully received.
Cheers
Jim
- Hi Jim & CityK,
- Js installed the missing extensions and I've since written a template for the low detail version of the device table that takes two additional arguments (selectionvalue and selectionattribute) and only displays a row if "selectionvalue" is found in "selectionattribute" of the data that is passed to it. Here are some examples of the usage: HLPlayground2#Row_Selections. I would be more happy if I had found the time to crunch the different levels of detail that currently are implemented by different templates into one template. It should be relatively easy, now that ParserFunctions are there. I just didn't have the time yet. On the other hand the code will get less and less readable if I do that. So we might as well call it "good enough". Now what needs to be done is
- a) decide which data we want to collect on the devices (this list is just my proposal)
- I agree with most of your choices for data to collect. However, there are three areas where I can see some wrangling will be necessary.
- The support status of the devices. Your suggestion of the status of drivers with regard to the kernel/v4l/experimental/branch/external support takes account of all the possible values at present. However, support for devices also varies according to the level of support and I think it might be prudent to indicate that in the table. As I mentioned before, there could be five different levels of support: not working, partial support for some features, support unknown, most features working or fully supported.
- Agreed. There needs to be more detailed information on the support for different features. The data about where to find which level of support (vanilla kernel or developer VCS) can be left to the device's page. However I'd like to have one overall "supported" field. Question is: should the field contain the highest level of support available, even if that support is only available for people who compile their own kernel, or should it be the vanilla kernel support of the latest stable kernel? (I am a bit worried about the amount of work this generates.)
- The use of machine-readable fields. I can see that this might offer the only option bearing in mind the limitations of the wiki backend. However, I wonder how likely it is that two chips will have the same part number from different manufacturers?
- We give those names. If a conflict occurs and we need to rename an existing chip, we run a simple search and replace on the existing data and on the pages that do queries with that selectionvalue.
- The comments field. Given that the table is meant to be a summary of the data available about various devices, is this field really necessary? I can see it being filled with fairly similar comments, which would suggest that another field would be more appropriate. In particular, I think that remote control support would dominate the comments and the addition of a field for remote control status (perhaps using the five-level system I proposed above with the addition of a 'not applicable' value for devices without remotes) might be a good idea. Any informatiive comments beyond this are surely the realm of a device page?
- Agreed.
- I agree with most of your choices for data to collect. However, there are three areas where I can see some wrangling will be necessary.
- b) to decide on the details that go into the different versions of the table and where to deploy which version (the stuff on HLPlayground2#first_scale_try is just my first idea) and
- As we discussed before, users can be split into three broad categories depending on their level of tech-savvy. However, their reason for looking on the wiki could be for:
- Pre-purchase information about devices and support.
- Post-purchase information about devices and support.
- Technical background on DTV.
- Programming information for drivers
- Programming information for software
- and probably others (please add to this list!!).
- When talking about the data on devices, we can skip the programmers and concentrate on the less tech-savvy users. They will always be the majority.
- I suppose that the most immediately useful page would be a page of fully supported devices, regardless of the method by which support is offered. This could eventually include devices from all architectures and would fulfil the criteria of 1. above. I think this would probably be the most visited page on the site.
- Agreed and it can be easily done. Take a look at the "tuner : mt2060 or vendor : TerraTec" table at HLPlayground2#Low_Detail_Table_2. You can combine data from different sources as long as it arrives in table rows with the right number and order of table cells. This way you don't need to throw all devices into one "database" article. You can keep USB DVB-T devices separate of PCIe DVB-S devices and of PCI Analog-TV devices.
- As we discussed before, users can be split into three broad categories depending on their level of tech-savvy. However, their reason for looking on the wiki could be for:
- c) add the data of at least all the devices that are in the old article into the "database".
- cheers -henrik --Hlangos 11:18, 11 June 2009 (UTC)
- PS: Is it a lot of work to set up another mailinglist? One for the linuxtv wiki? (linux-media or linux-dvb are way too noisy) It would help to coordinate and keep people informed without the need to subscribe to those high volume lists.
- I concur with this idea. I can see that an extra mailing list might well be the way to go.
- Once again, fine work Henrik. Please let me know what you think of my comments.
- Cheers
- Jim
- Maybe we should hijack the linux-media mailing list and flood it with our talk of reoganizing the wiki until they offer to make a mailinglist for us :-)