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.

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

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)

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)

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.

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)

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)

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:

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.

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.

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

Files to delete

Hi CityK, there are two image files that aren't needed anymore and can be deleted.

New Software to watch Digital TV

Hi, I took a look at the history and it looks like you're one of the main contributors to the page TV_Related_Software Now, I am the author of a new software to watch digital television on linux, it's open source and it's name is Antenna DTV, website: Antenna DTV. It's a new project which focuses on the signal, and not only to watching tv alone. Might I add it to the list of software to watch digital tv? Thanks! Any question is welcome!

But of course, feel free -- it is, after all, a community wiki ! You could create an article page for the app too --CityK 07:42, 9 January 2011 (UTC)

I'd go ahead and simply block those users but I can't figure out why they havn't been used to spam the wiki yet.
Do we have a policy in place that enforces email address verification before allowing edits?

BTW: it would have been easier to find those users if the user table could be sorted by creation date but "Sort by creation date" yields the following error on Special:ListUsers

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "IndexPager::reallyDoQuery (UsersPager)". Database returned error "1176: Key 'PRIMARY' doesn't exist in table 'user' (localhost)".

None of those users did actually do spamming yet. So there's no reason to block them so far. --wirbel 19:51, 29 September 2011 (CEST)

The SQL error should be fixed now. --js 00:32, 30 September 2011 (CEST)

I hadn't really noticed the German language spam, but that is pretty funny (given the translations, the names that are being used). About a month or so ago, I noticed that the new user spambot pattern seemed to be an English_name-prefix_followed_by_number (e.g. george1107). Anyway, I was thinking that perhaps we should deploy a reCaptcha (http://www.mediawiki.org/wiki/Extension:ReCAPTCHA) for our user registration, though I don't know how useful it would be. I note that the thinkpads forum ( http://www.thinkpads.com/forum/) has one of the more elaborate registrations that I've encountered in attempts to ward off spam... With the point being that spam still gets through--CityK 04:07, 30 September 2011 (CEST)

@wirbel: True, and if it was a single user I wouldn't even have noticed, but 15 users that just happen to have similarly spamy names?

It really looks like preparations/tests for spam, agree. But as users in this wiki can freely choose their login name to whatever they want and no spamming happened so far, i just wanted to remind, that blocking users should be taken into account only if they actively destroy something. reCaptcha or similar is a good idea anyway. --wirbel 18:25, 30 September 2011 (CEST)

@js: Thanks! Works like a charm now!

@CityK: The translations are literal. Most of the names are perfectly OK in German. You can stick word together like "chicken" and "soup" to make "chickensoup" (a soup with chicken) or "soupchicken" (a chicken destined for ending up in a soup). Some of the user names however don't work. E.g. Stromanbieter is a common word for your electricity supplier while Anbieterstrom would describe the electricity that comes from a supplier, and doesn't make much sense. I was a big fan of recaptcha, before they were bought by that one big company that is giving M$ a run for its money in the evil empire contest. Nowadays their privacy policy reads like a joke:

We log information related to reCAPTCHA, such as the Internet Protocol address of the end-user,
an identifier for the implementing site, the URL of the site accessed,
the CAPTCHA solution, the result of the CAPTCHA grading, the date and time of requests,
and one or more cookies that may uniquely identify the end-user browser.
In our logs, we will delete any information that identifies the individual URLs
within the implementing site within 30 days of the event logged.

The cookies are particularly evil as they allow them to follow your surfing habit across every site that happens to show a recaptcha. (You don't even have to solve that captcha. Just downloading the captcha image will tell them which page you have been looking at, from which IP at which time and so on...

There are alternatives to recaptcha but we also need to consider what we spend our time on, and if recaptcha is available and installable here without much fuzz, Using recaptcha may be ok for the sign-on process but I'd rather not have it pop up every now and then. cheers --Hlangos 12:18, 30 September 2011 (CEST)