User

29.12.2009 00:11:07

Hi

I bought latest MacMini and the new alu Apple Remote. I use my mini as a HTPC machine with PLEX. Unfortunatelly, the only app receiving all of my remote button clicks is MacOs/FrontRow itself. When I use Plex or Remote buddy, than 30-50% of my remote clicks are "lost somewhere" even when standing a few inches in front of Mini. So it looks like some problem with 3rd party apps? I tried installing candelair as well - no luck.

I'm using: 
MacMini 2.26Ghz 2GB RAM 
Snow Leopard 10.6.2 (All latest updates installed) 
Alu Apple Remote 
Plex 0.8.5 
Remote Buddy 1.16 (Trial at the moment)

Any ideas? Anyone else with the same issue? Most important: any solution or workaround available? I'm unable to find anything for more that week now :/

Thanks in advance for any help

User

29.12.2009 12:29:21

Thanks for asking.

This sounds like a classic reception - not software - problem. Please make sure

1) you have a direct line of sight between your remote and the IR receiver of the Mac Mini (its located in the right corner of the DVD slot drive)

2) you don't have any direct or reflected sunlight on the IR receiver, which could make it hard to impossible to the IR receiver (yes, the IR signal is decoded in hardware by the IR receiver itself, so the software running on your Mac simply can't have any effect on whether an IR code can be decoded/detected or not) to detect/decode IR codes because there's too much noise and too little signal

3) to take a look at the FAQ

Best regards, 
Felix Schwarz 

User

29.12.2009 18:22:44

Hi Felix,

thank you for your kind reply, but i have to disagree with your opinion. 
I have these losses no matter if there is day or night, if the room light are on or off, if i have my remote two inches in front of the MacMini or I'm standing across the room.

If i quit remote buddy and plex, run FrontRow, the reception is almost 100% - let's say - works flawlessly.

There must be some other, software, problem.

Any other information I can provide do debug this? 

User

29.12.2009 20:37:41

I'm sorry, but this isn't my opinion, but simply how it works. The built-in Apple IR receiver completely decodes the IR signal *in hardware* and directly outputs the result to the driver, which really can't do anything wrong with that data.

Add to this that Remote Buddy's driver is also used when you quit Remote Buddy and - unless you have uninstalled the driver and rebooted - also creates the events used by Front Row.

Plus you're the only one who has reported any issue.

As I said before: this is not a software problem. I already listed two common physical problems. You'll find more possibilities in the FAQ.

Best regards, 
Felix Schwarz 

User

30.12.2009 12:16:37

On 30/12/2009, at 6:37 AM, Felix wrote:

 
I note the stars around "in hardware". Of course it is not done in hardware, it is done in a level of software that Apple tries to keep out of your reach. Maybe EyeTV grovels down there somewhere and that is what upsets Remote Buddy. Do you have any contact with the Elgato people?

 
Hate to say this, but I have this issue too. See my previous email! 
and really it is not physical.

 
Some really odd stuff happens with a combination of Remote Buddy, EyeTV 3.3 and Front Row on current MacOS. I am finding it hard to diagnose because it does not always seem to be consistent. Shutdown either EyeTV or Remote Buddy and everything seems to work as it says on the tin, but with both running it is hard to get consistent results.

I will keep hacking on it and try get some useful fault reports.

Bill 

User

31.12.2009 00:13:34

 
 
I do not argue with that as I dont have the needed low-level knowledge.

 

 
This is the part i don't understand. Remote buddy is supposed "not to change anything in system". How is possible to uninstall driver only? I found only FAQ how to uninstall Remote buddy itself. Or you mean Candelair ? If so, I was experimenting with and without it and of course with restarts.

 

 
Looks like there two of us now :)

 

 
I really do not want to start arguing, but simply - I dont agree. I made A LOT of tests lately and I have conclusion, it is somehow software related. Frontrow works flawlessly for an hour of desperate clicking and waiting for any loss. Everything is rock solid. If I run remote buddy and/or Plex, I'm experiencing losses. Obviously, this can not be physical issue in any way. 
Interesting finding is, that frontrow works flawlessly even when remote buddy is running. Maybe some problem passing the decoded IR codes to the target 3rd party applications? Or latest FrontRow uses its own driver no matter what?

User

02.01.2010 17:42:47

 
 
