User talk:CityK

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)

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)

howl 10:50, 22 September 2009 (UTC)

Good point putting the web archive page for the AF9005 ;)

TechniSat AirStar USB / Air2PC DVB USB link on DVB-T USB Devices

A long time ago you added this to the "supported" section:

• TechniSat AirStar USB / Air2PC DVB USB

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.

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

1. 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.

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

1. Pre-purchase information about devices and support.
2. Post-purchase information about devices and support.
3. Technical background on DTV.
4. Programming information for drivers
5. 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 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 :-)

Files to delete

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

--howl 00:40, 1 October 2009 (UTC)

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)

Did it. Hope it fits well. :) Antoniop 22:39, 18 January 2011 (UTC)

Spam users in the pipe

Hi there, I just noticed that we have recently gained a lot of new users with names that seem to indicate German language spam.

These are the Users and the translation of their names:

User:xAbnehmen (lose weight)  
User:xAnbieterstrom (supplier electricity) 
User:xEnergie (energy)
User:xFirtenlernen (learning to flirt) 
User:xForexanbieter (forex supplier)
User:xGastarife (gas rates)
User:xGasvergleich (gas comparison)
User:xLottozahlen (lottery numbers)
User:xNaturstrom (nature electricity)
User:xOekostrom (eco electricity)
User:xPreisvergleichstrom (price comparison electricity)
User:xStrombilliger (electricity cheaper)
User:xStrompreise (electricity prices)
User:xVergleichstrom (comparison electricity)
User:xVersorgerstrom (supplier electricity)

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

cheers --Hlangos 19:34, 29 September 2011 (CEST)

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)

Thanks for all the info Hlangos. Looks like one of our German spambots got through tonight. I'll leave it up right now for you guys to have a look-see. I was unaware of the reCaptcha stuff ... I note that when I read your remark about them being bought by a member of the "evil empire" club, I was expecting it was to have been Apple :P (Google hasn't offended me too much yet, but they are definitely on my watchlist). Yeah, I was just thinking of having something on registration only. I don't know what JS thinks would be the best solution to implement, or if he has other feelings about it. --CityK 05:50, 1 October 2011 (CEST)

Hey CityK, your mail bounces. Please contact me. --js 22:08, 2 October 2011 (CEST)

Just sent you a message --CityK 23:03, 2 October 2011 (CEST)