1) No. Obviously Philips processes are so lax there software contains easily detectable defects. They obviously don't enforce well-known testing techniques.

2) Again, I'm complaining about a defect. The various descriptions of crashes, hangs, and bad data files are also not "features".

3) Ok, so I can convert the IR code to something human understandable. So what? The code is clean and is being sent multiple times. If I wanted it sent multple times, I'd encode it that way. Why are they simulating a button press anyway? Why not just send the IR code and if the code needs to be sent multiple times make the user write it that way? Why force actions to be tied to buttons? I can't control exactly what gets sent because anything sent is tied to some timer that decides how long a button click takes?

The time between a button down and button up determines if it is a simple click or the user is holding down the button. That I can't control the exact code sent to the device is a defect. You could argue it is a design defect, but it is a defect.

Or am I missing someway to create an action that is not associated with a GUI widget? You know, simple MVC. The only way I see to get to an action is to link to a button. Simulating a button click to perform an action is pretty lame, especially when there is a timing problem that causes a code to be repeatedly sent. It behaves differently in a macro than when clicked. Telling the user this is working as designed is a very poor response.