User

23.04.2010 03:42:04

So I tried Remote Buddy for the 30 day trial, and while I like it I don't think I want to buy it. I trashed the program, but now my remote is rendered useless.

Any tips here? 

User

23.04.2010 08:38:46

Thanks for asking.

1) Short answer: 
Your issue is and can't be caused by Remote Buddy. It is caused by another application that you installed.

You can use our free Remote Control Diagnostics tool to find and locate the application that's causing you this issue: 
http://www.iospirit.com/labs/remotecontroldiagnostics/

2) Long answer from the FAQ - including some technical background 
-- FAQ -- 
Q: After uninstalling/quitting Remote Buddy, my Mac® no longer reacts to the Apple® Remote. (FAQ015E0241)

A: To enable you to use all capabilities of the IR Receiver of your Mac®, Remote Buddy is using its own driver. In contrast, all other applications with integrated Apple® Remote support usually use the OS X Apple® Remote subsystem.

As long as you're running Remote Buddy, Remote Buddy and its driver are responsible for turning the received button presses into actions. As soon as you quit Remote Buddy, this task is again handled by the OS X Apple® Remote subsystem.

If other applications don't use the interface to the OS X Apple® Remote subsystem correctly, this can lead to the effect that nothing happens when you press a button on your Apple® Remote. For as long as you're running Remote Buddy, issues like this are covered by Remote Buddy and it's driver and are therefore not visible to you. However, as soon as you quit Remote Buddy, the OS X Apple® Remote subsystem is back in control and any issues caused in it by other applications become visible.

Therefore Remote Buddy is neither the cause of the issue nor is it responsible for it. Instead, the cause of the issue exists independently of Remote Buddy. It's located elsewhere and can also only be solved there.

Although our products can't cause any such issues, we're regularly contacted about such issues and asked for help. In order to make locating and fixing the cause of such issues as easy and efficient as possible, we've developed a free diagnostics tool: Remote Control Diagnostics (http://www.iospirit.com/labs/remotecontroldiagnostics/). It can locate issues with a single click and will provide you with information about the issue as well as with instructions on how you can fix it. 
-- / FAQ --

Don't hesitate to ask if you need further help.

Best regards, 
Felix Schwarz 

User

23.04.2010 18:05:25

Ah c'mon. It worked before Remote Buddy, worked with Remote Buddy, now post-Remote Buddy, it doesn't work! 

User

26.04.2010 08:55:32

The FAQ already answered your question. And I also already showed you the solution. Did you read it - and did you try it?

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

User

09.07.2010 06:49:30

If it helps.... Sorry, but you response that Remote Buddy is not the cause is not 100% accurate.

1. I was using the remote normally with front row 
2. 2 min later (next action) I Installed Remote Buddy 
3. tried it for 5 min then uninstalled 
4. my remote no longer works with my mac.

I used no other applications during that time.

Your remote diagnostic tool showed that boxee was locking the remote, and when I went into boxee and shut off the use of the remote in settings, it began to work again.

However, and here is the kicker... the installation of remote buddy somehow caused boxee to improperly lock my remote when i did not use boxee, because this only happened after I installed remote buddy.

Last edited: 09.07.2010 06:58:49 

User

09.07.2010 11:21:46

Thanks for asking.

My answer is accurate. Remote Buddy is not responsible for your issue.

As a matter of fact

1) only running applications can hold a lock. If you uninstalled Remote Buddy, it is no longer running and can no longer run.

2) Remote Buddy doesn't contain any code that would do any such locking - it uses a different mechanism. Remote Buddy definitely is not the cause of your issue.

3) Therefore, if RCD detects an application having a lock on the receiver, it definitely has to be another application that you installed. Most commonly this is either the helper tools of Plex, XBMC or Boxee (sometimes even the remains of an old installation). Under OS X 10.6, RCD would also have been able to name you the name of the tool and its full path. Prior to OS X 10.6, this information is not made available by OS X.

I can still help you, though. Please

1) Open Terminal.app 
2) enter 
sudo ps aux -w -A 
3) enter your password when prompted 
4) cut and paste the full output of the tool into a reply

I can then go through the list of applications running on your computer and show you which one is causing you the issue, which, as explained before, really can't be Remote Buddy.

Best regards, 
Felix Schwarz 

User

10.07.2010 17:49:46

My first reply was to the initial version of your posting - I get all forum posts by email (edits not included) and also reply that way. I just saw on the web that you edited it and removed most of your pretty wild accusations that your initial posting contained. That's a start.

