Since my good ole Pronto NEO TSU500 is dying, I just opened the box with a shiny TSU 9400. About to set it up, and was happy to find the gazillion codes shipped with the factory database. Remembering long nights trying to convince the Neo about codes ....

BUT ... there are a gazillion code sets for each brand and type, and I have no clue whatsoever which codeset to use. Given all these variants, it would take forever to figure out which is right by trial-and-error. Some sets may be identical except for one little code that works in one set but not the other (just had that experience with my Squeezebox - with only two sets to choose from). Having several devices with 5-20 possible codesets each, this could be a lifetime challenge ;-)

So - question is:
is there a some online reference for cross-referening make/model and code sets? Or is there a qucik and fairly safe way to identify the codeset?

In particular, I am interested in the code sets for these these devices:
- Receiver: Harman Kardon AVR 5550
- DVD: Harman Kardon DVD 30
- Satellite tuner: Digiality VC-CI 304
- TV: Hitachi 42PD9700

The rest of the stuff seem to have just one set to choose from - hope it works :-)

regards

No reference. Only way to do it is by trial and error.

I must say that this truly puzzles me. I'm a software geek and spend a LOT of time designing data sets, UI, features, workflows, etc. That means I also spend way too much time in software development forums trolling for answers to things. Any time there's a need for something like this codeset cross-reference I always seem to find that someone else has already built it.

Not so here. So here's what I propose.
I will be happy to design and populate an initial database of codes. I can even host the tool on my web site. But first I'll need to learn all about the data that's currently stored in MyDatabase. I only just bought my first Pronto and have just started studying the software this week. It will take me some time to get up to speed, but I will check back here to see if this generates any interest. If enough of you think this would be useful, I'm happy to help build it and give it home.

I am thinking of this as a free public resource. We need to be careful that we don't give anyone the impression that we control the codesets. If I'm not mistaken, codesets are considered intellectual property and the use or distribution of them is covered by whatever EULA comes from the hardware manufacturer. That being the case, whatever we build would have to operate as a repository of user-contributed data.

Anyway...I'll check back this weekend to see what kind of responses I get here.

See ya.

The codes in the Files area here is effectively a database of IR Codes, and tends to be more reliable than the factory database.

There are lots of missing and incorrectly labelled codes in the factory database.

A minor point but tracking models with codesets can be very difficult as the same device often has different model numbers in different countries and sometimes the same model uses different IR codes in different countries

Good points, Peter. I agree it would be difficult to manage, but I do think it's possible. The multi-model issue, for example, could be handled by using a tagging system similar to the way people tag their photos today.

Without know nearly enough about how the codes are structured, I'll offer this structural possibility.

CODEID: 000123456789
HEXADECIMAL VALUE: 0xE23
CONTROL TYPE: IR
DISCRETE: Yes
BRAND: Panasonic
DEVICE TYPE: TV
MODEL: PS123
CODESET ID: 1721
ACTION: Volume Up
CONTRIBUTOR: Legolad
Date Submitted: 10/22/2008
NOTES: Same as Mitsubishi OEM model

By breaking out the individual codes from the manufacturer's pre-defined (and arbitrary) codeset, we can begin to collect codes as a set of unique commands which, when used on a specific device will have a specific function.

In the database this would take the form of 2 tables (at a minimum).

In table 1 you have the unique hexadecimal codes.
In table 2 you have all the meta data submitted for those codes.

Assuming we allow people to enter duplicate codes and tag them differently, we could check each new code to see if it's already in the database. If it isn't, we add it to Table 1 and insert the meta data into Table 2.
If the code already exists in Table 1, we simply insert the new meta-data (the model, device, and other tags) into Table 2.

This allows people to submit the same code multiple times for different equipment/functions/models.

We could further enhance this system by using pre-defined dropdown lists of manufacturers, models, etc, though that makes the whole thing a lot harder to maintain.

Lastly, we would need to decide how much we want to validate the data. I know a few experts on this topic and I'm guessing there are at least a few lurking around in here. Between us maybe we could start to flesh out a plan.

Consider adding a "tag" that is the actual text or symbol attached to the button on the native remote.

BUTTON LABEL: whatever

Also, the current database follows a common manufacturer's convention of supplying two codesets, "normal" (native remote commands) and "extended" (often available to installers). This complicates programming because there are two devices associated with a single box. While this may be interesting history, I don't think it serves any useful purpose for the remote control program writer.

---

On another front, there could be some IP (intellectual property) issues if someone breaks into the current codebase and submits these codes.

---

Also, there should be a process and notes in the database. Perhaps:

REVIEWED BY: sam spade
REVIEW DATE: 01 December, 1965 (there will always be issues because "proper" date format varies by region)
REVIWER'S COMMENT: Changed single volume up step to repeating command.

Since it is not possible for all codes to be reviewed by a high level person, there should be some sort of user feedback. Codes with poor feedback could be scheduled for review by a high level person -- if one can be found who actually has experience with the model in question.

POSITIVE USER FEEDBACK: 95%
FEEDBACK REPORTS: 100
TOTAL DOWNLOADS: 50 .... Obviously, someone is cooking the books on this entry!

Under the covers, the feedback providers should be tracked and potentially contacted if a high level person is digging through issues with the code.