With regards to the Apple Remote, these are only around for the EyeTV Receiver, which is a different piece of hardware than the Apple IR Receiver that is being talked about in this thread.

 
This isn't the case.

As I said before:

The IR signals are received and decoded directly inside the Apple IR Receiver and NOT by any OS X driver or part of OS X. Of course the receiver hardware will run some kind of firmware, but I don't consider this a part of OS X (since firmware, by definition, is OS independent and will and doesn't work any different under Windows, Linux, ..) nor any attempt of Apple trying to keep anything out of anyones reach. It's normal for USB devices to have firmware to communicate via USB just as well as the kind of IR receiver Apple uses has been around before and is known as "HID receiver". The opposite are "raw receivers" that just pass through the raw IR signal. The Apple IR receiver, however, does not do this.

In the scope of this discussion, the question was whether there's any difference whether Remote Buddy can have any impact on the quality of decoding the IR signal. Since the Apple IR Receiver is a normal HID receiver (and is actually showing up and behaving as a normal HID device on the USB bus), where the decoding of the IR signal is happening directly inside the receiver itself and not by any driver, there can't be any differences. A difference could only be possible when receivers like the Microsoft MCE receivers are used which - unlike the Apple IR Receiver - do provide access to the raw IR stream without any protocol parsing.

And just to answer the logically next question in advance, too: no, Remote Buddy doesn't load its own firmware on the Apple IR Receiver nor does that receiver need any firmware upload. The firmware that is part of the Apple IR Receiver is used at all times.

 
I'm sorry, but since the IR signal is decoded by the IR Receiver itself, the driver code really is dead simple and I can't see how code that effectively looks like this

[..] 
if (receivedValue == 0x01) { buttonPress = kButtonCodeLeft; } 
if (receivedValue == 0x02) { buttonPress = kButtonCodeRight; } 
if (receivedValue == 0x03) { buttonPress = kButtonCodeReleased; } 
[..]

could behave randomly or not consistent all across the board.

On the other hand, unconsistent behaviour *is* the rule for physically originated problems. Which can have many origins from light to the position of the sender and receiver, to how (and if) the surrounding reflects IR light - and even the shape of the sender:

The new Apple Remote, for example, *does* have other physics than the old Apple Remote. Take a look at the IR window on the front: the old Apple Remote had a broad window over the full width of the remote. The IR diode did rake out of the white plastic case and could send freely in all directions. Compared to that, the new Apple Remote's IR window spans only about 30 percent of the remote's width and the IR diode is completely embedded inside the casing, limiting the directions in which the IR signal is emitted from a full 180 degree (a half sphere) to just a fraction of an estimated 90 degree.

