[t4_ravenbird]

WakeOnAccess kicks in and first thing it does is to wait for network to initialize while displaying the progress dialog until timeout OR dialog is cancelled, in which case the wakeup will be skipped and control returns to whatever kicked the wakeup (mysql in this case)

There seems to be some strange behavior with the progress dialog here that I know too little about .. from the log it seems the dialog is not pre-loaded and must be loaded - strange, but OK (it takes 2 seconds++ to load, is that normal?).
Then there is the error at 11:44:33 CheckDisplayEvents .. dont know what it is but it looks bad, it comes from WinSystemX11.cpp here ;

Code:

void CWinSystemX11::CheckDisplayEvents()
{
#if defined(HAS_XRANDR)
  bool bGotEvent(false);
  bool bTimeout(false);
  XEvent Event;
  while (XCheckTypedEvent(m_dpy, m_RREventBase + RRScreenChangeNotify, &Event))
  {
    if (Event.type == m_RREventBase + RRScreenChangeNotify)
    {
      CLog::Log(LOGDEBUG, "%s: Received RandR event %i", __FUNCTION__, Event.type);
      bGotEvent = true;
    }
    XRRUpdateConfiguration(&Event);
  }

  // check fail safe timer
  if (m_dpyLostTime && CurrentHostCounter() - m_dpyLostTime > (uint64_t)3 * CurrentHostFrequency())
  {
    CLog::Log(LOGERROR, "%s - no display event after 3 seconds", __FUNCTION__);
    bTimeout = true;
  }
...

It looks to me like the progress-dialog returns "cancelled" (as if the user hit "cancel" -button) and then the wakeonAccess indeed cancels ..
It almost looks like the progress-dialog gives up because the underlying display-system fails to get ready in time.. at this time I need help from someone who knows the architecture of xbmc in order to find out how to deal with this.
It may be somehow provoked by the WakeOnAccess function, but I dont know
(Also I dont understand how this would happen now and not in the previous build you made - as far as I can see everything up to this point should have been equal)