But it took the MD too long to power-on so I just leave it running. One other thing that can't work is the turning on of the pipes after power-on.

For example, atm, when the MD is powered off, and you say: Play TV, the MD will get powered on, but as the DCERouter is stateless, the Play TV never will reach its recipient. So what happens is: The MD will turn on. Full stop. Nothing more. That is not nice. And there is no easy way around this atm, due to the mentioned stateless-ness.

So, all in all, nice idea, but not doable with LinuxMCE without some MAJOR rewrite of the internals.

@posdeBig what if...What if the core would know if the md is off? i think it already knows. and when play a video, check if md is off, if so, send power on command. when the md is booted, the md sends a "Ready for commands" message. and the core send the command to play media

@LMCE godsI've looked through the orbiter.h and orbiter.cpp but i dont see how it works. any advise would be appreciated

The Orbiter class (as defined in Orbiter.cpp/.h), is a decendent of Command_Impl, and if you look, you'll actually see a list of commands that are implemented. This is where the bulk of a DCE device's logic is. Orbiter's complexity comes from its abstraction, so that it can be ported to other graphics toolkits and rendering/windowing systems.

If you want to see how to make a DCE device, look at Developing a DCE device, and try to do it...You'll see how a simple DCE device works, and eventually be able to pick apart how Orbiter works.

I've been looking through the orbiter code again, and i found where the screensaver and displayoff commands are started. now to find how the timer works, how it gets the data from the admin webpage, etc.

@posdeBig what if...What if the core would know if the md is off? i think it already knows. and when play a video, check if md is off, if so, send power on command. when the md is booted, the md sends a "Ready for commands" message. and the core send the command to play media

The dcerouter has NO intelligence. And it is good that way. The router only does one thing: It sends stuff around, it does not track state per se (even though the database does store such information). So, to have "Play TV" work like you would want to it to work, would mean a, imho, big rewrite of the router and/or another plugin, that would take care of the queue. Doable? Of course. I doubt, any of the existing devs would invest the needed amount of time into it atm. We have soooo many other things that do not work like they should, that everybody has their plate full. And the original architecture assumed always on MDs. If you keep it that way, or manually turn off/on the devices, you will have a much better experience. If you want to create a plugin that would be able to queue specific messages, feel free to dive into router, plugin development, and read all the dev pages we have in the wiki. If you have specific questions, feel free to come by the #linuxmce-devel channel @ freenode.net