[t029248]

Since my original Xbox is dying (no sound, it became mute) I need to move on, I decided to tryout the alternatives XMBC versions (Linux, Windows and OSX) Since I own a MBP I could tryout all 3 of them lately.


To keep this short, there is too much reading to do before I got XBMC working on Linux and Windows (I know about the recent setup for Windows) Once I got XBMC to work on Windows & Linux I was disappointed to find out there is no native remote control support and no guidance how to make it work AT ALL. It’s so user-unfriendly not to provide an easy way to setup something as essential as remote support! (reading long forum post are not great for something essential as remote support) From a user point of view, my MBP has an recognized IR and remote why does it not work in Windows / Linux? In OSX the remote is working and also switching between Windowed and Full-screen is no problem, it already feels so finished. OSXBMC installs very quick and easy and integrates very well with OSX.


The developers OSXBMC are open and informational and Elans blog is expressing the joy he and he team have in porting XBMC to OSX (don’t lose it). In a short time it became for me the only alternative to replace my original Xbox.



I hope that Apple soon will release a new or updates Mac mini so I can start using HDTV with Barkley’s Media Center on OSX!

[topfs2]

Its probably more natively supported remotes under linux version than any off the other ports. LIRC support. WiiRemote are only supported on linux the rest work on all. Admitelly LIRC is abit rough to setup on some remotes. The installation is 3 commands in terminal and it will download and install and auto update it. The information might be abit scarse but its standard debian install so its not harder to install then on osx, just different . Id suggest you try the PPA again before you go and judge it.

[JeffElkins]

I use both Linux and OS X variants. I like em both, but the Apple remote is weak, with only dix buttons.

[t029248]

Thanks for your reply….

I searched the forum, and at the moment the info how to setup LIRC is tooooo tooo blurry, a search in the Wiki related to LIRC is not returning anything useful. To attract more people towards XBMC this should be done better. I know XBMC is a work in progress but it has been like that forever, it a WIP for so long that it have becomes an convenient excuse itself!!??

Should IR functionality not simply be integrated with the underlaying OS? The IR-Receiver is visible in the device / hardware on my Windows and Linux systems, why I can’t simply select and configure the IR further from XBMC? (it’s not cool to have too hunt around the Internet for info about this and it doesn’t feel confident) I could do all that if I build my final XBMC Box but not just to test it out, so I’m forced to test a crippled XBMC or spend / waste hours trying to make a remote work.

Could someone explain me and the users who also struggle with this, if / or why not there isn’t an IR setting panel in XBMC, an panel where we can select and configure the IR devices which are already recognized by the OS and where we can select the remote control we use? There even could be an advanced panel where we could then add custom remote controls and map the required keys manual, (selecting a function, pointing the RC at the BOX, press the button for the function) the custom mappings then could be published and integrated in later XBMC builds. (sounds simple and even fools like me could map any RC to XBMC)

I don’t see any good reason besides that it’s a WIP why this couldn’t be done, since I’m not and developer myself I don’t feel welcome to submit a patch, but I would love to test and document it! J

[topfs2]

Just for clarification, LIRC is apart of the O/S. And XBMC have little controll over it we can merely listen to what buttons are pressed by which remotes, and for lircd to send these commands it needs to know which Hardware you run.
Therefor LIRC Needs to be configured based on which hardware you have, and this is nothing XBMC is able to do, it's a design "flaw" of LIRC. The pro with this design is that it's very dynamic and I bet that is why it was selected. I have looked high and low for a way to configure LIRC from within XBMC and this is something we want to do so we aren't trying to round up excuses, it's how LIRC is designed and we either need to patch LIRC or do really ugly hacks which won't be good for the people on Ubuntu Desktop, that beeing said these hacks might be created and would probably work on XBMC LiveUSB were the sole purpose of the desktop is HTPC but generally speaking we don't want to cause harm to the system and won't risk it with ugly hacks.

Ubuntu media center is trying to create a simpler LIRC which might be able to autoconfigure it and when they have done this I'm sure XBMC will obey that instead.

It greatly depends on which Hardware you have, if you ie have MCE remote it's very easy to get running in Ubuntu, sudo apt-get install lirc and choose mceusb from the menu and your set to use it withing XBMC so please don't say we don't want it simple, we are trying to.

