[Milhouse]

Anyway, I overwrote the files on the SD with those from rbej's latest build now and tested with the Update files (so basically updating to the same version again) and that worked, so unless anyone else has a problem it's probably not worth looking at the kernel.

OK, agreed...

More importantly, it no longer works for me.

Maybe why the PVR stuff has been reverted, new build just uploaded (see post before yours). It seemed to be working fine for me, but then I'm not using any of the PVR stuff.

[doveman2]

Maybe why the PVR stuff has been reverted, new build just uploaded (see post before yours). It seemed to be working fine for me, but then I'm not using any of the PVR stuff.

I did kill {tvheadend PID} and then kill {xbmc.bin PID} and then xbmc restarted and managed to finish the "Loading EPG data" but then froze right after that. I've posted the two logs here http://pastebin.com/ez692M1w (before killing) and here http://pastebin.com/vYenz3JJ (after killing and XBMC restarting). I'll try the newest build though, as you say maybe the PVR stuff is the problem

[rbej]

PVR master branch not work properly with Xbmc Frodo Branch. I back to PVR Frodo Branch.

If you see log network message on startup, please dont worry. This is correct.

https://github.com/OpenELEC/OpenELEC.tv/pull/2031

[doveman2]

Cool, seems to be OK again with the latest update

[Milhouse]

- remove "Suspend" and "Hibernate" from XBMC shutdown menu (taken from XBIAN)

I queried the addition of this change to the author of Confluence Modified which is great on the Pi, to see if he could also add it, and he replied that rather than hacking the skin with such a change, the skin should be querying XBMC to determine whether Suspend and Hibernate options are supported by the hardware and not displaying options that are not supported... so assuming this statement is true, then it suggests the Raspberry Pi is lying when it reports that it supports Suspend and Hibernate, does anyone know if this has been raised as an issue?

Edit: It's very true... these are the default visibility options for Suspend and Hibernate in Confluence:

Code:

<visible>System.CanSuspend</visible>
<visible>System.CanHibernate</visible>

so it would appear the Raspberry Pi is not being honest about it's Suspend and Hibernate capabilities. Investigating...

It turns out that the Raspberry Pi is using the default power interface, CNullPowerSyscall, and is getting all power options by default:

Code:

virtual bool CanPowerdown() { return true; }
virtual bool CanSuspend()   { return true; }
virtual bool CanHibernate() { return true; }
virtual bool CanReboot()    { return true; }

Rather than patch individual skins, it would be better/easier to patch the default power interface when building for the Pi, thus correctly disabling Suspend/Hibernate for all skins... the following patch achieves this:

Code:

diff --git a/xbmc/powermanagement/PowerManager.h b/xbmc/powermanagement/PowerManager.h
--- a/xbmc/powermanagement/PowerManager.h       2013-03-09 22:57:46.919080343 +0000
+++ b/xbmc/powermanagement/PowerManager.h       2013-03-09 22:58:08.775080999 +0000
@@ -32,8 +32,8 @@
   virtual bool Reboot()       { return false; }

   virtual bool CanPowerdown() { return true; }
-  virtual bool CanSuspend()   { return true; }
-  virtual bool CanHibernate() { return true; }
+  virtual bool CanSuspend()   { return false; }
+  virtual bool CanHibernate() { return false; }
   virtual bool CanReboot()    { return true; }

   virtual int  BatteryLevel() { return 0; }

[sraue]

- remove "Suspend" and "Hibernate" from XBMC shutdown menu (taken from XBIAN)

I queried the addition of this change to the author of Confluence Modified which is great on the Pi, to see if he could also add it, and he replied that rather than hacking the skin with such a change, the skin should be querying XBMC to determine whether Suspend and Hibernate options are supported by the hardware and not displaying options that are not supported... so assuming this statement is true, then it suggests the Raspberry Pi is lying when it reports that it supports Suspend and Hibernate, does anyone know if this has been raised as an issue?

Edit: It's very true... these are the default visibility options for Suspend and Hibernate in Confluence:

Code:

<visible>System.CanSuspend</visible>
<visible>System.CanHibernate</visible>

so it would appear the Raspberry Pi is not being honest about it's Suspend and Hibernate capabilities. Investigating...

the problem here is xbmc calls "upower" to get if suspend/hibernate is supported. because upower depends on consolekit, which depends (still) on x11 librarys we dont include upower (also because supend/hibernate is not supported). this also means xbmc shows this options which are set as default because xbmc dont get the requested info

[sraue]

It turns out that the Raspberry Pi is using the default power interface, CNullPowerSyscall, and is getting all power options by default:

Code:

