[mythtv-users] Mythwelcome wakes up the backend

[MartinG]

Hi list!

I have a question regarding Mythwelcome.
The short version:
It seems that mythwelcome tries to wake up the backend immediately
after it goes to sleep, even though Mythwelcome has done the countdown
and got the shutdown message. Excerpt from frontend log:
  2007-09-23 12:27:05.598 MythWelcome received a SHUTDOWN_NOW event
  2007-09-23 12:27:07.967 Event socket closed. No connection to the backend.
  ...
  2007-09-23 12:30:16.953 Trying to wake up the MasterBackend now.
  would run the WakeServerCommand now, if set!
  2007-09-23 12:30:16.958 Waiting for 5 seconds until I try to reconnect again.
  WOL package sent to <snip: my server MAC address>


Now for the long version:
This is my setup:
Backend server:
mythtv-0.20.2-165.fc6
kernel-2.6.22.5-49.fc6

Frontend:
kernel-2.6.20-1.2944.fc6
mythtv-0.20.2-164.fc6

Both the frontend and backend use UTC as system time (given in
"system-config-date") and both clocks are totally in sync, as both are
using NTP.

I have read http://www.mythtv.org/wiki/index.php/ACPI_Wakeup
and use alarm-script.sh given there. I have checked, and it works on
the backend, e.g. if I enter the following as root on the backend:

# NOW=`date +%s`
# WAKEUP=$((NOW + 6*60))
# /home/kos/.mythtv/alarm-script.sh --settime $WAKEUP
# poweroff -h

...it will automatically start after 6 mins. (My backend does not
support ACPI suspend, only poweroff as given above).

OK, so it should at least be possible to do automatic shutdown/wakeup.
Now, this is my config:

On the frontend, I've done the following:
$ mythwelcome -s
  nvram-wakeup command: /home/mythtv/.mythtv/alarm-script.sh
  nvram-wakeup restart command: <blank>
  command to reboot: /sbin/reboot
  command to shutdown: /sbin/poweroff -h
  xterm: xterm
  command to start frontend: /usr/bin/mythfrontend

In mythwelcome, I've pressed "i" and used this config:
  Period 1: disabled (00:00-00:00)
  Period 2: disabled (00:00-00:00)
  Automatically start: No
  Shutdown with master: No

On the backend:
# service mythbackend stop
# mythtv-setup
General:
Shutdown/Wakeup Options:
  Startup command:            (empty)
  Block shutdown before
  client connected:           checked
  Idletimeout (secs):         1200 (20 mins, which is max)
  Max wait for rec (mins)     15
  Startup before rec (secs)   180 (3 mins)
  Wakeup time format:         yyyy-MM-ddThh:mm
  Set wakeup time command:    mythshutdown --setwakeup $time
  Server Halt command:        mythshutdown --shutdown
  Pre shutdown check command: mythshutdown --check

# service mythbackend start

I've restarted both the frontend and the backend (I guess a "service
mythbackend restart" would do the trick, but I actually power cycled
them)

On the frontend, when I start mythfrontend (from mythwelcome), watch
livetv, and then exit the frontend, I get back to mythwelcome, which
tells me:
  "MythTV is idle and will shutdown in 180 secs"
  "There are no recordinds currently taking place"
and there is no scheduled recordings withing a couple of hours.
The countdown is updated every 10 seconds, and will stop at "10 seconds".

Backend log reads (/var/log/mythtv/mythbackend.log):
  2007-09-23 12:24:05.858 I'm idle now... shutdown will occur in 180 seconds.
  2007-09-23 12:24:14.868 170 secs left to system shutdown!
  2007-09-23 12:24:24.882 160 secs left to system shutdown!
  2007-09-23 12:24:34.896 150 secs left to system shutdown!
  ...
  2007-09-23 12:26:45.077 20 secs left to system shutdown!
  2007-09-23 12:26:55.091 10 secs left to system shutdown!

  Broadcast message from root (Sun Sep 23 12:27:05 2007):

  The system is going down for system halt NOW!
  sh: /usr/bin/nvram-wakeup: No such file or directory

The frontend log reads:
  2007-09-23 12:23:37.604 Connecting to backend server:
192.168.3.9:6543 (try 1 of 20)
  2007-09-23 12:23:37.606 Using protocol version 31
  Destroying SipFsm object
***
The backend server shuts down here
Mythwelcome states that "Cannot connect to server!"
Then, mythwelcome will try to wake the server:
Frontend log after backend has shut down:
***
  2007-09-23 12:27:05.598 MythWelcome received a SHUTDOWN_NOW event
  2007-09-23 12:27:07.967 Event socket closed. No connection to the backend.
  2007-09-23 12:27:34.613 Connecting to backend server:
192.168.3.9:6543 (try 1 of 20)
  2007-09-23 12:27:46.612 Trying to wake up the MasterBackend now.
  QSqlQuery::exec: database not open
  2007-09-23 12:27:49.665 DB Error (KickDatabase):
  Query was:
  SELECT NULL;
  No error type from QSqlError?  Strange...
  2007-09-23 12:27:49.717 Database not open while trying to load
setting: WOLbackendCommand
  would run the WakeServerCommand now, if set!
  2007-09-23 12:27:49.722 Waiting for 5 seconds until I try to reconnect again.
  2007-09-23 12:27:54.723 Connecting to backend server:
192.168.3.9:6543 (try 2 of 20)
  2007-09-23 12:27:55.843 Trying to wake up the MasterBackend now.
  would run the WakeServerCommand now, if set!
  2007-09-23 12:27:55.849 Waiting for 5 seconds until I try to reconnect again.
  ...
  2007-09-23 12:30:13.952 Connecting to backend server:
192.168.3.9:6543 (try 20 of 20)
  2007-09-23 12:30:16.953 Trying to wake up the MasterBackend now.
  would run the WakeServerCommand now, if set!
  2007-09-23 12:30:16.958 Waiting for 5 seconds until I try to reconnect again.
  WOL package sent to <snip: my server MAC address>


Server wakes up, as the WakeOnLan (WOL) package was sent from the frontend.

MythWelcome still have "MythTV is idle and will shutdown in 10 seconds.",
but it have connected: "There are no recordings currently taking place"
The rest of the frontend log reads:
  WOL package sent to <snip: my server MAC address>
  ICE default IO error handler doing an exit(), pid = 20705, errno = 32
  2007-09-23 12:32:32.109 Connecting to backend server:
192.168.3.9:6543 (try 1 of 20)
  2007-09-23 12:32:32.111 Trying to wake up the MasterBackend now.
  would run the WakeServerCommand now, if set!
  2007-09-23 12:32:32.117 Waiting for 5 seconds until I try to reconnect again.
  2007-09-23 12:32:37.118 Connecting to backend server:
192.168.3.9:6543 (try 2 of 20)
  2007-09-23 12:32:37.257 Using protocol version 31


Phew, sorry for the extensive log messages.
I will provide more details if needed - maybe I've just overlooked
some basic setting somewhere.

Any help appreciated!

best regards
MartinG