I am just about finished with the implementation of an XBMC remote application for the Philips Pronto PRO (9800/9600 and adaptable to the 9400).

It drives the XBMC system using its HTTP API interface over TCP/IP (Wi-Fi) I have the basic code working to do all of the available operations including Wake-on-LAN and shutdown. It is table driven so can be easily modified or extended.

I also have the capability implemented to spin disks up or down on an unRaid NAS.

I am wondering how much interest is out there for this application

Hi Barry

What do you have XBMC running on, at the moment i have it on a Apple TV controlled via IP.. (Pronto Tunes), but the apple tv is a bit slow :(

Hi Barry, very interested =)

I am interested in learning more abot this as well.

Hi Barry, I have just installed XBMC last night and was starting to think about coding something based on the Official XBMC Android remote control, so your timing is excellent for me. Needless to say, I am very interested!

sounds great! but isn't xbmc going to change the way you can control it over ip?

Quote:

HTTP-API

NOTE: As of Dharma, the HTTP-API is depreciated - use the JSON-RPC interface instead


[Link: wiki.xbmc.org]


Discussion about this:

[Link: forum.xbmc.org]

I'd be interested

Hi Barry, very interested =)

as long as it works

A couple of comments:

What I am developing is for control purposes only and has not implemented any download capability. Its purpose is to control the XBMC system as a fully functional IR remote associated with a commercial media player appliance would. My rational is that XBMC has a superb GUI and on screen library presentation. I am looking at the XBMC for video only as I use SqueezeServer for music.

I have built the application to be table driven so it is very flexible. In fact the current experimental/testing/learning version has some commands implmented as buttons (e.g. transport control, cursor navigation, etc.) but also has the ability to bring up the lists of all possible HTTP API commands for execution.

Converting from HTTP to JSON should be (for the most part, if not completely) just a matter of changing the tables and the reply analysis.

I am not sure what version (I run XBMC LiveCD 9.11) of XBMC is required for JSON and have posted a query on that subject in the XBMC forum

My intent is to develop decent documentation so that others can add to and modify the code simply and without too much difficulty. In essence I will be trading speed and efficiency for ease of modification and ability to understand what is going on.

I have written it using some libraries I have developed (subroutines, basic TCPIP, POPUP management) that are in somewhat rough form as I am not yet confident regarding my understanding of the Library implementation in PEP2.4 (System level vs activity level, check vs no check, include vs no include, namespace requirements, and lastly Scope.)

JSON will be implemented in the 10,x release, called Dharma which is due soon. Betas of this can be found under Nightly builds at xbmc.org

[Link: mirrors.xbmc.org]

Thanks nimnul, I did find what you pointed to. I also found XBMCfreak which also releases a live CD image

I will probably download a copy and install it on the asrock. From what I have read it should be a simple change to go from the HTTP api to the JSON api, especially since I want it as a control interface only. In fact I am using very similar code to control the XBMC system, a Dune player, a Vudu player and a Sony CX7000ES mega changer.

I need to do regression and feature testing to ensure that all the tables are correct.

In operation a button press makes a queue entry of text that contains, the component routine for sending, and the command name to send ( e.g. workQue.unshift("SendXBMC('CursorDown')"); ). This guarantees that user actions are always caught and preserved. The work que is inspected FIFO and an entry is used as the argument of an eval function executing the correct transmission function with the provided parameter.The send function uses a TCPIP library to build a socket, connect, send, receive a reply, process it with the correct analysis function and finally release the socket. All tcpip work is done async, with the assumption that only one tcpip request is in operation at a time. This is reasonable for a control only environment.

Also add a command to start XBMC in windows. (I use W7 and XBMC)
Its pretty easy to assign a keystroke as a trigger to the XBMC shortcut in windows. So I use "F10" to start XBMC.

The reason for not running LIVE is that PC is also showing our national broadcasts over a web browser, great for things you missed.

I guess you dont have to bother with XBMC LIVE.

To start XBMC under windows, how about if there is a small little app running on the windows machine (launched at boot, or as a service) that monitors a specific port and when it gets a specific message it will launch XBMC. Trivial to write and I will supply it for those who need it. Obviously it could be made into a full keyboard emulator/application launcher, but then again there is Girder.

Barry, What command do you send to the unraid server to spin up the drives?