• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 11
XBMC on Pi: Add TV/monitor Power Save support when idle?
#31
(2014-01-19, 22:06)jose1711 Wrote: thanks for sharing, though for some strange reason XBMC.Quit on my openelec system equals to shutting down the system. so instead of sending that json request i need to do os.system("killall xbmc.bin")

That is strange, and obviously not correct...

Can you confirm if:
Code:
./texturecache.py power exit
(which will send the Application.Quit() JSON command) causes your Pi to shut down?

If so that would suggest a bug in the version of OpenELEC you are running... what version of OpenELEC is it? Try upgrading to the latest Frodo 3.2.4, or Gotham.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#32
Code:
OpenELEC:~ # ./texturecache.py power exit
OpenELEC:~ # Connection to malina closed by remote host.
Connection to malina closed.

openelec is 3.2.4. also.. somehow this killall workaround is working until the very first wake up. then (when xbmc is restarted) i got no reply on port 9090 - successive xbmc restart seemed to fix that - i will try to find out what's going on.
Reply
#33
(2014-01-19, 23:30)jose1711 Wrote:
Code:
OpenELEC:~ # ./texturecache.py power exit
OpenELEC:~ # Connection to malina closed by remote host.
Connection to malina closed.

openelec is 3.2.4. also.. somehow this killall workaround is working until the very first wake up. then (when xbmc is restarted) i got no reply on port 9090 - successive xbmc restart seemed to fix that - i will try to find out what's going on.

That isn't how it behaves in Gotham, the Application.Quit() should initiate an immediate restart of xbmc.bin... I though that was how it worked in Frodo too. I'll try installing Frodo 3.2.4 and see what's up.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#34
OK, there's two problems with rbphdmi and OpenELEC Frodo:
  1. OpenELEC Frodo is designed so that a clean exit from xbmc.bin (exit code 0, ie. Application.Quit()) results in a poweroff. Not really sure why, as the user actioned poweroff is signaled by exit code 64.
  2. Once xbmc.bin has been restarted (either after a clean exit or killall), the remote communication server (aka RPC server) will fail to start, which means there is no JSON communication
While I could code around #1, #2 is pretty much a showstopper.

See next post for a hack that will workaround the problem by rebooting the Pi instead of powering off after an Application.Quit().
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#35
@jose1711: This is a fix for OpenELEC Frodo 3.2.x - instead of powering off after an Application.Quit(), it will reboot the Pi. Rebooting the Pi ensures the RPC server connects every time, but does of course incur additional delay (about 20 seconds on a 1GHz Pi) while the Pi reboots, then there is the time required for XBMC to start of another 15 seconds, for a total of about 35 seconds (timed from the moment the HDMI is re-enabled to the appearance of a usable GUI in XBMC, on a 1GHz Pi)..

Add the following code to /storage/.config/autostart.sh:
Code:
#!/bin/sh

