Messages

466

Users / Re: wiimote almost sorted!

« on: September 14, 2007, 01:46:16 am »

I was basically short on time last night so didn't get very far at all.

Got started though, setup wiimote on a different Media Director - as that one is easier for me to test things on. No major problems there except I did have problems discovering after a reboot.

Still undecided as to where the device should live in the heirarchy. At first I thought it would be a child of the MD Device but thinking about it a bit more it might be better under the Bluetooth dongle.

Did a couple of checks on the bluetooth dongle and it is receiving events on discover mode (1+2 buttons pressed). Therefore I think the following should be possible;
1. Walk into room with an existing MD running and Bluetooth dongle
2. Press discover (1+2)
3. Bluetooth dongle device recognises new device and matches MAC address range as wiimote presents option to winstall wiimote device (much like a new bluetooth phone does now)
4. Device is installed, with all dependent packages and parameter set to MAC address of wiimote. Maybe button/key mappings can be parameters as well
5. Device is started, starting wminput appropriately
6. On restart or reload router shtdown of device is called and stops the wminput

If device goes out of range then device would be stopped.

On an existing setup that has already got the device installed the same process would work (without having to do the package/device installs). You would still need to press 1+2 to use the wiimote (and start the device) - that is why I am think that it should live under bluetooth dongle???

All this seems quite straightforward to implement. Once the device is working then we just need to ensure all the dependencies are packaged up appropriately.

Some questions I still need answers to;
1. Can LMCE detect the wiimote and bind to it without 1+2 being pressed. This would enable the wiimote to be active on a restart without having to do anything.
2. Can wminput work with multiple wiimotes? Not a big issue or anything - just thinking ahead to the concept of it being like an ID for each family member. If they are using their wiimote then LMCE would recognise which user is controlling the orbiter. This makes cheking voicemail etc easier and can give them different UI.

There is also potential for Follow-me functionality to be tied to the wiimote. Basically, any of the mobile orbiter functionality could be contenders due to the use of bluettooth.

Anyway, first things first - need to get the device running with the basic wminput start/stop functionaility first. Job for the weekend now as that is the first chance I will get.

Regards
Darren

467

Feature requests & roadmap / Re: mobile phone remote control???

« on: September 13, 2007, 06:47:42 am »

No I don't think this phone is supported as a mobile orbiter.
Only some Symbian and some Windows Mobile phones are supported to my knowledge.

468

Users / Re: Many questions

« on: September 13, 2007, 01:36:29 am »

1. LMCE pretty much needs to be the DHCP server if you want diskless network boots for the Media Directors. From the sounds of it though - you are just running one LMCE machine and using the other machines as file stores so you don't need to boot any Media Directors and therefore don't need to run DHCP on the CORE/HYBRID. There a few other threads on this already.
2. No idea. You could try it and I would have thought with a bit of persistence it would work. Simulating the same subnet would probably be necessary.
3. No, only the x86 version is built.
5. That should not be a problem.

HTH
Darren

469

Users / Re: wiimote almost sorted!

« on: September 13, 2007, 01:24:26 am »

I think we should make it into a device that gets started when the media director is spawned.  I'm hoping that a simple script will suffice, just starting wminput in a loop, but maybe there has to be some sort of "locking" as well.

I think that is probably the best idea actually. It only really needs the Startup/Shutdown events on the device to start/stop the appropriate wminput stuff.
Advantage would be timing should be better aligned with bluetooth stack loaded and "Quick Reload Router" should allow you to reinitialise it if needed. Scripted device should be fine.

Will have a go at this tonight... if noone beats me to it.

Regards Darren

470

Developers / Re: Keyboard Mappings

« on: September 12, 2007, 01:01:36 am »

Rob,

Thanks for the help - but basically my remote is not using LIRC at all, instead it sees the remote as a keyboard and uses the appropriate keyboard driver (usbhid from memory).