If you have both, feel free to fire up Photobooth and press a button on your remote, then check in which angles you can see the IR diode flash.

 
EyeTV is now using my HID code (as publicly available at http://www.iospirit.com/developers/hidremote/ ).

Remote Buddy uses its own driver.

When Remote Buddy is not running, EyeTV uses my HID code to receive Apple IR Receiver HID events - sent by the Remote Buddy driver.

When EyeTV is not running, Remote Buddy continues to receive events just like it does when EyeTV is running. It makes no difference.

When neither EyeTV nor Remote Buddy are running, Front Row receives the exactly same HID events like EyeTV from the Remote Buddy driver.

Resumée: effectively the same piece of code is used in all cases / scenarios. So where's the difference? There's only one:

Some apps (like EyeTV, Plex, Remote Buddy, ..) distinguish between long and short presses in all circumstances and react differently to them.

Others (like Front Row) don't always do (f.ex. two short presses in a list behave like one longer press). You're of course going to notice the consequences of physical problems much quicker if you use apps that do distinguish vs. apps that don't. Bad reception or a too high signal-noise ratio can lead to signal interruptions or a corrupted IR start sequence that the IR sensor can no longer make sense of.

That doesn't make such issues software issues, though. The origin remains physical.

Best regards, 
Felix Schwarz 

User

02.01.2010 18:30:37

 
 
I don't want to argue, either.

 
One needs to distinguish between two separate things:

- the stock Apple OS X driver for the Apple IR Receiver 
- the Remote Buddy driver (also available seperately as the core part of the Candelair package) for the Apple IR Receiver

Remote Buddy doesn't need to change/remove/patch/.. any system files in order to use its own driver. And it doesn't need to hack/patch/modify/.. any part of the system at runtime to do this either. Apple provides clean, publicly documented OS X APIs for this.

 
It can. Please see my - really detailed, really lengthy - reply that I wrote prior to replying to your post for details.

 
That actually contributes to the conclusion that this is a physical issue. Front Row in most places doesn't distinguish between long and short presses and you're much less likely to notice any effects of a physical issue than if you're using an application that does react differently to long and short button presses. An application that doesn't distinguish won't show any different effect between two short button presses - and - one longer button press. Compared to that, the difference in an application that does will immediately be apparent because the reaction is different than you'd expect and as you *could* expect if the IR signal was received correctly in its entirety.

 
All events are handled identically inside Remote Buddy and its driver. No difference is being made between EyeTV, Plex .. or Front Row. It's always the same code at work.

 
No. When Remote Buddy is installed, Front Row is using Remote Buddy's driver as well. And when Remote Buddy is running, Remote Buddy actually translates the button presses it receives into cursor key strokes and sends these to Front Row.

I've the greatest interest in Remote Buddy working as perfect as possible everywhere and for everyone. So, rest assured that if anything suggested this was a software issue, I wouldn't hesitate to send you debug tools and ask for the output. I've done it in the past and I'm not going to change this.

But if, like in this case, all indicators for a physical problem are so crystal clear (to me at least, but I've also spent most days of almost the last 4 years with remote control and IR topics and the Apple Remote in particular - on a low level - if that counts) and any additional information I get actually supports that it's a physical problem following pure logic, I'm afraid I can't do more for you than to repeat myself, which doesn't really help anybody.

I've now spent several hours on this thread basically explaining the same over and over again with growing level of detail. I'm afraid I can't do more for you than that.

Best regards, 
Felix Schwarz

P.S.: I recall a past thread with comparable intensive and detailed debate. It was about Bluetooth/WiFi interferences. This, too, was a physical problem and correctly identified by me as such (BT/WiFi sending over the same 2.4 GHz band). It, too, was attributed to Remote Buddy by participants of the discussion and if I recall correctly, their tendency was to not believe my argumentation that it's a physical problem. What happened since then? Months after the discussion, Apple put up a knowledge base article saying exactly the same as me and suggested the same workaround (using a 802.11n network, which operates on a 5 GHz band and doesn't conflict with 2.4 GHz Bluetooth) .. 

User

03.01.2010 12:40:34

Hi Felix,

thanks for lengthy and detailed reply. 
As I have no known interference in my room, I believe that new alu apple remote might be the problem itself? If so, I have no way to resolve this issue right?

You also wrote, that FrontRow is not waiting for long presses and that it reacts immediately. Is it possible to configure remote buddy to act like this globally? That means disable the support for Hold (Long presses) and send keystrokes or codes to target app right after receiving it? Or remote buddy already does so and Plex needs to implement such a behavior?

I really appreciate your help - Thanks!

User

08.01.2010 07:16:16

Sorry to muddy the waters here, but Felix I think you might be mistaken. I'm having a similar issue. In case the problem, might not have been completely described (or fully understood) by the original poster, let me describe my particular symptoms:

I just purchased one of the new Apple aluminum remotes. I also have a Keyspan RF remote that I was using before. I have the seven buttons on the Apple remote mapped identically to seven of the buttons on the Keyspan remote. Currently, both are enabled.

In EyeTV, everything works fine, for both remotes. 
In iTunes, everything works fine. 
In DVD Player, everything works fine. 
Navigating Remote Buddy menus, everything works fine.

In Plex, however, the 'up' button on the Apple remote does not work. All other six buttons work with the appropriate Plex functions, as set in the Mapping pane of Remote Buddy Preferences. All seven buttons on the Keyspan RF remote, including the 'up' button. I can navigate to quit Plex, and with no physical differences (I'm sitting in the same place, the same lights are on in the room, etc.) the Apple remote once again works perfectly outside Plex.

I don't see how a hardware issue would cause the remote to work perfectly everywhere except in one software program. I have the 'up' button mapped to 'navigation:up' for Plex in Remote Buddy's preferences. Seems to me the driver is not communicating perfectly with the remote control and that Plex function. I'm not surprised or offended, since the remote is new. But we did pay for the program, and it's not working. So I think it's worth looking into this issue.

Questions for the other posters, so we can nail down the issue more precisely: do you have problems only with Plex, or with other programs too? Is it only certain buttons that have problems?

Last edited: 08.01.2010 07:19:27 

User

08.01.2010 07:43:58

UPDATE: was messing around some more, and tried mapping the 'up' button to Virtual Remote->Virtual Button Press Up and now it works perfectly. So the problem seems to be in the Plex->Navigation:up mapping function. (For me, anyway.) For those having problems in Plex, try using the Virtual Remote mapping instead of the Plex mapping and see if it helps.

As I reflect on it, this may well be a problem in Plex, not Remote Buddy... as nice as it is, Plex is far from being a finished product, and there are plenty of bugs in it. Or maybe it's not even a bug, but just a minor change that happened with its menu navigation, and Remote Buddy didn't realize it. (Plex changes a lot with each version, it must be maddening to support it (but please continue to do so!))

Anyway, hope this information helps everyone. 

User

08.01.2010 10:26:46

Thanks for asking.

What you describe is most likely not a problem of Plex or Remote Buddy nor should you need to use the Virtual Remote. Instead, it's most likely a consequence of changing the global mapping table for the Apple Remote.

Since this particular topic has been discussed before, please let me just point you to my summary post for more info:

http://www.iospirit.com/support/forums/remotebuddy/singlethread/14439/

Best regards, 
Felix Schwarz 

User

08.01.2010 21:12:34

That's not it. I should have included more information in my post, to more precisely identify the problem, but I'll add it now:

I'm using OS X 10.6.2, Plex 1.16 with the latest firmware update, and Plex 0.8.5. No buttons are assigned to anything in Global Mapping. The six 'old' buttons are assigned to standard Plex functions in Plex (up/down/left/right/enter/menu) and the 7th is assigned to 'Context Menu.' Under this setup, in Plex, the Up button is not completely functional. Before I just said it didn't work, but here I'll be more specific: about 8 of every 10 button presses have no effect. Sometimes it will cause the cursor to move up in the menu, as intended... but it is rare and unpredictable. The other six buttons all work flawlessly.

The Up button does not have uniform functions - in various applications it does different things, from menu navigation to volume control to executing custom-written applescripts. All of those functions work flawlessly.

Changing the assignment of the button in Plex from Mapping->Plex->Navigation:up to Mapping->Virtual Remote->Virtual Button Press Up makes the button work flawlessly. The other six buttons are still assigned to their Mapping->Plex functions and continue to work flawlesly.

Frankly, this setup works well for me since I made that change, so I'm not too worried about the problem. But it is a problem, and I feel you should be aware of it. Based on my testing the remote control, the IR receiver and Global Mapping are *not* causing the problem. Based on my experience and reading a few posts around here, I see a pattern with three things popping up every time: 1) the new seven-button aluminum Apple remote; 2) Plex; and 3) the Plex functions in Remote Buddy's Mapping pane. The problem lies somewhere in the combination of those three things. 

User

11.01.2010 01:57:26

It seems to me that too many apps are trying to manage the interaction between Front Row and other software like EyeTV and Plex. The result is chaos and unpredictability.

I put up a support request suggesting that it be possible to disable the RB OSD and application management so it becomes purely a remote code re-mapper. I will also suggest similar options to disable Front Row integration for the developers of EyeTV and Plex.

Maybe others could do the same.

Cheers 
Bill Northcott 
On 09/01/2010, at 7:12 AM, Silas wrote:

User

12.01.2010 20:50:10

Bill, that's irrelevant to this issue. To go on a tangent:

What you ask for is *precisely* what RB gives us: the ability to use the Apple Remote with many different end-user programs, but only have it communicate with a single program (RB) which will control its different behaviors. I agree that the RB menu is... less than perfect, but that's why I don't use it. It's completely optional. Just go into RB's Preferences,in the Mapping pane, and remove the RB menu from all buttons. Then just assign the buttons hoever you like. For utter simplicity, assign them in Global Mapping and they'll be the same in every program. This flexibility is exactly what makes RB so great. 

User

16.01.2010 21:39:44

Hello Felix,

this is a last post regarding my problem. After a long weeks, I managed to find a problem and everything works fine right now. And obviously - you were wrong :) Although the problem was not on the RB side. I switched to the very lightweight Plex skin (PlexXTV) and disabled all the unnecessary graphics fun and guess what - all the presses work just great now! So the issue was - As I supposed on the software part of the whole problem.

Anyways, I just bought a copy of Remote Buddy as a appreciation of your work and a time you had to came through with my issue.

Thanx