Also please don't say it's simple to do if your not a developer, if you are and think it's simple you are more then welcome to do a patch, I for one would love that feature but from what I know it's not simple to do..

/Topfs2

[davilla]

IR support in XBMC for OSX is pretty trivial. There's only one IR receiver/remote to support on one version of OS (10.5.xx). It's dirt simple to implement as there are numerous working source code examples available from google searches.

IR support in XBMC for Linux is much more complicated. It required 2N options for the numerous IR receivers. Some IR receiver support multiple IR remotes and LIRC has different configs depending on version which distills down to distro (gutsy/hardy for example). So given the 20+ IR receiver/remote possible under Linux, that results a large number of different configs just to get the IR remote working at the OS level.

IR support is an OS kernel/userland function in Linux. In OSX, since there's only one to support and it's already handled by the OS, it's pretty easy which to choose and how to handle it.

Eventually XBMC for Linux might have something similar when more pressing issues are resolved and dev time can be spent crafting such an item. Personally, I don't think it belongs in XMBC proper. It's an OS issue and once you get an IR remote working at the OS level, XBMC support falls into place.

[bmfrosty]

I would suggest a tool - to be run from within XBMC (assuming some mechanism for XBMC to call commands with sudo) to update lirc configuration files with files of known quantities for remotes that XBMC is known to work with. The tool could also install ~/.lircrc and scripts for controlling XBMC - like the ones suggested in the tips and tricks thread - into ~/bin or ~/scripts. This could also be used a configuration point to tell XBMC what eventclients it should be running.

I won't say that what I suggest would be simple, it would take a lot of work, but I don't think it would be rocket surgery either. If I had the inclination to learn about XBMC internals, python, and LIRC, it might be something that I would be able to take on, but I don't. C'est la vie.

[t029248]

If I understand it correctly the IR Code flows like this :
IR -> IR Hardware -> Ubuntu -> Lirc Daemon -> XBMC
The LIRC Daemon translates the IR Code to something useable in XBMC.
It could be an requirement to request an working IR-device and configured LIRC for XBMC to work fine! That probably also reduces the number of possible XBMC users on Linux with 90% due to too much complexity. LIRC would be great if it was not only flexible but also easy to configure and of course updated itself with the latest device info trough the Internet. In reality LIRC is an showstopper on Linux on Windows it’s HID that spoils the fun, bottom-line if you have something else then an MCE remote nothing works and you are left without useful information.
My point is that the OSX port solved this (simple or not) but it works, the MAC remote might be limited but something is better than nothing. I’m glad to find out that the Dev’s are trying to work this out.
If I understand it correctly XBMC using its own (optional) IR daemon is not an option because it breaks the IR functionality for the rest of the OS?

[davilla]

My point is that the OSX port solved this (simple or not) but it works, the MAC remote might be limited but something is better than nothing. I’m glad to find out that the Dev’s are trying to work this out.
If I understand it correctly XBMC using its own (optional) IR daemon is not an option because it breaks the IR functionality for the rest of the OS?

Not a simple task to write an IR daemon that handles all IR remotes. That's what LIRC attempts to provide in the first place. OSX already has an IR daemon built-in that handles it's single IR remote.

So applying the same "single remote" principle. If XBMC on Linux ONLY supported the USB MS mce IR receiver/remote (the newer one), then that would be acceptable?

PS. "MAC" stands for "Media Access Control" and refers to an ethernet device. "Mac" is the abbreviation for "Macintosh". When you say "MAC", I think you are talking about ethernet device. Yes, I'm a "Mac" fanboy

[t029248]

Not a simple task to write an IR daemon that handles all IR remotes. That's what LIRC attempts to provide in the first place. OSX already has an IR daemon built-in that handles it's single IR remote.

So applying the same "single remote" principle. If XBMC on Linux ONLY supported the USB MS mce IR receiver/remote (the newer one), then that would be acceptable?

PS. "MAC" stands for "Media Access Control" and refers to an ethernet device. "Mac" is the abbreviation for "Macintosh". When you say "MAC", I think you are talking about ethernet device. Yes, I'm a "Mac" fanboy

Better to support remotes properly then a single one but proper support for the most common remotes (MCE, main universals) would be welcome and workable for many users.

Sorry for the error, if i could edit my messages on this forum i would have altered MAC to Mac... but unlike many forums that's not possible anymore on this forum.

