Author | Thread |
User 02.08.2007 01:03:13 |
This posting is older than 6 months and can contain outdated information. I'm really enjoying the functionality provided by Remote Buddy, however I have a problem activating Front Row through RB menu via a Wiimote. I am using Remote Buddy 1.1 and (obviously) the kernel extension 1.4.5. I can activate FR using cmd+esc. Doing this for the first time loads FR into memory and I can view the process running using Activity Monitor. Once in FR I can control the menu using the Wiimote and also exit etc. However, RB displays some interesting behaviour when I try to activate FR using the Wiimote (even after the process is running via cmd+esc). When I select "Activate Behaviour" via the RB menu instead of fading out the menu (as with all other activation commands) it instead disappears instantly. If FR process has not been loaded before (straight after reboot) then it does not load into memory and I have to hit cmd+esc to bring FR up. If FR has been loaded previously using cmd+esc and is still resident then RB thinks that FR has been activated even though I do not see FR on my screen. I know this because I now need to hold Button B on the Wiimote for 2 seconds for the RB menu to appear. In the RB menu it has changed from "Activate Behaviour" to "Deactivate Behaviour". I can also not access FR using cmd+esc now. The only way to fix this is to quit Front Row via Activity Monitor. So in short, I cannot access Front Row via RB using Wiimote. Every other behaviour and program works fine. I have applied Front Row update (1.3), reinstalled kernel extension but have had no luck. Has anyone else encountered this problem or have a solution? Thanks for your time. kim UPDATE: OK I've had a chance to play around a bit more and I think I've fixed the problem. Since FR was not installed natively on my computer I added an instance of the key HIDRemoteControl to my Info.plist in AppleHIDMouse.kext to allow FR to be accessed via cmd+esc when RB extension is not loaded. See http://www.osxbook.com/book/bonus/misc/frontrow/ for more details on this. This also seemed to fix the issue above. Last edited: 02.08.2007 13:45:24 Last edited: 02.08.2007 13:46:09
| These entries from the FAQ may be relevant to this topic: Behaviours
There are several possible error sources:
- The application has been installed after Remote Buddy has already been launched
For efficiency reasons, Remote Buddy only searches for supported applications when its started. If you have installed an application after launching Remote Buddy, please quit Remote Buddy and launch it anew.
- Oudated program versions
The installed version of the program in question could be outdated and identify itself with a different Bundle Identifier than the version supported by Remote Buddy. This problem often occurs with Mplayer OS X. The most recent version of that application is not to be found on Sourceforge but on directly on the pages of Mplayer HQ.
- Custom menus
If you use a custom menu in Remote Buddy and you don't make use of Remote Buddy's smart folders, the menu structure is static. You have to manually add the behaviour into a place of your choice in the menu.
- The behaviour is deactivated.
Make sure, the checkbox in front of the Behaviour's name in the Mappings pane of the preferences is active.
- The Launch Services database is outdated.
Remote Buddy uses Launch Services to check for the availability of an application on your Mac. If the Launch Services database of OS X is incomplete or outdated, so is Remote Buddy's dynamically created menu. The solution, though is easy. Download LSRefresh, launch it, select the application(s) that don't turn up in Remote Buddy's menu, wait until the update is finished and then restart Remote Buddy.
Driver The Setup Wizard already contains a summary on how the driver does help Remote Buddy to provide additional features and hardware support. If that summary was too short, here's some more info on each of the points:
- fix for Apple® Remote driver problems in OS X
Since OS X 10.4.9 (that includes 10.4.10/10.4.11/10.5.x/..) many users have been experiencing that one button press on their remote does now trigger two reactions - once from any currently running application that supports the Apple® Remote, once the default system action. So, this problem is not specific to Remote Buddy. The driver provides a clean, system conform fix to this problem using only documented APIs.
- enabling of all features of built-in IR receivers
Only with the Remote Buddy driver do you gain support for arbitrary length button presses for the Play and Menu buttons as well as minimized reaction times for all buttons. While this may sound like unimportant technical details, they actually do have a strong practical impact. If, for example, you want to map a function to the Play or Menu button, that you want to see executed for as long as you press that button, this was previously simply impossible to achieve. This limitation still applies to all other applications. It does not for Remote Buddy with the driver loaded.
- the emulation of a virtual Apple® Remote
Control applications that have support for and listen to an Apple® Remote - with any remote control of your choice supported by Remote Buddy. And on any Mac®. This allows you to f.ex. use iAlertU side by side with Remote Buddy or accessing special functions and modes inside applications that would otherwise require these apps to have full control over the built-in IR receiver of your Mac® - and that your Mac® actually came with one.
- support for Bluetooth® remotes and external receivers
It's not possible to reliably operate many Bluetooth® based remotes, like for example the Wii® Remote with a Mac® purely from userspace due to limitations in the operating system. The situation for many external receivers is similiar: some of their features - or the entire device - can only be supported with the help of a driver.
Hardware - Apple® Remote
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. 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.
Please update your copy of Remote Buddy to version 1.15 or later.
Hardware - Wii™ Remote Built into the Wii™ Remote is an infrared sensor, that can locate several, punctual infrared light sources and report their location to Remote Buddy.
It's impossible to determine the position of the remote control - and thus also moving the mouse cursor - without at least one of these infrared lightsources.
When using the game console, the so called sensor bar is supplying this IR light source. The name is a bit misleading, as it does not contain any sensors at all, just IR diodes, that emit light in the IR spectrum - which is invisible to the human eye.
If no sensor bar is available to you - or if the IR diodes in it are currently turned off, another infrared light source is required. Infrared radiation is also called heat radiation. Simply said, when there's heat, there's infrared light, too. Using this physical phenomena, you can also use very hot objects as infrared light source - whereas f.ex. tealights and candles are especially predestined. Always make sure to exclude the possibility of a fire and any other risks, when using burning candles, tealights or very hot objects,
An infrared receiver can not be used as infrared lightsource. It can only receive, not emit infrared light.
TV sets and monitors don't create light in the infrared range that would be strong enough, either.
In order to use the infrared mouse mode, you have to point your remote control to the IR lightsource. You can easily check, whether this source is strong enough by having a look at the options of your remote in Remote Buddy's preferences (in the Hardware tab). There, all light sources recognized by the IR sensor are displayed for as long as the IR mouse mode is active.
You can find more information on infrared light on f.ex. Wikipedia (Link to external article).
| Thread-display::- Frontrow not activating, User, 02.08.2007 01:03:13
|
|