MythTV ACPI Shutdown/Wakeup

Status of this Document: This wiki page is somewhat out of date. It refers to "/proc/acpi/alarm" which only applies to kernel versions 2.6.21 and earlier (Feisty Fawn, 7.04, and earlier). Kernel versions 2.6.22 and later (Gutsy Gibbon, 7.10, and later) use "/sys/class/rtc/rtc0/wakealarm" instead. If your kernel version (type "uname -a" in a terminal window) is 2.6.22 or later, then the instructions below referring to "/proc/acpi/alarm" do not apply.

For kernel versions 2.6.22 and later, you may go to mythtv.org/wiki/ACPI_Wakeup and follow the "/sys/class/rtc/rtc0/wakealarm" instructions.

Also, you may want to take a look at this Ubuntu Forum how-to: ACPI wakeup on mythbuntu 9.04.

DISCLAIMER: Due to the idiosyncrasies of motherboards and their BIOSes, finding an automatic wake-up/shutdown solution is not a one-size fits all process. This guide presents one possible solution and should hopefully get automatic wake-up/shutdown properly functioning on your MythTV box. Some boards are notoriously difficult to get waking, so you might want to google your motherboard and see what information you can find before trying this.

As long as you are careful to backup any file before changing or replacing it and note original BIOS and set-up settings before changing them, undo-ing what you do here will be painless- and poses no danger to your board or OS. The worst case scenario is it just won't wake up by itself and you have to restore some backed up files and settings.

This guide approaches auto wakeup/shutdown using ACPI wakeup via the BIOS RTC (real time clock) alarm. This solution will work for many boards, but not all. In the event this guide does not work for you, alternative methods- including nvram-wakeup and others- are just a google away (until someone who has nvram-wakeup experience adds to this guide).

ACPI RTC Wake Ability

The wake-up function is provided on most modern boards by the ability to "wake from RTC alarm"- setting a date and time in BIOS will cause the computer to power itself on and boot at the set time. Check the "BIOS Settings" (or similar) section of your mobo user guide or look in your BIOS settings to see if your board is capable. This setting is likely found under a sub-menu of "Power Management" "APM", or "Advanced"- you just need to poke around to find it. It will likely be called something like Wake from RTC, Wake From Alarm, RTC Resume, etc.

BIOS setup is usually entered by pressing DEL or F1 at boot. Again, consult you manual if you do not know how.

NOTE: On many boards, when this setting is enabled, it will wake only from a time set and saved from BIOS setup, and not from a time set outside of the BIOS setup environment- as we want. All of the boards the original author of this document needed this setting disabled to correctly wake with ACPI. This is the recommended starting point, but is not mandatory. If you are unable to wake your board at step 1.4, try again after setting this to the opposite in BIOS.

While you are investigating your BIOS settings, you should also look for settings involving "ACPI Aware OS" and "ACPI 2.0" functions. You may or may not need these enabled. In my experience, ACPI Aware OS needs to be enabled and ACPI 2.0 didn't seem to make a difference.

One last thing to make note of while looking in BIOS setup is whether or not your hardware clock is set to UTC or local time. The clock should be on the main setup page. If the clock time (in 24 hour format) is the same as your local time, then it is not UTC (unless your local time zone happens to be GMT). If Ubuntu is the only OS on your system, chances are the time is stored in UTC. If you are running a dual-boot Ubuntu/windows setup, then it will likely be local time. You will need to know if it is UTC or not for step 2.1.

Remember to make note of which settings you make changes to and what their original setting was; and don't forget to save the changes before you exit BIOS setup.

OS Function

Make sure you have ACPI functions enabled and exposed to the OS. If you have a modern board and power supply, the chances are you do: 

  • $ dmesg|grep -i acpi

should give you long-ish list such as: 

  • [17179569.184000]  BIOS-e820: 000000003bfc0000 - 000000003bfce000 (ACPI data)
[17179569.184000]  BIOS-e820: 000000003bfce000 - 000000003bff0000 (ACPI NVS)
[17179569.184000] ACPI: RSDP (v000 ACPIAM                                ) @ 0x000f9240
[17179569.184000] ACPI: RSDT (v001 A M I  OEMRSDT  0x02000614 MSFT 0x00000097) @ 0x3bfc0000
[17179569.184000] ACPI: FADT (v002 A M I  OEMFACP  0x02000614 MSFT 0x00000097) @ 0x3bfc0200
[17179569.184000] ACPI: MADT (v001 A M I  OEMAPIC  0x02000614 MSFT 0x00000097) @ 0x3bfc0390
[17179569.184000] ACPI: MCFG (v001 A M I  OEMMCFG  0x02000614 MSFT 0x00000097) @ 0x3bfc03f0
[17179569.184000] ACPI: OEMB (v001 A M I  AMI_OEM  0x02000614 MSFT 0x00000097) @ 0x3bfce040
[17179569.184000] ACPI: DSDT (v001  761GX 761GX964 0x00000000 INTL 0x02002026) @ 0x00000000
[17179569.184000] ACPI: PM-Timer IO Port: 0x808
[17179569.184000] ACPI: Local APIC address 0xfee00000...

