Hey Todd,

Unfortunately Christian Bauer is offline, he has decided to take a week off to actually finish the front software for the database.

In the short term, he is working off of LIRC, and the initial work is schema cleaning and developing a self-serve front end. Apparently the flat file format is very messy and not constant, so making sure we clean up and automate the cleaning and have a validated schema for the 100k or such codes is an important step towards getting a distribution that is MAINTAINABLE. LIRC is actually GREAT (remarkable that they can get so much in) but lacks the automation, we will help on that front. Self serve means we will be able (in 2 weeks or so) to offer you a web page where you can click on this code doesn't work for me and potentially enter new codes for your model.

In the mid term an organic but systemic growth of a LIRC seed is the fastest way we can envision to grow the AV database. If you have other ideas we are listening. Another area in the mid-term is to work off the Tonto database. It is essentially cleaned codes from Phillips and would provide a good seed. The CCF format does not interest us here, but rather the raw codes. This is on our radar but is taking second place to the LIRC import at the time.

Long term we could get lucky. In the sense that the OR database achieves enough brand recognition that it attracts enough guys like you that can validate and actually are savvy enough to derive codes by their own means or something like lirc-record of a IR reciever (which we have planned for the Controller). Alternatively the manufacturers know of this effort to publish their own codes.

One must not be naive about the brand recognition that is necessary. That is where I am helping with PR and such. BTW we will try to make some product noise around OR/Beehive, as even though it is not a product it is a project that is warrants stand-alone visibility. In other words, you may want to use OR/Beehive, without really using OR as your AV solution.

The good news is that this brand building is self-reinforcing, with positive feedback loops, i.e. the more people enter codes the more people will find it relevant etc. That means a small entity like ourselves (160 members?) can achieve this kind of visibility with little time.

Juha/Mark, thanks for the follow up. Your responses are more or less what I expected. I agree with the comments re: LIRC files (based on my experience with them last year).

So, I wonder if there are ways to try and be more proactive about code acquisition and validation.

For example, what tools could be employed to automate observation/recording/submission of codes?

Could some VERY low cost widget be developed for this purpose? Do they already exist?

Can the review of submissions be validated or automated by some means?

Does anyone have experience in obtaining codes directly from vendors?

How could an extensive open source database be used constructively to encourage vendor participation?

Todd,

Todd Comins wrote on Aug 26, 2008 21:49:
For example, what tools could be employed to automate observation/recording/submission of codes? Could some VERY low cost widget be developed for this purpose? Do they already exist?

Stewart Allen of Tonto project was describing one method on this thread which basically involves getting one of the good universal remotes and start clicking away. It's kind of rough but it's a start. Do you have some other ideas in mind?

Todd Comins wrote on Aug 26, 2008 21:49:
How could an extensive open source database be used constructively to encourage vendor participation?

I agree with Marc's point above that an active community, growing community with good publicity and PR is the best way to get vendors to notice. All additional ideas are welcome :-)