You're still making a wrong claim here, though, in stating that Remote Buddy has any involvement with your issue. This is NOT the case. Your issue is exclusively and solely a Boxee issue and nothing else - especially not Remote Buddy - plays any role in this.

Since you have questioned my person, my authority, knowledge and the accuracy of what I say, I feel that, really, the only way to react is by confronting your assumptions and wrong allegations with actual facts. Here we go:

First, as I already wrote, Remote Buddy doesn't use any locking on the Apple Remote driver and also doesn't contain any code that could. That it does, however, would be THE absolutely essential, basic requirement for it to be able to have *ANY* influence on Boxee's Apple Remote helper tool that has caused your issue. As it is, however, Remote Buddy doesn't even contain any such code.

Second, locking on IOKit resources like the Apple Remote HID device requires the application that wants to hold a lock to actually run. IOKit automatically takes care that all exclusive locks are released as soon as an application quits or crashes. No IOKit locks on HID devices like the Apple Remote can survive quitting or crashing an application, let alone an uninstall or reboot (as you claimed in your original post). Other than you claimed in your original post, code that doesn't run or even no longer exists on your Mac can't do any IOKit locking.

Third, you appear to be using OS X 10.6 and Boxee. It is a well known and well documented fact that Boxee's Apple Remote support does NOT work on OS X 10.6.2+ and causes EXACTLY the issue you had. Just ask Google. Not only will you find numerous users that had the exact same issue as you after installing Boxee under OS X 10.6 (f.ex. http://forums.macrumors.com/showthread.php?t=236587 - notice how Remote Buddy doesn't play any role there at all? And they all have the same issue as you.. strange, huh?). You'll also find that Boxee themselves readily acknowledge that their Apple Remote support simply doesn't work under OS X 10.6 and that the only way to get their Apple Remote support to do anything (apart from blocking the Apple Remote for everything else) under OS X 10.6 is to install our Candelair driver and enable the Legacy Compatibility Mode. Just check out boxee_help on Twitter or Apple Remote related topics on IIRC Boxee's getsatisfaction page.

Fourth, if Boxee ever worked with your Apple Remote under OS X 10.6, you must already have been using our Candelair driver. The Candelair driver, however, is nothing else but the same driver that also ships as part of Remote Buddy. So if you uninstalled Remote Buddy completely - including the driver it shares with Candelair - you also removed Candelair - and with it the only way to actually USE Boxee's broken built-in Apple Remote support under OS X 10.6.

Fifth, what is so problematic about Boxee's built-in Apple Remote support is that it acquires an exclusive lock on the Apple Remote and then bases the interpretation of the events it receives not on the actual information that it receives from the system but on hardcoded internals of HID element offsets in the HID descriptor of the Apple Remote driver itself. Since these internals vary between OS releases and (once again) changed in OS X 10.6.2+ and Boxee didn't update their code to be compatible again, their helper tool currently just acquires an exclusive lock on the Apple Remote (thereby disabling all built-in OS X functionality as well as hindering all other applications from accessing the Apple Remote via an exclusive lock). The result: only Boxee receives the events, can't make sense of it and does nothing. Plus, no one else gets the events. Your Apple Remote seems to not work anymore. And, finally, if you enable an option in Boxee, Boxee will take care of its helper being started right after system startup, making it impossible for you to use your Apple Remote even if Boxee doesn't appear to run - Boxee's helper sure does.

Sixth, to conclude: you ran Boxee, with this well known OS X 10.6 issue that is ENTIRELY unrelated to Remote Buddy and that shows just as well on pristine OS X 10.6.2+ installs. You enabled this option (or it is enabled by default) so that Boxee's helper runs all the time, right after system startup. Running Boxee's helper effectively renders your Apple Remote non usable for the time it runs because of its broken Apple Remote support. Of course, you experienced this well known Boxee issue just like anybody else. Then, using the information I and my tool, Remote Control Diagnostics, provided you with, you quit the Boxee helper. You quit the software that caused you the issue (Boxee's helper) and the issue disappeared. Not really a surprise. Then you pointed fingers at someone completely uninvolved and gave him all the blame.

If you must blame someone for your issue, blame Boxee for not fixing their code and still not being Snow Leopard compatible. Not that my free HIDRemote class (which does not depend on any internals, which has none of the many other issues the code currently used in Boxee has and which greatly improves the user experience by just working) wasn't available for almost a year by now and adoption of it is pretty simple and straightforward ..

- Felix Schwarz