virtual bool CanPowerdown() { return true; }
virtual bool CanSuspend()   { return true; }
virtual bool CanHibernate() { return true; }
virtual bool CanReboot()    { return true; }

Rather than patch individual skins, it would be better/easier to patch the default power interface when building for the Pi, thus correctly disabling Suspend/Hibernate for all skins... the following patch achieves this:

Code:

diff --git a/xbmc/powermanagement/PowerManager.h b/xbmc/powermanagement/PowerManager.h
--- a/xbmc/powermanagement/PowerManager.h       2013-03-09 22:57:46.919080343 +0000
+++ b/xbmc/powermanagement/PowerManager.h       2013-03-09 22:58:08.775080999 +0000
@@ -32,8 +32,8 @@
   virtual bool Reboot()       { return false; }

   virtual bool CanPowerdown() { return true; }
-  virtual bool CanSuspend()   { return true; }
-  virtual bool CanHibernate() { return true; }
+  virtual bool CanSuspend()   { return false; }
+  virtual bool CanHibernate() { return false; }
   virtual bool CanReboot()    { return true; }

   virtual int  BatteryLevel() { return 0; }

will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find.

[Milhouse]

will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find.

It works as a patch for a Pi, that's all I've tested with.

the problem here is xbmc calls "upower" to get if suspend/hibernate is supported. because upower depends on consolekit, which depends (still) on x11 librarys we dont include upower (also because supend/hibernate is not supported). this also means xbmc shows this options which are set as default because xbmc dont get the requested info

The problem is there is no valid power management option for the Pi, so it always uses the default null provider.

Here is the code to determine a suitable option:

Code:

#if defined(TARGET_DARWIN)
  m_instance = new CCocoaPowerSyscall();
#elif defined(TARGET_ANDROID)
  m_instance = new CAndroidPowerSyscall();
#elif defined(_LINUX) && defined(HAS_DBUS)
  if (CConsoleUPowerSyscall::HasConsoleKitAndUPower())
    m_instance = new CConsoleUPowerSyscall();
  else if (CConsoleDeviceKitPowerSyscall::HasDeviceConsoleKit())
    m_instance = new CConsoleDeviceKitPowerSyscall();
  else if (CSystemdUPowerSyscall::HasSystemdAndUPower())
    m_instance = new CSystemdUPowerSyscall();
  else if (CUPowerSyscall::HasUPower())
    m_instance = new CUPowerSyscall();
#ifdef HAS_HAL
  else
    m_instance = new CHALPowerSyscall();
#endif
#elif defined(_WIN32)
  m_instance = new CWin32PowerSyscall();
#endif

  if (m_instance == NULL)
    m_instance = new CNullPowerSyscall();
[

None of the Linux tests are performed, not even HAS_HAL, so I'm guessing HAS_DBUS is not defined. On a Pi, m_instance is always NULL, so is assigned an instance of CNullPowerSyscall.

So the question becomes - maybe one for Popcornmix - does the Pi have any kind of power management interface, and if so should the above test be modified rather than patching the properties of the default?

Edit: On further investigation, _LINUX and HAS_DBUS are both defined, but HAS_HAL isn't, so none of the four conditions tested within __LINUX && HAS_DBUS evaluate to true on a R-Pi, thus explaining why m_instance is always null before being assigned the default instance.

[Milhouse]

Rather than patch individual skins, it would be better/easier to patch the default power interface when building for the Pi, thus correctly disabling Suspend/Hibernate for all skins... the following patch achieves this:

Patching the power management instance with correct options for the Raspberry Pi also means that the Power Saving settings screen no longer offers Suspend and Hibernate, which is a nice bonus.

[Milhouse]

will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find.

PR #2403.

[popcornmix]

PR #2403.

404.

[rbej]

Very good patch. Works well.

[Milhouse]

PR #2403.

404.

I did just get a 404 on my phone when clicking the link, but it's loading fine on my desktop... maybe an intermittent github problem?

[Milhouse]

Google told me to use either sudo shutdown -h or sudo halt but If I use either command I just get an error saying sudo not found

In OpenELEC you don't need sudo as you're already root (the super-user). However neither shutdown or halt exist in OpenELEC, so presumably you're using instructions for another distribution. "poweroff -f" is the command to shutdown OpenELEC, and "reboot" to reboot.

[Milhouse]

will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find.

PR #2403.

I've also just updated this PR (though I think I may have messed it up slightly by trying to squash my commits!) to include ifdef's for the Raspberry Pi, so that original suspend/hibernate behaviour is restored for non-Pi systems. The patch is here, and maybe this patch could be accepted into xbmc master at some point (unless there is a better solution).