Author Topic: MD Power On/Off Behavior  (Read 537 times)

davegravy

  • Addicted
  • *
  • Posts: 517
    • View Profile
MD Power On/Off Behavior
« on: October 17, 2011, 05:08:47 am »
Hydro is no longer included in my rent and so I am becoming obsessed with saving electricity (aka money).

A few questions:

1) If my MD is idle for a time (as specified in webadmin/orbiters) my AV peripherals (plasma TV, receiver, etc) get turned off. Is it possible to have my MD suspend in addition to turning off these peripherals? I poked around a bit in "respond-to-events" but couldn't find an event for an idle-timeout type thing.

2) When I power off my MD via the power menu, is it possible to first have it turn off my peripherals? Is there an editable scenario for this, or is it auto-generated? Likewise, when my MD powers up via the power menu, can I have it turn on my peripherals once the associated devices are started?

3) When my MD is powered down and I select an action via the orbiter such as play media, or any other action which requires the MD to be ON, can I have the MD turn on and then execute that action?

4) My MD takes 1:15 to resume from suspend-from-RAM. 80% of the resume seems to be starting the various LMCE devices. What might I do to speed this up?  What is the likely bottle-neck for this process?

Gigabit network, both the MD and CORE are 5600+ Athlon X2s with 2G RAM. Core runs on 7200RPM drives. Would an SSD in the core help much?

As you can see here, I'd like to reduce the number of button pushes that SWMBO needs to do to access various media/functions and save as much power as possible :)

Thanks in advance,

Dave

posde

  • Administrator
  • LinuxMCE God
  • *****
  • Posts: 2984
  • Wastes Life On LinuxMCE Since 2007
    • View Profile
    • My Home
Re: MD Power On/Off Behavior
« Reply #1 on: October 17, 2011, 08:24:03 am »
1) If my MD is idle for a time (as specified in webadmin/orbiters) my AV peripherals (plasma TV, receiver, etc) get turned off. Is it possible to have my MD suspend in addition to turning off these peripherals? I poked around a bit in "respond-to-events" but couldn't find an event for an idle-timeout type thing.

not atm

Quote
2) When I power off my MD via the power menu, is it possible to first have it turn off my peripherals?

not atm

Quote
Likewise, when my MD powers up via the power menu, can I have it turn on my peripherals once the associated devices are started?

no.

Quote
3) When my MD is powered down and I select an action via the orbiter such as play media, or any other action which requires the MD to be ON, can I have the MD turn on and then execute that action?

not atm

Quote
4) My MD takes 1:15 to resume from suspend-from-RAM. 80% of the resume seems to be starting the various LMCE devices. What might I do to speed this up?  What is the likely bottle-neck for this process?

Remove devices you do not need.

Quote
As you can see here, I'd like to reduce the number of button pushes that SWMBO needs to do to access various media/functions and save as much power as possible :)

Understood. Especially point 2 and 3 are bothering me as well. To fix 4 I had setup a timed event to start the MD at 8pm. But nowadays, I just keep it running, as it also powers our door bell. I know, expensive door bell.

davegravy

  • Addicted
  • *
  • Posts: 517
    • View Profile
Re: MD Power On/Off Behavior
« Reply #2 on: October 17, 2011, 03:17:00 pm »
Ok, thanks for letting me know :) Good to know I'm not the only one desiring this sort of behavior and that it may be possible in the future.

Out of curiosity, would you say implementing this kind of behavior is a massive undertaking requiring significant changes to the underlying system structure? Or is it something a beginner/intermediate dev could reasonably tackle?

Regards,

Dave

posde

  • Administrator
  • LinuxMCE God
  • *****
  • Posts: 2984
  • Wastes Life On LinuxMCE Since 2007
    • View Profile
    • My Home
Re: MD Power On/Off Behavior
« Reply #3 on: October 17, 2011, 04:57:13 pm »
If it would be easy, it would have been done already. One problem lies in the pipe handling, which is one of the more interesting parts of LinuxMCE