Regarding your "it worked before, it worked with, now after it doesn't work" sentence, it's already addressed in the FAQ entry I quoted, but I'm ready to explain it a last time:

If you install an other application that's locking up the *OS X driver* for the Apple Remote *while* using Remote Buddy, you'll not notice the effect of said other application *until* you quit Remote Buddy. Why? Because *until* you quit Remote Buddy, 
*Remote Buddy's driver* was in use. And *after* you quit Remote Buddy, the *OS X driver* is used again. Of course, if an other application is disabling your Apple Remote by exclusively accessing the *OS X driver*, you won't notice for as long as Remote Buddy is running. Simply because at that point the *Remote Buddy driver* is used. And *after* you quit Remote Buddy, the *OS X driver* is used again - which is where the issue you experience is at home.

Remote Control Diagnostics (linked to in my previous post) is a one-click tool that can detect whether an application is doing so and - under OS X 10.6 - even tell you the name, PID and filesystem location of the application that's doing so. Many applications that worked fine in the past are causing such problems under OS X 10.6, because their Apple Remote support depends on internals of the OS X driver that changed with OS X 10.6.2 (and, in the past, with OS X 10.4.9 and OS X 10.5).

Under OS X >= 10.6.2 many people saw these issues with the invisible background helper apps of Boxee, Plex and XBMC (usually automatically launched at each startup) - which were either leftovers from old installs or from versions whose Apple Remote support is incompatible with the OS X driver of OS X >= 10.6.2.

You'll notice that once you quit the other application that Remote Control Diagnostics detected as cause of your issue, your Apple Remote will work again. And that, once you run that other application again, the Apple Remote will stop working again. You can reproduce this even on a pristine OS X install (using the same OS X version/revision, so that the same version of the OS X driver is used) using just the app that's causing you the issue.

As I already said - and as I believe with this posting's PS to have explained to the full extent - Remote Buddy isn't and can't be causing such issues.

Using Remote Control Diagnostics, it's very easy to find out which other application is causing you the issue (it actually takes just one click).

But, as is always the case with solutions: they can only work if you apply them. They don't work if you ignore them.

Regards, 
Felix Schwarz

P.S.: Following is a detailed discussion of the issues that the usage of the *OS X driver* by other applications can cause even on pristine OS X installs, explains why and also explains why Remote Buddy - by the very way it works - can't be causing such issues.

-- cut -- 
Let me start by telling you about the two driver architectures for the Apple Remote. First, there's Remote Buddy, which uses its own driver architecture to deliver the best experience and responsiveness to Apple Remote users. Second, there's the OS X Apple Remote subsystem (henceforth OS X subsystem), which is used by pretty much every other application. These two architectures exist separately from one another - in peaceful co-existance.

Applications using the OS X subsystem usually access it in exclusive mode. Thereby, they prevent any OS X default actions (like volume up/down/etc.) and also keep all other applications from using the Apple Remote at the same time. So far, things are fine. The problem starts with how these applications try are making sense of the codes they receive: most of them rely on the interals of specific versions of Apple's driver. Such dependencies, of course, are a bad thing and in fact, every time Apple updates this driver, these applications can no longer make sense of the input they receive and don't show any reaction anymore. So far this has happened with the OS X 10.4.9, 10.5 and 10.6.2 updates. The problem really starts in the combination of these two aspects: the exclusive lock on the OS X subsystem, which prevents OS X reactions and other applications from accessing the Apple Remote on the one hand. And, on the other hand, the fact that the application itself can no longer make sense of the input it receives and simply does nothing when you press a button. The result is that your Apple Remote simply does nothing anymore.

It is because of these issues caused by other applications that we chose - years ago - to no longer use this OS X subsystem in Remote Buddy at all. Instead we invested a lot of time, money and research into developing our own driver architecture that works under all circumstances. This allows Remote Buddy to just work even in situations where - as is the case here - the user has installed an other application that effectively disables the Apple Remote for whenever the OS X subsystem is responsible for handling the Apple Remote's signals.

Now how does this all connect and how does it explain the issue this user is having?

Easy. This user has installed one of those apps that 
1) keep an exclusive lock on the OS X Apple Remote subsystem 
2) aren't able to make sense of the input they receive due to lack of support for the driver version that shipped as part of the OS X release the user is running. 
This, on this user's system, effectively disables the Apple Remote systemwide.

Now, if this user launches Remote Buddy, which - as I pointed out - uses a different, independant driver architecture of its own, Remote Buddy of course works well (as also noted by the user).

But as soon as the user quits Remote Buddy, responsibility for reacting to the Apple Remote signals is back in the hands of the OS X Apple Remote subsystem. Which in turn is already locked exclusively by the other application this user has installed. It is this other application that's responsible for his Apple Remote effectively not working.

Since Remote Buddy is not causing his issue, re-installing and uninstalling it of course doesn't have any effect (as also noted by the user). After all, the other application that's causing his issue is still installed, running and disabling his Apple Remote.

The solution?

The user simply needs to quit the other application that is causing his issue. In case he can't remeber which other applications he installed before, while (*) or after using Remote Buddy: we even provide a free tool called "Remote Control Diagnostics" that makes the identification of such applications super simple and takes just a single click (=> http://www.iospirit.com/labs/remotecontroldiagnostics/ ).

- Felix Schwarz

(*) If the user installed the other application that's causing him the issue while Remote Buddy runs, he wouldn't immediately notice the effect of installing the other app. Because, at that point, the Apple Remote is controlled by Remote Buddy's driver - and not the OS X subsystem in which the other app is causing his issue. It is only when he quits Remote Buddy and control returns to the OS X Apple Remote subsystem that he'd notice the issue caused by the other app he installed. 
-- / cut --