I can actually load the lirc_mceusb2 driver successfully but the kernel is not probing for this driver because as far as it is concerned there is no free interfaces for the device. This is because it has used the keyboard driver for the device.

I tried for a while to get it to use the lirc driver instead of the keyboard driver but without really hacking it would just not call the probe callback in the driver (the hack was to rmmod usbhid and explicitly modprobe a rebuilt version of lirc_mceusb2)

So I checked that all the keys worked as keyboard keys (just ran showkey and pressed them all) and the ones that currently work are the ones that are using the same key codes as a normal keyboard. So I can basically control linuxMCE to a limited extent. There are a few weird mappings (like mute seems to operate the same as F8) but there are also quite a few buttons that don't seem to work (mainly the media control buttons).

I know that I can change the X windows mappings for keys so if I know what keycode that linuxMCE expects for say PAUSE(assuming there is one of course) then I can map my pause button to that and hopefully that will give me a fully functional remote(keyboard?). A side effect would also be that if I find out all the expected mappings for the functions then it should be quite straightforward to also map normal keyboards that have media player type keys on them.

I am starting to think that it may be a code change to orbiter or another device that sort of does the same thing as the LIRC_DCE based devices, but hoping that someone knew more.

Hope that explains it a bit better.

Regards
Darren

471

Developers / Keyboard Mappings

« on: September 11, 2007, 01:57:36 pm »

Just checking if someone has done the following before I invest any more time in it....

I have purchased a cheap "Windows MCE Compatible" remote which comes with a USB receiver - thinking that this would just work using LIRC and the lirc_mceusb2 driver.
When I plugged it in straight away a few of the things worked and I can basically use it as a mouse but LIRC didn't want anything to do with it.

It turns out that it emulates a keyboard and that it loads a keyboard driver for it. I tried rebuilding the lirc_mceusb2 driver with support for the vendor/device id but it seems that it would prefer to allocate the keyboard driver as a preference.

A few of the keys map to standard keyboard keys like the numbers and the arrow keys, however there is a lot more keys including media control keys like play, pause etc and volume up/down, channel up/down.

So firstly does anyone know if orbiter has keyboard equivalents for media control and if so what are they all? I guess knowing this I can use Xmodmap to assign all the remote keys.

Alternatively, does anyone else have any other ideas before I start looking through code... Anyone looked at this part of the code??

I also have a wireless keyboard that has a bunch of media keys along the top. It would be good to get those working too.

Regards
Darren

472

Feature requests & roadmap / Re: Control XBMC via HTTPAPI ?

« on: September 11, 2007, 01:15:41 pm »

James,

Great idea, didn't realise that it had this API. Should be possible.
Probably could even just be done with a Ruby device rather than a C++ one.
Got a few things at a higher priority at the moment - but someone else(you?) might be willing to give it a try.

Regards
Darren

473

Developers / Re: KDE on Diskless MD??

« on: September 10, 2007, 02:18:15 am »

If I understood what you were asking correctly ....
Then I think the answer is No, it does not work like you are asking (and probably will not).
IE: The MediaDirectors run everything locally using their own resources (CPU, Video, RAM  etc).
The system is a distributed system, it is not client/server. There is a messaging system that operates client/server using a centralised broker on the core (DCERouter) but this is for communications between devices.
Now the bit that confuses this a bit is that the storage for the Media Directors is centralised and typically a media director will not have a local hard drive, but will instead network book, mount a network drive as if it was local and then run the OS on top of that. This includes mounting the media directories so that effectively the media looks like it is local to the MD but in fact (along with the rest of the OS) it lives on the core machine.

The other part of your question asking about switching between the desktop OS and MCE. I believe that this is possible, but it is not how I run it so I will let others confirm. Keep in mind though that everything is still running on the local machine using local resources (not thin client).

I think linuxMCE will still probably meet your objectives - just the Media Directors need to be higher spec'd machines than you hoped for.

HTH
Darren

Just noticed djrobx post beat me to it - at least we were saying the same thing