etc...

Next, check for the most important part we need- access to the RTC alarm itself.

If: 

  • $ find /proc/acpi/alarm

returns: 

  • /proc/acpi/alarm

then you are good to continue. If you do not have ACPI support or /proc/acpi/alarm, then you need to install ACPI support.

hwclock.sh

Of all the changes we will make to use ACPI wake-up, this is the heart of it all. hwclock.sh is a script found in /etc/init.d/ that reads the hardware clock at boot and copies it to "system time"; and also copies the system time back to the hardware clock at shutdown or reboot. By doing this, the hardware clock should remain accurate, as system time has likely been synchronized with an ntp server.

However, this causes problems for a lot of boards, which will "forget" the RTC alarm time if the hardware clock is written to after having set the RTC alarm. To get around this, you make two small modifications to the hwclock.sh script to ensure the RTC alarm is written after the final write to the hardware clock. Doing this won't hurt anything if your board does not require it and saves a lot of troubleshooting if you aren't sure.

First, back up your existing hwclock.sh- in case you need to restore it.

(From this point forward, all terminal commands assume you are in your user's home directory and that the user has sudo privileges. Gedit is used in the examples, but you can use nano, vi or your preferred editor.) 

  • $ sudo cp /etc/init.d/hwclock.sh hwclock.sh.bak

Now, make two small additions to the existing hwclock.sh: 

  • $ gksudo gedit /etc/init.d/hwclock.sh

At the head of the file, add the following line: 

  • ACPITIME=`cat /proc/acpi/alarm`

Make sure to use grave accents instead of single quotes in the above code. The result will look like this: 

  • ... comments ...
HWCLOCKPARS=
ACPITIME=`cat /proc/acpi/alarm`
hwclocksh()
{

    [ ! -x /sbin/hwclock ] && return 0

etc...

Next, scroll down to the tail of the file and look for: 

  •             #
            # Updates the Hardware Clock with the System Clock time.
            # This will *override* any changes made to the Hardware Clock.
            #
            # WARNING: If you disable this, any changes to the system
            #          clock will not be carried across reboots.
            #
            if [ "$HWCLOCKACCESS" != no ]; then
                log_action_msg "Saving the system clock"
                if [ "$GMT" = "-u" ]; then
                    GMT="--utc"
                fi
                if /sbin/hwclock --systohc $GMT $HWCLOCKPARS $BADYEAR; then
                    verbose_log_action_msg "Hardware Clock updated to `date`"
                fi
            else
                verbose_log_action_msg "Not saving System Clock"
            fi
            ;;

You want to add this line: 

  • echo "$ACPITIME" > /proc/acpi/alarm && sleep 1 && echo "$ACPITIME" > /proc/acpi/alarm

so that section of code now looks like this: 

  •             #
            # Updates the Hardware Clock with the System Clock time.
            # This will *override* any changes made to the Hardware Clock.
            #
            # WARNING: If you disable this, any changes to the system
            #          clock will not be carried across reboots.
            #
            if [ "$HWCLOCKACCESS" != no ]; then
                log_action_msg "Saving the system clock"
                if [ "$GMT" = "-u" ]; then
                    GMT="--utc"
                fi
                if /sbin/hwclock --systohc $GMT $HWCLOCKPARS $BADYEAR; then
                    verbose_log_action_msg "Hardware Clock updated to `date`"
                fi

                echo "$ACPITIME" > /proc/acpi/alarm && sleep 1 && echo "$ACPITIME" > /proc/acpi/alarm
            else
                verbose_log_action_msg "Not saving System Clock"
            fi
            ;;

Save the result.

This added command writes the wake time after the final clock change (the command directly above it).

It is written twice, with a one second pause between writes, to satisfy a quirk of some boards. Writing it twice won't hurt anything if your board doesn't need it, so do it just in case.

Clock Format

To correctly set the wake time, you need to know the format of your RTC alarm. 

  • $ cat /proc/acpi/alarm

will return the RTC format. you should see something like: 

  • 2007-**-28 14:10:21

In this example, the format is yyyy-MM-dd hh:mm:ss- the ** may be the correct month, 00 or be blank on your system- having no settable month seems to be common.

First Test

Before you dig too much deeper into setting this up, it's a good idea to determine whether or not your board is going to comply. At this point, everything should be ready to test a wake-up. To do this, you will set the system to wake five minutes from now. If your computer is slower, you can increase the time; if faster, you can decrease it. Just make sure you allow for enough time for the system to shut down completely, with a minute or two to spare before it needs to wake.

The following command uses our example time format of yyyy-MM-dd hh:mm:ss and adds 5 minutes to the ACPI alarm. If your time format is different, you will need to adjust the ordering of +00-00-00 00:05:00 to comply. 

  • $ sudo sh -c 'echo "+00-00-00 00:05:00" > /proc/acpi/alarm'

It is a good idea to check if the command did the job right.

  • If the year part looks like "0007" instead of "2007", change +00 with +2000; this worked for Acer Ferrari 3400, TravelMate 800, Asus M2NPV-VM and ABit VA-10. 

    $ cat /proc/acpi/alarm

Now you can shut down the system to see if it wakes up. Bookmark this page if you haven't already. I'll see you when you get back.

Shut it down: 

  • $ sudo shutdown -h -P now

Sit back, relax and wait for your box to wake up...

Welcome Back!

Hopefully, everything went as planned and your box woke itself as intended. If not, double-check each step above to be sure it was all correctly done. If everything is correct, your board might need to reboot and complete a POST cycle before correctly waking, as some do. Skip ahead now to 3.0 Poweroff Kernel and try that remedy.

If you tried the poweroff kernel but still failed to wake, see 4.0 Troubleshooting.

If it did wake, CONGRATULATIONS! It's all downhill from here...

Scripts and Settings

You will likely need at least one of these scripts for the wake-up/shutdown process:

  • a script to adjust and set the wake-up time (if your mobo clock is UTC)
  • a Pre-shutdown script (possibly)
  • a Server Halt script (if you use poweroff kernel)

Examples of a wake script MythWakeSet, pre-shutdown script MythShutdownCheck and server halt script for poweroff kernel MythShutDown are provided here. If you need to do something special on your system before shutdown, such as special service shutdown scripts, etc., then you are responsible for integrating them into the provided script.

MythWakeSet

If your hardware clock is set to UTC, you need MythWakeSet to adjust between the wake time MythTV will report (local time) with the time the RTC alarm requires (UTC).

To create the wake script, open the editor of your choice and copy and paste the following. Save it as MythWakeSet: 

  • #
# MythWakeSet
#
# set mythtv wake-up time with UTC-adjusted time
#

# temp file for working with time
temp_stamp=/home/mythtv/timestamp

# store the wake time passed from mythbackend
echo $1\ $2 > $temp_stamp

# Read the date in *locale* time format and tag the time-zone info to the wake time
localeadd=$(/bin/date -f $temp_stamp +%F\ %T\ %z)
echo $localeadd > $temp_stamp

# adjust this to UTC and store the final wake time
utcadj=$(/bin/date -u -f $temp_stamp +%F\ %T)

# set the alarm
echo $utcadj > /proc/acpi/alarm

Now, make the script executable and put a copy of it in /usr/bin: 

  • $ chmod +x MythWakeSet
$ sudo cp MythWakeSet /usr/bin

Yet another script, that works with old acpi and new rtc alarm: 

  •  #!/bin/sh

# inspired from http://www.mythtv.org/wiki/index.php/ACPI_Wakeup
# and https://help.ubuntu.com/community/MythTV/Install/WhatNext/ACPIWake
#
# MythWakeSet
#
# set mythtv wake-up time with UTC-adjusted time
#
# use: MythWakeSet date time
# ex.: MythWakeSet 2008-11-02 20:15:00
# See also 'man date' for date/time-formats.

# TimeZone, use +0100 for GMT+1
#TZ="+0100"
TZ=$(date +%z)

LOG=/var/log/mythtv/mythbackend.log

DATE=$(date -d "$1 $2 $TZ" "+%F %H:%M:%S" -u)
SECS=$(date -d "$1 $2" "+%s")

echo Running $0 to set the wakeup time to $1 $2 >>$LOG

if [ -e /sys/class/rtc/rtc0/wakealarm ]; then
  echo 0 > /sys/class/rtc/rtc0/wakealarm
  echo $SECS > /sys/class/rtc/rtc0/wakealarm
  echo "echo 0 > /sys/class/rtc/rtc0/wakealarm" >>$LOG
  echo "echo $SECS > /sys/class/rtc/rtc0/wakealarm" >>$LOG
  cat /proc/driver/rtc  >>$LOG
else
  if [ -e /proc/acpi/alarm ]; then
    echo $DATE > /proc/acpi/alarm
    echo "echo $DATE > /proc/acpi/alarm" >>$LOG
  else
    echo "ERROR, Wakeup not set, no /sys/class/rtc/rtc0/wakealarm and no /proc/acpi/alarm found" >>$LOG
  fi
fi

MythShutdownCheck

If you use your backend server for other things in addition to MythTV, such as ssh or ftp transfers etc., you want to make sure that MythTV doesn't shut down the system while you are in the middle of something. This is especially true if you have the backend set to a stingy idle timeout like 5 minutes.

One very effective way to do this is to check and see if another user is logged in, since you likely won't be transacting much non-mythtv business as the mythtv user. If you are not watching tv or a recording, but want the backend box to remain alive, all you need to do is log into an ssh session and leave it open.

You can do other checks in addition to- or instead of- checking for logged-in users: such as checking for specific running processes, etc. Add these checks to this script if needed, but first be sure to check that your changes work properly! Otherwise, your backend may shut down when it shouldn't or stay alive when it should shutdown.

If you want to make sure no other users are logged in before shutdown, copy and paste the following into an editor and save it as MythShutdownCheck; if not, skip ahead to 2.3. 

  • #
# MythShutdownCheck
#
# checks to see if any other user is
# logged in before idle shutdown
#
# returns "1" if yes, stopping shutdown
# returns "0" if ok to shutdown
#


# to not shutdown during mythcommflag process, uncomment the following line
# ps ax | grep -v grep | grep -q mythcommflag && exit 1


if last | head | grep -q "pts/.*still logged in"   # check for active *remote* login?

then
   exit 1

else
   exit 0
fi

Make the script executable and put a copy of it in /usr/bin: 

  • $ chmod +x MythShutdownCheck
$ sudo cp MythShutdownCheck /usr/bin

mythtv-setup

At this stage, you have the needed scripts and the box woke successfully on test. Now it's time to setup Mythtv to test MythWakeSet.

Stop the server for needed changes and then run mythtv-setup: 

  • $ sudo /etc/init.d/mythtv-backend stop
$ mythtv-setup

The settings you need are under 1. General, on page 5 (Shutdown/Wakeup Options). The settings you need are:

Block shutdown before client connected: you want this box unchecked, or the automatic shutdown routine will be blocked until a frontend client has connected.

Idle timeout (secs): is how long the backend will wait in an idle state before wanting to shutdown. Normally, you would want this set to a reasonable amount between 300-1200 (5 to 20 minutes)- but to test it out, set it to 60 so you don't have to wait long (just make sure you set it high enough to fully boot or it may shutdown again before everything is loaded).

Max wait for recording (min): determines whether or not the backend will shutdown if it is idle and there is a pending recording. e.g. if this is set to 20 minutes, the backend is idle and wants to shut down and the next recording is scheduled three hours in the future, the backend will shutdown and wake itsef up later. If the same conditions are true, but the recording is scheduled to start in 20 or fewer minutes, then it will wait, record it and then check this setting again after reaching an idle state . For now, set this to 1 to make sure it shuts down for our tests.

Startup before rec. (secs): is how much time the backend will allow for itself to fully boot and come up to speed, before being expected to record. Note that this time will be added as an offset to the wake time. You should likely allow at least 200 seconds or more to be sure you do not miss beginning of your recording. Set this to a reasonable estimate of your boot time for now, but time your boot from powerup for your final setting.

Wakeup time format: is the format your board expects for the RTC alarm (you checked this earlier). In this example, it is yyyy-MM-dd hh:mm:ss adjust yours as necesary.

Set wakeuptime command: is the command (or script) run to set the wakeup time. If you are using the UTC script above, enter: sudo /usr/bin/MythWakeSet $time This will call your script and pass it the waketime via the $time variable.

Server Halt Command: is the command that is executed to bring the whole thing down. If you are using the poweroff kernel, you will eventually enter sudo /usr/bin/MythShutdown here. For this test, enter: sudo /etc/init.d/mythtv-backend stop, which will only stop the backend.

Pre Shutdown check-command: is the shutdown checker - enter sudo /usr/bin/MythShutdownCheck to use it or enter exit 0 if not.

sudo

The last thing to do before testing is to take care of permission issues. As you probably noticed, the above commands run as "sudo", which would cause problems if it prompted for a password and nobody was there to enter it-- nothing would ever happen.

There are a number of ways to handle this- the method presented here gives the mythtv user sudo privileges, without prompting for a password, for limited commands and resources. There are other alternatives you can explore; each with their own advantages and pitfalls.

To give mythtv user the permissions we need: 

  • $ sudo visudo

Add the following line to the end, making sure it is the only entry for mythtv- if another entry for mythtv exists, replace it with this one: 

  • %mythtv ALL = NOPASSWD: /sbin/shutdown, /usr/bin/MythWakeSet, /proc/acpi/alarm, /usr/bin/MythShutdownCheck, /etc/init.d/mythtv-backend, /usr/bin/mythshutdown

NOTE: If you are using the poweroff kernel, use: 

  • %mythtv ALL = NOPASSWD: /sbin/shutdown, /usr/bin/MythWakeSet, /proc/acpi/alarm, /usr/bin/MythShutdownCheck, /etc/init.d/mythtv-backend, /usr/bin/mythshutdown, /sbin/reboot, /sbin/grub-set-default

Another Test

Before proceeding, go into the frontend and schedule a recording an hour or so from now and note the time it starts.

Now we can test to see if the scripts and their interfaces with MythTV are set up correctly. First, set /proc/acpi alarm to a known value (again, if your date/time format is not yyyy-MM-dd hh:mm:ss, adjust as needed): 

  • $ sudo sh -c 'echo "2007-12-12 12:12:12" > /proc/acpi/alarm'

Then, check to see it was set. You should see something simlar to: 

  • $ cat /proc/acpi/alarm
2007-**-12 12:12:12

Now, fire up the backend to test the write to /proc/acpi/alarm. In this case, we won't lauch it as a daemon so we can see what is being logged: 

  • $ sudo mythbackend &

It should immediately start warning you of impending shutdown, count it down and then stop. Hit Enter to get a command prompt and then check to see if MythWakeSet worked: 

  • $ cat /proc/acpi/alarm
2007-**-01 20:59:00

As the example shows, the time returned should now reflect the waketime and not all 12's, as we set before the test. Of course, yours will probably not match the example...

If your hardware clock is in UTC, to see if the waketime is set correctly:

Take the start time of the recording you set a little while ago (24 hour format), add or subract (as appropriate) for your time zone offset, and subtract the amount of time you set for Start before recording in step 2.3.

For example:

  • Recording was for 4pm (16:00:00)
  • Local time is GMT-5 +(05:00:00)
  • Start before rec was -(00:01:00)
  • Time with offset is 20:59:00

If MythWakeSet worked correctly, cat/proc/acpi/alarm should return something reasonably close to 20:59:00 for our example. If, after checking your math, yours still varies substantially or is unchanged from 12's, go back and review each step to check for errors. If you have the recording options in MythTV to wake a minute or two (or more) before the scheduled recording, this will also cause a small discrepancy.

The FINAL Test

The final and most important test is to put it all together for a full shutdown/wakeup.

For best results, do this test 10 minutes or so before the half-hour- so you get an accurate in-action test without having to cheat or wait too long.

Make sure the backend is shut down and go back into setup: 

  • $ sudo killall mythbackend
$ mythtv-setup

Return to the Shutdown/Wakeup page and make the following changes:

Idle timeout (secs): 120
Server Halt Command: sudo shutdown -h -P now

  • if you are using the poweroff kernel this will be: sudo /usr/bin/MythShutdown (see 3.1 MythShutdown)

And then start the backend: 

  • $ sudo /etc/init.d/mythtv-backend start

In the frontend, find a show- on any tunable channel- that begins at the next half-hour and set it to record. Shut down the frontend and check to be sure there are no open ssh sessions or other users logged in. If this is a combined frontend/backend, log out of your current session.

Within two or so minutes, the backend should shut itself down.

Now is a good time to get a sandwich or a cold drink (or both!) and wait for it to turn itself on and boot up!

Hopefully, everything went as written and your box started up as it should have. If not, but you could successfully wake in step 1.4, check every step from 2.0 forward- it should be working properly. There's likely a small mistake somewhere.

When it wakes and records it should , all that is left for you to do is shutdown mythtv-backend, go back into mythtv-setup and make your final settings for Idle timeout, etc.

ENJOY!

MythWelcome

If you run frontend and backend on the same machine, you can use MythWelcome to decide if the machine has been woken up by user and the start of the frontend is needed or not. With MythWelcome the Frontend is automatically started if you started the machine manually, but if its started automatically via acpi-wakeup the frontend won't start and lock the backend from shutting down when recording is finished. Unfortunately MythWelcome was originally build for use with nvram-wakeup, but you can also use it with acpi-wakeup.

First you have to manipulate /usr/share/mythtv/startmythtv.sh to specify that mythwelcome is loaded in startup instead of loading the frontend directly. You can do this by starting an editor with 

  • $ sudo nano /usr/share/mythtv/startmythtv.sh

Info <!> If you cannot find /usr/share/mythtv/startmythtv.sh then skip this part and continue with section below "I don't have startmythtv.sh".

Look for the last lines 

  • #start mythtv frontend software
exec mythfrontend

and change it to 

  • #start mythtv frontend software
#exec mythfrontend
sleep 5
exec mythwelcome

I need the sleep options because mythwelcome is faster than the backend, without this i get an error that the backend is not running.

I don't have startmythtv.sh

If startmythtv.sh is missing from your installation (e.g. in Mythbuntu 8.04/8.10)

Mythbuntu 8.04

then you should instead edit ~/.config/autostart/mythtv.desktop like this: 

$ sudo nano ~/.config/autostart/mythtv.desktop

Look for the line reading 

  • Exec=mythfrontend

and change it to 

  • Exec=mythwelcome

Mythbuntu 8.10

edit '/etc/mythtv/session-settings' like this: 

$ sudo nano /etc/mythtv/session-settings

Uncomment the line reading 

  • #MYTHWELCOME=true

it should look like this 

  • MYTHWELCOME=true

Test if MythWelcome starts up Ok

Now it is time to restart your computer and see if mytheelcome is being started.

Restart.

Depending on whether you have scheduled a recording in the near future or not, you will see one of two things:

  • The regular mythfrontend. This will appear if you have no recording scheduled that begins soon.
  • The screen of mythwelcome. This will appear if the backend is soon going to record a show.

In case you see the mythwelcome-screen you may continue with the rest of the configuration. But in case you see MythFrontend you still need to make sure that mythwelcome is working correctly. To do so, exit mythfrontend. This should immediately return you to mythwelcome.

If you see a the blank desktop then you need to re-check the previous step.

Modify MythWakeSet (only required for older versions of MythWelcome)

You can skip this step if you run mythtv >= 0.21 (Mythbuntu 8.04).

If you are using an older version of MythWelcome, you need to make some adjustements, since those older versions only use a Unix timestamp to set the wakup time you need to modify the /usr/bin/MythWakeSet script. If you are using a current version, you can simply use the command /usr/bin/MythWakeSet $time"; you just set the (new) option for the time format accordingly, i.e. to yyyy-MM-dd hh:mm:ss or whatever your mainboard requires. If you have this option, simply skip this part.

If you are running an older version, open the script MythWakeSet via 

  • sudo nano /usr/bin/MythWakeSet

and replace 

  • # store the wake time passed from mythbackend
echo $1\ $2 > $temp_stamp

with 

  • # store the wake time passed from mythbackend
##echo $1\ $2 > $temp_stamp
tmp=`echo $2 | awk -F: '{print strftime("%Y-%m-%dT%T", $1)}'`
tmp1=`echo $tmp | awk 'BEGIN { FS = "T" } { print $1 }'`
tmp2=`echo $tmp | awk 'BEGIN { FS = "T" } { print $2 }'`
echo $tmp1\ $tmp2 > $temp_stamp

Restart.

Configure MythWelcome

Exit the frontend, you will automaticaly get the mythwelcome screen. Press F11 to enter the setup and enter the following values:

  • nvram-wakeup Command: sudo -H /usr/bin/MythWakeSet "$time"
    nvram-wakeup Restart Command: leave blank!
    Command to reboot: sudo -H shutdown -h -r now
    Command to shutdown: sudo -H shutdown -h -P now

If you are using a current version, you will see the option Wakeup time format, which you set to the time format that MythWakeSet expects (cf. above).

Leave the rest unchanged.

A side note: MythWelcome has two setup menues. One is accessed by F11, the other by pressing "i". There is also a command menu that you can access via "m". "Enter" will start mythfrontend. You do not need this here but it is good to know.

Configure MythBackend

Navigate to Shutdown/Wakeup Options and change the following values:

  • Wakeup time format:: yyyy-MM-dd hh:mm:ss
    Set wakeuptime Command: sudo -H mythshutdown --setwakeup "$time"
    Server halt Command: sudo -H mythshutdown --shutdown
    Pre Shutdown check-command: mythshutdown --check

NOTE: The command mythshutdown --setwakeup $time does not write to the /proc/acpi/alarm. It just sets the wakeup time in mythwelcome. The command mythshutdown --shutdown actually writes the time set by the call of mythshutdown --setwakeup to the RTC in the motherboard and should be used for the Server halt Command option. If this was sudo shutdown -h -P now, MythBackend will shutdown the machine properly, but it wont wake up to record for the next scheduled recording as the wakeup time is never set to the RTC of the motherboard.

Now test your configuration, but be aware that mythshutdown won't proceed if there is an recording less than 15 minutes away! These 15 minutes cannot be configured. Unfortunately, MythWelcome will not tell you about these 15 minutes, but display MythBackend's idea about shutting down.

(Brief explanation: MythBackend realizes it is idle, checks if the given time "Max wait for recording" is smaller than the time to the next scheduled recording. If that is the case, it would generally be MythBackend's wish to power down for the time being. In order to do that, it waits for the specified amount of time, the "Idle Timeout"; if nothign happens in this time, MythBackend will power down and wake up again at the time for the recording minus the powerup time and minus the generally configured pre-recording time.

MythWelcome will report what MythBackend thinks. If you set up MythBackend to even power down for just five minutes (let the next recording be 10 minutes away), with an idle time of e.g. 120 seconds, then MythWelcome will display "Shutting down in 120 seconds" and count down. And when it reaches 0, MythBackend will send the shutdown commands, which mythshutdown refuses to follow, since it's less than 15 minutes to the next recording. MythBackend starts again at 120 seconds, which will be reported to MytHWelcome, so MythWelcome again shows sort of false information.)

The "Lock" feature

MythTV has an internal "lock" feature: when the lock is set, MythBackend will not shut down the system at all, no matter how idle it is. There are basically two ways to set and remove a lock:

  1. you can use mythshutdown --lock and mythshutdown --unlock, respectively, e.g. by running them in a shell.

  2. MythWelcome actually allows, when you have the menu popup by pressing M, to set and remove the lock.

This is pretty useful if you want to do some desktop work and keep MythBackend running in the background wihtout having to fear being logged off in the middle of work.

Show and change status on the Desktop

Since using mythshutdown allows to set and unset the lock status (and since mythshutdown actually provides for a way of checking the lock status), it is possible to set up tools that report the lock status.

Using a panel item in an xfce desktop

If you use Mythbuntu in the standard variety if you use Xubuntu or if in general you have decided to use xfce as your desktop, there is a simple way to show and change the lock status on the "task bar" that xfce provides using the genmon (short for "Generic Monitor") plugin.

In order to do this, you first need to install the genmon xfce panel plugin: 

  • sudo apt-get install xfce4-genmon-plugin

Next we need a script to check MythBackend's status for us and provide us with

  1. icons
  2. nice tooltips
  3. the possiblity to click to lock and unlock

Paste the following Perl script into an editor and save it (you need Perl installed for this to work, and Perl scripts need to be allowed to run the system command): 

  • $result      = system('mythshutdown', '--status', '1');
$myth_locked = (($result >> 12) & 0x01);
$imgpath     = '~/images/lock_';
if($myth_locked == 1){
  print '<img>'.$imgpath."closed.png</img>\n"
       ."<tool>MythTV can currently not shut the computer down</tool>\n"
       .'<click>mythshutdown --unlock</click>';
} else {
  print '<img>'.$imgpath."open.png</img>\n"
       ."<tool>MythTV can currently shut the computer down</tool>\n"
       .'<click>mythshutdown --lock</click>';
}

(If your path to the Perl executeable is not /usr/bin/perl, adjust the path after the shebang.)

Save this to an arbitrary place, e.g. ~/scripts/MythCheckStatus.

Now you need to provide the necessary icons. The script assumes that they are located in ~/images/ and that their names are lock_open.png and lock_closed.png, respectively. You can choose what you want here.

Once this is done, you can right-click the xfce panel (task bar) and add a new item for the type of which you choose "Generic Monitor"; then press "Add".

As Command you enter ~/scripts/MythCheckStatus, as Label you enter nothing and uncheck the checkbox next to it, and finally you set the Period to an amount of seconds that serves your needs. Maybe 5 s, maybe 30 s, whatever floats your boat.

And now you are done. The image will show whether or not the lock status is set; in order to change the status, just click it. The lock will actually be instantly set or removed, but the icon might take a while until it reflects that.

Poweroff Kernel

Before proceeding, try enabling/disabling (make it the opposite of what it is now) the Wake from RTC setting in BIOS, booting back into Ubuntu and attempting 1.4 First Test again. If it still fails after having tried adjusting BIOS settings, return any changed BIOS settings to their original state and try the following poweroff kernel remedy.

If you are not careful, these changes can hose your grub and booting could be an adventure. If have not edited your grub menu before or are not sure what you are doing, you should ask someone for assistance or google for grub editing information. PLEASE BACK UP YOUR menu.lst BEFORE MAKING THESE CHANGES!!!

So just back it up, cowboy... 

  • $ sudo cp /boot/grub/menu.lst  menu.lst.bak

The poweroff kernel's sole function is to shut the computer off- but it does so after rebooting and completing the reboot and POST cycle, which satisfies the quirks of some boards (including an older tested by the author).

To test if your motherboard might need a poweroff kernel, set a wake up time a few minutes in the future, restart the PC in the normal manner, but turn the PC off (by pressing the power button briefly, not by holding it down for a few seconds) after the POST but before Linux boots up. If the PC wakes up using this method, then the poweroff kernel should work for you. If it doesn't, this is not necessarily indicative of failure- at least one tested board failed this procedure but worked very well with the poweroff kernel.

First, install the poweroff kernel- download, unpack it and copy it to /boot: 

  • $ wget http://prdownloads.sourceforge.net/nvram-wakeup/reboot-2004.10.03.tar.bz2?download
$ tar -xvjf reboot-2004.10.03.tar.bz2
$ sudo cp reboot-2004.10.03/bzImage.2.4.20.poweroff /boot

Next, edit the grub menu: 

  • $ gksudo gedit /boot/grub/menu.lst

find the line at the head that reads: 

  • default  X

make note of the default number that is there (X) and then change it to: 

  • default saved

This will cause grub to boot the last menu entry that was set (using grub-set-default, surprisingly). In this case, you will set the default value to the poweroff kernel. On reboot, grub will load, boot the poweroff kernel and shutdown.

Setting the default back to the "usual" kernel in the poweroff kernel menu entry ensures that when it wakes, it will boot into Ubuntu and MythTV as normal. The "usual" kernel is the X you just wrote down.

Append this entry to the end of your menu list: 

  • title           POWER OFF
savedefault     X       ### replace X with your default value from the step above ###
root            (hd0,0)         ##### this entry should match the ''root'' statement of your default kernel ####
kernel          /boot/bzImage.2.4.20.poweroff root=/dev/null

Next, counting from 0, determine the menu entry for this poweroff kernel.

e.g. if you show one kernel, one recovery mode, one memtest and this kernel, the menu entry would be 3... if you have only a main kernel and this poweroff kernel, then it is 1, etc. Remember not to count any menu items that are commented out (with #).

Double-check the menu list to be sure you counted correctly!

Now you can test it out. Substitute value of poweroff kernel you determined above for P in the following and reboot: 

  • $ sudo grub-set-default P
$ sudo reboot

Your computer should reboot, go through POST, load grub and then shut off.

When this works, you are ready to try a wake again- 

  • $ sudo sh -c 'echo "+00-00-00 00:05:00" > /proc/acpi/alarm'
$ sudo grub-set-default P   ## again, substitute "P" with poweroff value
$ sudo reboot

See you back at Step 1.5...

MythShutdown

If you are using the poweroff kernel, you will need this script to set the default grub selection and reboot. Copy and paste the following into an editor and save it as MythShutdown 

  • #
# MythShutdown
#
# saves the powerof kernel grub entry and reboots
#

sudo grub-set-default ''P''  ### replace "P" with the poweroff menu value from 3.0!
sudo reboot

Make it executable and copy it to /usr/bin: 

  • $ chmod +x MythShutdown
$ sudo cp MythShutdown /usr/bin

Troubleshooting

Small mistakes are easy to make, so double and triple-check the things you have done.

If you were able to wake your board in step 1.4 (whether or not you are using the poweroff kernel), but you can't get MythTV to wake- chances are you made one or more small mistakes. Go back and check thoroughly.

If you were able to wake your board in step 1.4 but can't get the backend to shut down by itself- make sure that no other application like mythfrontend or mythfilldatabase is still connected to the backend since this will prevent the backend from shutting down.

If you were unable to get your board to wake for the test in step 1.4:

  1. Try it again after changing the BIOS RTC wake setting to the opposite of what it is now
  2. Try it with various combinations of BIOS settings for Power Management-type functions
  3. Google, google, google...
  4. Give your mobo manufacturer's technical support a call
  5. Some motherboards will only wake from S3 (suspend), rather than from S4 (hibernate) or S5 (power off). If yours is one of these, you'll have to investigate suspending your PC instead of shutting it down.
  6. Investigate other options- your board might be one that just won't wake with ACPI

Man, I Give Up!

If you have reached this stage, I'm sorry that ACPI wakeup did not work for your board.

To return things back to their original state: 

  • $ sudo cp hwclock.sh.bak /etc/init.d/hwclock.sh
$ sudo cp menu.lst.bak /boot/grub
$ sudo rm MythWakeSet /usr/bin/MythWakeSet MythShutdownCheck /usr/bin/MythShutdownCheck MythShutdown /usr/bin/MythShutdown

To remove the backup system files: 

  • $ sudo rm hwclock.sh.bak menu.lst.bak

If you aren't frustrated to the point of loathing shutdown/wakeup, you can investigate other wakeup options via google, the MythTV forums and our excellent Ubuntu forums.

Good Luck!

List of successful implementations

This ACPI wake method has been confirmed to work on these boards/barebones:

  • Abit VA-10
  • ASRock K7S41GX
  • Asus A8N-SLI

  • Asus K8N (disable RTC wakeup in BIOS)

  • Asus K8N-E

  • Asus K8N-E deluxe (disable RTC wakeup in BIOS)

  • Asus K8V (seems to work with unmodified hwclock.sh of Ubuntu8.04)

  • Asus M2NPV-VM
  • Asus P1-AH2

  • Asus P2-M2A690G (disable RTC wakeup in BIOS; kernel option hpet=disable is needed)

  • Asus P4-P800-E
  • Asus P5B-VM
  • Asus P5LD2-VM

  • Asus P5N-E SLI (seems to work with unmodified hwclock.sh of Ubuntu7.10)

  • Asus P5B-Deluxe (BIOS wake enabled(every day?))

  • Epia EN15000
  • ECS GF8200A V1.0
  • ECS 761GX-M754
  • ECS KT600-A
  • ECS K7VTA3 (v5.0)
  • ECS RS482-M
  • MSI MEGA 651
  • Intel 915GAG

  • Intel DG965OT (seems to work with unmodified hwclock.sh of Ubuntu7.10)

  • Intel D845PESV
  • MSI K8T NEO2-F v2.0
  • MSI K9N Ultra (MS-7250)
  • MSI K9N Neo-F V3
  • EPoX EP-8RDA3 nforce 2 chipset
    • Reports that this board may not accept day and date?
  • Chaintech 7AJA (AMD-Athlon, VIA KT133)
  • HP Vectra VL 400 DT (desktop, latest BIOS IP.01.08 from HP site, RTC OFF)
  • MSI K8MM3 (MS-7181 v.2.X) (micro-atx mainbord from MSI)
  • Jetway 830CH
  • Via Epia CN10000EG
  • Gigabyte GA-M68SM-S2
  • Gigabyte GA-MA69G-S3H

  • Gigabyte GA-MA74GM-S2H (HPET disabled)

  • Gigabyte GA-MA78GM-S2H (rev.1.0)
  • Gigabyte GA-8KNXP

These laptops also work:

These laptops only wake up from S3 (suspend):

  • Dell Inspiron 8200
  • Dell Inspiron 8500

If this guide works for you, please ADD your board to this list!

CategoryHardware CategoryPowerManagement CategoryVideo

MythTV/Install/WhatNext/ACPIWake (last edited 2011-04-09 01:50:07 by D9784B24)