please make a ticket @ http://svn.linuxmce.org/ ... thanks

-Thom

Once you're back up and running, we need to make a ticket so that we can improve the RAID UI in the web admin, to help deal with these issues.

-Thom

Please add a bug in the bug tracker, so I can keep track of it, and work on it when I get a chance, thanks.

http://svn.linuxmce.org/

-Thom

I did some more digging with regards to the HDMI matrix support.

We have a database table, DeviceTemplate_Output, which can be used to create outputs for a given device template.

It consists of three relevant columns:

* FK_DeviceTemplate, this specifies the device template that this output belongs to.
* FK_Command, this specifies what command should be sent to the matrix to select this output, look at the Command table for command numbers.
* FK_ConnectorType, This specifies what connector to show in the connection wizard, (HDMI, Composite, S-Video, whatever), this is purely aesthetic, and has no functional impact, and can be completely optional.

Once this is filled in, you'll see entries show up in the Output pull-downs for your device, and in the Connection Wizard.

Interestingly enough, we don't have anything in this table yet, but all the logic in the system does reference this table and use it, sooo...

-Thom

Basically, when an AV device is created in the system, you have Pipes associated with it,

Those pipes can be configured either manually (in the AV screen), or they can be configured via the Connection Wizard, specifying what inputs are used, what outputs are used, etc.

This way, once a piece of media has asked to be played via a scenario, it can then be routed to the correct destination.

-Thom

it's on my list to add SSDP discovery to the Plug and Play subsystem this year, so that devices like the Roku can be found easier.

As for the scenario, interesting, it automatically adds to mine..hmm..

-Thom

You can also look at the Developing a DCE device page in the wiki, as well as the Developers guide.

Essentially, DCE devices of this nature are interfaces, they translate DCE messages to the native messages for a given bus, and vice versa. We have device data so you can keep track of things like addresses of devices on a bus, and assign them to the dummy light bulbs etc, and the interface device will receive the commands for those children, and can grab the associated device data, and do the right thing.

There are plenty of examples of interfaces in our source code tree, under src/, CM11A, and ZWave are two such devices interfacing with said busses.

And, if you can get on IRC, we can help navigate you through the code and get you to where you can write a DCE device to control this bus.

-Thom

I have checked with our release manager, and he has informed me that the new Roku device has been built, and is in the repo.

In order to use it, you will need to update your sqlCVS.

from the web admin, go to advanced > sqlCVS > update

select all of the items in the DCE, and then press update.

Upon plugging in the Roku box, it should find it, and install the new driver. You can verify by looking for a Roku_LTXDXS_Pla driver in /usr/pluto/bin and process.

-Thom

I am aware of the bugs with the Roku GSD driver.

I have since rewritten the entire driver to use the new ECP control methods (instead of the telnet sockets). These are stateless HTTP calls, and do not tie up the control socket.

It also provides access to more buttons, keys, features, which will be expanded upon in future releases.

I have checked in the Roku device into the 1004 branch, not sure if posde built a package for it or not, will ask, but the code is there, and it does work beautifully.

As for the latency you experienced, this is, believe it or not, normal, through a tuner card. That's just the way it is when you bounce AV signals and digitize them, it takes time to do so. This is why AV control works best when you do direct control/input switching, wherever you can...Typically, I do direct control where the device normally is, and for bouncing around the house, I have a tuner device like the HD-PVR.

-Thom

Such devices are part of scenarios, and in the case of LinuxMCE, would be configured as the result of hooking pipes together.

I'm not sure if Dianemo still actively uses the pipe model, or if they've eschewed this for manual configuration.

-Thom

You're welcome. Hopefully this will allow Hulu to work a bit longer. Now that Hulu is not supported like this, alternatives will need to be used.

For the record, I am now using a Roku 2/3 box for such things, the new driver works exceptionally well.

-Thom

I have come up with a solution to allow Hulu Desktop to work for now, and have checked in the requisite code and data. I will ask our release manager, posde, to build a new package that can be updated.

With that said,

Hulu has dropped all support for Hulu Desktop. Period. End of Story. They think it's redundant. There will be no more versions, and when we can no longer run Hulu Desktop within LinuxMCE, the device template will be summarily disabled, and the software module option will be removed.

-Thom

You're not the only one who has been bitten by this. It's caused by Adobe breaking the flash plugin horribly with the last release of the plugin (presumably, the last version they will release for Linux).

The solution is to get an RPM with the 10.2 version of flash in it, unpack the flash plugin using rpm2cpio, and copy that plugin into the /usr/lib/mozilla/plugins folder, until we can come up with a solution that won't get trampled over with every damned update.

-Thom

Hello everyone,

After years of doing cell phone shaky cam videos, and getting constantly ribbed about them; coinciding with the purchase of a Nikon D5200 camera, I am now putting together a series of demonstration videos, titled "Why LinuxMCE?"

The aim of these videos is to show concepts present in the system, without going into a lot of detail.

The first one is here: http://www.youtube.com/watch?v=b-29IfFdsrY, I will be re-editing it in the next week, to deal with some of the cuts, but I decided to keep the preliminary one up for review.

-Thom

The Aeon skin was never finished. It was done to show that a skin could be hand ported from XBMC to QML, however, as merkur2k found out, there are far fewer screens in XBMC, than there are in LinuxMCE, so he ran out of stuff to use, _very_ quickly.

As for the default skin, you may want to talk to golgoj4 about this. Right now, dealing with DPI differences between devices is a bit of a challenge, and you'll probably need to change the qml for the skins to work properly. We need more people to help write skins and work through these interesting challenges.

-Thom