474

Users / Re: MythTV Observations, ugh.

« on: September 05, 2007, 02:03:28 pm »

I was not suggesting to have it removed. I was trying to gauge the importance to others.
Just to see where priorities should be placed.

475

Users / Re: MythTV Observations, ugh.

« on: September 05, 2007, 06:34:58 am »

As far as im concerned TV is one of the most important things of a media center.

What are others thoughts on this. Having used a Tivo for a couple of years - I can't remember the last time I watched live TV. Even sports etc I will start watching 15min or so after it starts. ie; I record everything that I want to watch.
So I only really see MythTV as being a replacement PVR - which in a linuxMCE scenario could mean not even having to use the TV button (assuming recording is done via the web based interface).

476

Users / Re: use australian community guide for EPG?

« on: September 05, 2007, 06:26:41 am »

You don't need to buy a wii though. I just bought a controller off ebay.

Got it working on the desktop last night, will try with linuxMCE when I get a chance.

477

Users / Re: LMCE vs Pluto(home)

« on: September 04, 2007, 06:59:27 am »

See http://wiki.linuxmce.com/index.php/History

My main reason for switching to linuxMCE from Plutohome was that the Pluto release schedule had seemed to grind to a halt. I have a few opinions on why that might of happened.
linuxMCE has certainly generated a lot more interest and this seems to be a combination of naming (linuxMCE is a lot more explanatory than Plutohome) and marketing (video has done wonders). linuxMCE is releasing regularly and in my opinion is a more stable and feature rich product than Plutohome 0.44, but it is afterall an evolution. Pluto have not had a release since linuxMCE existed from memory.

At the moment I don't necessarily agree with the concept of integrating the whole project with standard desktop distros (KDE), although certain Media Director functionalilty could be. But I am prepared to see where Paul and others go with this.

478

Users / Re: use australian community guide for EPG?

« on: September 04, 2007, 05:53:55 am »

macca - I don't think that it is possible to use the external inputs and the tuner at the same time. The input seems to act as a switch and allows you to switch between the inputs (svideo, composite, tuner)

I also have one of the leadtek cards but can't help you with the remote though as mine is in the CORE machine under the house so not much need for the remote there. I use homemade serial infrared receivers for the remotes.

I just got a wiimote as well so I can try what atreidae is doing....

479

Users / Re: MythTV Observations, ugh.

« on: September 04, 2007, 05:47:08 am »

It's good to see some discussion on this sort of stuff (probably should be in the developers group though).

I don't think that we want to be coupled to MythTV too closesy. Not because its not a good product or anything but moreso due  to it restricts our development to the timeline and development of the MythTV project. 

Integrating at the API level may be more work (in building GUIs) but gives us more flexibility in producing a good solution. It also enables us to have a common GUI to multiple applications allowing best of breed implementation. eg: VDR may be a better liveTV/PVR implmentation for some people using different hardware.

I understand that we might not get some of the best bits of some of the applications, like OSD capabilities, but if the project is to be more than a MythTV wrapper then I think that is what is needed.

Again, this is my opinion and I appreciate yours.

I am interested in the ideas from the Myth database that you think would be useful. What exactly are they?

480

Users / Re: LinuxMCE Core and Orbits

« on: September 04, 2007, 05:33:15 am »

What dopey said was right but I just wanted to add...
The video card is still important (in fact the most important part IMO) for playing the media. So your media directors do need a good video card even if they are not running UI2 with Alpha Blending. Even then is is more about getting a video card driver that supports the compositing that alpha blending requires. But if your core is not acting as a media director and not playing video then pretty much any old video card will do.

The on screen orbiters (or any orbiters) are designed so that that they can control any device in the house. If you tell it what room you are in (or it detects it) then you will get a user interface for that room. So for instance, I could be in the lounge room and using the on screen orbiter of the media director in that room I could tell the system to play music or a video in another room.
Hope this helps (rather than making it more confusing)