[topfs2]

I would suggest a tool - to be run from within XBMC (assuming some mechanism for XBMC to call commands with sudo) to update lirc configuration files with files of known quantities for remotes that XBMC is known to work with. The tool could also install ~/.lircrc and scripts for controlling XBMC - like the ones suggested in the tips and tricks thread - into ~/bin or ~/scripts. This could also be used a configuration point to tell XBMC what eventclients it should be running.

I won't say that what I suggest would be simple, it would take a lot of work, but I don't think it would be rocket surgery either. If I had the inclination to learn about XBMC internals, python, and LIRC, it might be something that I would be able to take on, but I don't. C'est la vie.

This is the "hack" I was refering to. Although I don't want to add this to XBMC linux codebase because it might destroy LIRC setup on regular desktop.
Although I have no problem sitting down and write this when the EventClients have settings and 2-way communication.

I’m glad to find out that the Dev’s are trying to work this out.
If I understand it correctly XBMC using its own (optional) IR daemon is not an option because it breaks the IR functionality for the rest of the OS?

Yeah I really want this to work easily and out of the box so rest assure sometime we will have it working, in it's current state it's abysmal. But my point was merely that it's not easy

Why we don't create an own daemon (if you mean LIRC daemon) is because it's not necessary to reinvent the wheel, LIRC is very good but it's a bitch to configure though .
Although the configuration part of the LIRC daemon must be changed either by LIRC because XBMC shouldn't be able to do it by default (mainly so we don't go round breaking stuff on your O/S) ofcourse on ie the XBMC LiveUSB solution we can have full configuration ability because we are certain that we won't break a desktop setup, just XBMC setup. The Configuration ability could ofcourse be installed on a regular desktop if desired.

[bmfrosty]

This is the "hack" I was refering to. Although I don't want to add this to XBMC linux codebase because it might destroy LIRC setup on regular desktop.
Although I have no problem sitting down and write this when the EventClients have settings and 2-way communication.

Yes... That's a danger. Maybe include a click-through warning screen?

[topfs2]

My idea was to have a setting page on the EventClient were we have a Enable/Disable ticker for configuration (Defaulting to disable and perhaps default to not have the ability at all, ie need run by lirc-eventclient --enable-configuration). And after that a selector for the HW.

But it would be very important to tell the user that this will alter the LIRC configurations

[t029248]

My idea was to have a setting page on the EventClient were we have a Enable/Disable ticker for configuration (Defaulting to disable and perhaps default to not have the ability at all, ie need run by lirc-eventclient --enable-configuration). And after that a selector for the HW.

But it would be very important to tell the user that this will alter the LIRC configurations

I just bumped into the event client and it seems to solve in theory many of these problemsn. (And it should be to compy with The XBMC manifesto
whixh says that if User-friendliness is next to godlyness and the KISS (Keep It Simple Stupid) principle need to be applied.)

I appreciate all the work being done.... i understand it's not easy ..

[platanito21]

NOTE: this message is more for the OS X team than the linux or windows xbmc teams.

I've never used any of the other XBMC ports but from what I can tell by using XBMC for OS X it seems like it is a port deriving from another OS. Some of the basic settings and the structure just doesn't feel very OS X to me yet. The one good thing I hope comes from this forking is for things to become a little more "Apple-ish." The whole way to setup and organize the library just doesn't feel as fluid as it should (I'm coming at this as a user not a programmer). To me it feels like it was designed more for someone who likes to be more hands on with everything that they do (by programmers, for programmers). In a mac world things like this are usually handled behind the scenes where the user doesn't even know its happening which makes things "appear" more easy. I think most mac users have grown accustomed to this kind of thing. When I get a piece of software I don't want to spend my entire day (or days) setting it all up. I don't want to search through forums to find out how to do something that should be simple (thats a general statement, not talking about anything specific).

I can already see the OS X version starting to get there and I know that eventually it will be so great that Apple will be shitting its pants. Keep up the great work guys and I hope that we as a mac community can continue to engage in these kind of discussions in order to make this software the best that it can be.

Oh and (as I've stated in numerous other posts) thanks to all the xbmc teams for all the amazing work you've done to get it to where it is today. Its nice to see all you guys starting to be more active in the mac support forum ;-)