# Hack to work-around problems with Frodo 3.x.x
if [ $PPID -eq 1 -a -d /etc/init.d -a -z "${XBMC_INIT_NEW}" ]; then
  XBMC_INIT=$(grep "DISPLAY=:0.0" /etc/init.d/* | awk -F: '{print $1}')
  export XBMC_INIT_NEW=/tmp/pihackxbmc
  . /etc/profile
  logger -t "$(basename $0)" "Modifying ${XBMC_INIT}"
  cp  ${XBMC_INIT} ${XBMC_INIT_NEW}
  sed -i "s#\(RET=..\)#\\1\n    [ \$RET = 0 ] \&\& RET=66#" ${XBMC_INIT_NEW}
  #cp /storage/93_xbmc ${XBMC_INIT_NEW}
  logger -t "$(basename $0)" "Starting XBMC using ${XBMC_INIT_NEW}"
  . ${XBMC_INIT_NEW}
fi

(sleep 20 && /storage/texturecache.py @logfile= @debug=yes rbphdmi) &

Reboot, and next time the HDMI has been been disabled and needs to be re-enabled, the Pi will reboot.

Should you switch to Gotham at some point in the future, the above hack will be automatically disabled as it is not required for Gotham (you can then safely remove lines 3 to 13.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#36
thank you, but i am not fond of the reboot solution. if anything - xbmc is not the only application running on my openelec system and i dislike disconnects/service interruptions. also i prefer stability (frodo) to new features (gotham). how about an alternative approach: kill xbmc as many times as needed (until there's something responding on port 9090)? check out this (no answer from telnet means - port is in listening state):

Code:
OpenELEC:~ # echo | telnet localhost 9090
OpenELEC:~ # killall xbmc.bin
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # killall xbmc.bin
OpenELEC:~ # echo | telnet localhost 9090
telnet: can't connect to remote host (127.0.0.1): Connection refused
OpenELEC:~ # killall xbmc.bin
OpenELEC:~ # echo | telnet localhost 9090
OpenELEC:~ # echo | telnet localhost 9090

this may not be necessarily faster than reboot but surely nicer to other processes running on raspi.
Reply
#37
I can totally understand you not wanting to use the reboot option.

Rather than repeatedly kill xbmc.bin until the RPC port is no longer bound to an address, try the following method, which actually works quite well most of the time....

1. Create a new script, /storage/rbphdmi.sh:
Code:
#!/bin/sh

LOCK=/var/lock/xbmc.disabled

WAIT4PORT='
import sys, time, socket
def p(m):
  print(m)
  sys.stdout.flush()

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
p("[WAIT4PORT]: Checking if the RPC port is already bound to an address...")
c=0
while True:
  try:
    s.bind(("localhost", 9090))
  except Exception as e:
    if c==0: p("[WAIT4PORT]: RPC port is already bound - waiting... [%s]" % str(e))
    c += 1
    time.sleep(1.0)
  else:
    p("[WAIT4PORT]: RPC port is not bound")
    break
s.close()
'

while [ true ]; do
  # Give xbmc.bin time to bring up the services before trying to connect with JSON-RPC
  sleep 20

  # Create the lock file so that xbmc.bin doesn't automatically restart after exiting
  touch $LOCK

  # Monitor notifications and disable/enable HDMI when required
  /storage/texturecache.py @logfile= @debug=yes @rpc.retry=0 rbphdmi | logger -t "$(basename $0)"

  # Wait until RPC port is no longer bound to an address
  python -c "${WAIT4PORT}" | logger -t "$(basename $0)"

  # Start XBMC by removing the lock file
  rm $LOCK
done

2. Grant execute permission to /storage/rbphdmi.sh:
Code:
chmod +x /storage/rbphdmi.sh

3. Update the autostart.sh hack in post #35, replacing "RET=66" with "RET=255" - this will ensure that xbmc.bin is restarted each time, rather than the Pi rebooted.

4. Add a call to /storage/rbphdmi.sh at the end of autostart.sh in place of the current call to texturecache.py, ie.:
Code:
/storage/rbphdmi.sh &

4. sync, reboot.

5. "tail -f /var/log/messages" to see rbphdmi-related events.

What the new script rbphdmi.sh will do is prevent xbmc.bin from restarting by creating a lock file (/var/lock/xbmc.disabled) until the RPC port is no longer bound to an address, at which point the lock file is removed and xbmc.bin can then load successfully.

Quite often, the RPC port will not be bound to an address after xbmc.bin has exited with Application.Quit(), in which case there will be no delay before xbmc.bin is restarted. Basically, how it is all of the time with Gotham! Smile

However, whenever the port remains bound to an address, usually after a "killall xbmc.bin", the delay before the port is unbound will be 60 seconds. I've tried changing the default value for net.ipv4.tcp_fin_timeout to something less than 60 seconds, but xbmc.bin is ignoring whatever value I set (or maybe I'm changing the wrong tcp setting?) so the delay is always 60 seconds whenever the address/port remains bound after xbmc.bin has exited, and I've found no way to reduce it.

This is my last shot at working around the problems with Frodo - unless you can find a better way to make it work then upgrading to Gotham is the only other option! Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#38
thank you very much, this setup is running for 11 days without any issues (i remember faintly i had to restart the script manually at the beginning though).
Reply
#39
With the introduction of "virtual suspend mode" in the latest Gotham RPi test builds, the use of rbphdmi is no longer necessary if you want to suspend HDMI after a user defined idle period.

rpbhdmi will however still function when the client supports virtual suspend, in which case rpbhdmi can be used to augment sleep/resume with additional CEC functionality by overriding bin.tvservice.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#40
(2014-03-05, 01:00)MilhouseVH Wrote: With the introduction of "virtual suspend mode" in the latest Gotham RPi test builds, the use of rbphdmi is no longer necessary if you want to suspend HDMI after a user defined idle period.

rpbhdmi will however still function when the client supports virtual suspend, in which case rpbhdmi can be used to augment sleep/resume with additional CEC functionality by overriding bin.tvservice.

This looks very promising indeed. It'll be a day or two before I can give this a play (rpi in use).

Thanks for the update. Oh and popcornmix, thanks also.
Media Companion Dev.
Media Companion - Kodi / XBMC - Media Companion
Reply
#41
So I attempted to get this working with a script like
Code:
#!/bin/bash

/opt/vr/bin/tvservice $1

case "$1" in
  "--off")       echo "standby 0" | cec-client -s >/dev/null;;
  "--preferred") echo "on 0" | cec-client -s >/dev/null;;
esac
Note I'm on Rampbmc, and tvservice is under /opt/vr/bin.

Called this mytv.sh and chown +x ~/mytv.sh to make it executable

I downloaded texturecache.py and it's sitting in /home/pi/texturecache.py, also made executable.

So tried running this command
Code:
./texturecache.py @logfile= @xbmc.host=localhost @bin.tvservice=/home/pi/mytv.sh rbphdmi
but just hangs
also tried /home/pi/texturecache.py etc, but it just sits at a blank line. That was this morning.

right now, I'm just getting a list of help.

Also tried adding @logfile=/home/pi/test.txt, but this is all that was inside
Quote:2014-03-06 21:15:56.372486:MainThread: Command line args: ['./texturecache.py', '@logfile=/home/pi/test.txt', '@xbmc.host=localhost', '@bin.tvservice=mytv.sh']
2014-03-06 21:15:56.378530:MainThread: Current version #: v1.5.1
2014-03-06 21:15:56.379382:MainThread: Current platform : linux2
2014-03-06 21:15:56.380202:MainThread: Python version #: v2.7.3.0 (final)

Wondering, do I need to have to have allow remote control enabled in settings?
Media Companion Dev.
Media Companion - Kodi / XBMC - Media Companion
Reply
#42
Add @debug=yes to see any output.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#43
Right, Here's what was on screen of PuTty
Code:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pi@raspbmc:~$ wget -q http://is.gd/XGXbTG -O ~/texturecache.py
pi@raspbmc:~$ ls
libdvdcss-1.2.13  libdvdcss-1.2.13.tar.bz2  mytv.sh  test.txt  texturecache.py
pi@raspbmc:~$ chmod +x ~/texturecache.py
pi@raspbmc:~$ ./texturecache.py @logfile=/home/pi/t2.txt @debug=yes @xbmc.host=localhost @bin.tvservice=/home/pi/mytv.sh rbphdmi
2014-03-07 06:21:10.409874: [rbphdmi] HDMI Power off delay: 900 seconds
2014-03-07 06:21:10.413070: [rbphdmi] Player OnStop delay : 5 seconds
2014-03-07 06:21:10.415655: [rbphdmi] Path to tvservice   : /home/pi/mytv.sh
2014-03-07 06:21:10.419359: [rbphdmi] Connecting to XBMC on localhost...
2014-03-07 06:21:10.441192: [rbphdmi] Connected to XBMC
2014-03-07 06:21:10.443606: [rbphdmi] HDMI power management thread - initialising XBMC and HDMI state
2014-03-07 06:21:10.621816: [rbphdmi] HDMI is [on], Screensaver is [active], Player is [inactive], Library scan [inactive], Can Suspend [yes]
2014-03-07 06:21:55.999346: [rbphdmi] Screensaver has deactivated
2014-03-07 06:26:15.751711: [rbphdmi] Screensaver has activated
2014-03-07 06:28:17.159409: [rbphdmi] Client is now suspended
2014-03-07 06:28:17.517646: [rbphdmi] XBMC exited - waiting for restart...
2014-03-07 06:28:19.733251: [rbphdmi] HDMI is now off
2014-03-07 06:28:32.537766: [rbphdmi] XBMC not responding, retries remaining 12
2014-03-07 06:28:37.547657: [rbphdmi] XBMC not responding, retries remaining 11
2014-03-07 06:28:42.563494: [rbphdmi] XBMC not responding, retries remaining 10
^Z
[1]+  Stopped                 ./texturecache.py @logfile=/home/pi/t2.txt @debug=yes @xbmc.host=localhost @bin.tvservice=/home/pi/mytv.sh rbphdmi
pi@raspbmc:~$ date
Fri Mar  7 06:37:10 NZDT 2014
pi@raspbmc:~$

And here's the log file
Raspbmc Gotham by miappa in from here
Pi set to suspend after 5 minutes.

Help me Obiwan...
Image
Media Companion Dev.
Media Companion - Kodi / XBMC - Media Companion
Reply
#44
Code:
2014-03-07 06:28:17.159409: [rbphdmi] Client is now suspended

At this point, it should make a few calls to your @bin.tvservice.

First, it will check the status of the display (@bin.tvservice --status) to determine if the TV has been powered off (not HDMI off, actually turned off/standby). If the TV is still on (not all TVs report this status correctly, most saying they're on when they're off) then the HDMI will be turned off with the call "@bin.tvservice --off" - since Virtual Suspend has already turned off the HDMI, this does nothing other than give you a chance to do something CEC-related now that the HDMI is being turned off. Lastly, it will call "@bin.tvservice --status" again to confirm the HDMI is now off (which it should be).

This all looks to be working, as it prints "HDMI is now off" which it will only do so when it gets the correct response in the last step above.

A similar sequence of events will take place when the Pi is resumed (only this time, the HDMI will be enabled, with --preferred instead of --off, even though the HDMI should already have been enabled).

Code:
2014-03-07 06:28:17.517646: [rbphdmi] XBMC exited - waiting for restart...

What puzzles me is the above, why is XBMC exiting? It shouldn't be exiting now, and wasn't instructed by rbphdmi to exit.

Other than that, I'm not sure what the problem is as it seems to be working normally - you'll need to add some tracing to your @bin.tvservice to log the calls that are being made from rbphdmi.

I may add some extra logging to record when calls to @bin.tvservice are made.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#45
I'll check in about 3 hrs what "tvservice --status" says when
a) Raspbmc handles HDMI suspend
b) texturecache.py handles suspend.
c) I put the TV into suspend.

I figure It's something I'm missing in the procedure.

BTW: When I type the command and press enter, I don't get the next command prompt. Have to Crtl-Z to get back to command prompt. (Above test I'll open an second PuTty window). And when we get this working, I'll need to figure out how to add running this on Raspbmc start-up, but figure their forum probably has info on how to do this.

Thanks for taking the time to look into this.

Rob
Media Companion Dev.
Media Companion - Kodi / XBMC - Media Companion
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 11

Logout Mark Read Team Forum Stats Members Help
XBMC on Pi: Add TV/monitor Power Save support when idle?1