[t4_ravenbird]

@kricker ; You got mail ..

I added a log-entry with a little info whenever the wakeup kicks inn, hope that will narrow it down

[DeViLRuNNeR]

Thx t4_ravenbird for this excellent patch!

I have successfully rebuild my XBMCUbuntu bin file to include this patch.
I am using a network MySQL database on my NAS(Thecus) for my xbmc databases and thx to this I can now wake the NAS before XBMC boots.
I think people who are using network MySQL databases on devices that go to sleep know about the problem that XBMC won't boot without the MySQL server being accessible.

I am also using pathsubstitutions for my sources.xml / rssfeeds.xml which are stored on the same NAS.
However because my NAS boots up very slow these are not available yet when XBMC has booted.
Hence they are not applied.


Would it be possible to integrate some kind of wait command/parameter after the WOL packet has been sent?
Maybe even with a little animation or perhaps even a ping check to see if the unit is alive?

[kricker]

Currently the patch relies on the Samba timeout or whatever is already built into XBMC. We are dealing with some issues regarding that now. There are instances where XBMC will timeout before the server wakes and then that causes some issues connecting again. t4_Ravenbird is currently looking into it.

[t4_ravenbird]

Thanks DeViLRuNNeR !

*

As I see it the patch is working OK as far as it does what it aimed to do (wake on access)
However, this is not always enough to give us the effect we would like (a system that just starts up everything and connects failure-free ..)
To patch this problem by adding a wait period after sending wake-on-lan is probably not a good design (I dont have enough overview of XBMC design that I could feel comfortable with something like that - there is a big risk of negative effects that this could lead to)
If we go in that direction we need to involve some of the guys with more knowledge of the overall design in this area than I have (I am just a new-comer to XBMC and added the wake-thing because I missed it :-)

However, I have been searching through the quite advanced file/folder-handling system in XBMC (with 'Virtual Directories' and 'Directory Cache' system) - and as I understand it there already IS a timeout/retry mechanism present in that design. And I believe there is a glitch (bug) were this retry logic not always gets activated !

@DeViLRuNNeR and/or kricker :
If you would like to try out a fix then locate 'directory.cpp' and in line 126 replace
return GetDirectory(strPath, items, hints);
with
return GetDirectory(strPath, items, hints, allowThreads);

My very quick testing looked very promising with that fix

[t4_ravenbird]

I have been experimenting further and found out some more :

-My setup is between 2 windows PC's, server is WinXP and client is Win7.
-When I start XBMC and navigate to a folder on the (suspended) server XBMC will always wake server and normally (but not always) read the contents of the folder.
-If I reboot server and then immediately put it into suspend and THEN wake it with the XBMC client it will resume but consistently fail to read the folder !
-Having a setup with a repeatable problem I have investigated what is root cause and identified that as being inside Windows networking itself :
FindFirstFileW fails if called to soon after server has started the process of resuming from suspend mode, it goes into timeout (error 53) after ~50 secs whereas on a successful connection it will return much faster.
This behavior may very well be dependent on OS (different with Linux or other flavors of Windows)
-I have tried adding a loop to read the folder twice when it fails but that does not help, it fails on second attempt as well

-I then tried adding a wait period after waking the server as has been suggested by several and that DID fix the problem for my setup. Both 10 secs and 8 secs seem enough to start successfully, I have not tried lower.

Therefore I have now submitted a new modified patch to the ticket and hope somebody will try it out
- new 'wait' parameter in advancedsettings.xml :

Code:

    <onaccesswakeup>
        <wakeup>
            <host>10.0.0.6</host>
            <mac>00:15:f2:1d:df:1e</mac>
            <tmout>700</tmout>
            <wait>8</wait>
        </wakeup>
    </onaccesswakeup>

-XBMC will also display the 'working..' dialogue while doing this wait
-The fix I showed in my last post is also included - this ensures that the 'working..' dialogue is shown while XBMC waits for reply from server

[kricker]

Awesome. I'll be sure to try this out sometime today. Great work and troubleshooting. I'll repeat your steps before I use the new patch to confirm my connection issues were just like yours.

[zebraitis]

Check my explaination and low-tech functional work-around in this thread:

http://forum.xbmc.org/showthread.php?tid=92525&page=2

[makromorphago]

That´s just what i need, too...implement this please!

[makromorphago]

Hey guys.
So I understand this right. I want to use this on my xbmcbuntu installation. That means I need to get the sourcecode. Create my own build with the patch and make it installable?
Well, how the hell do I do this. I usually use Windows, there I got a workaround, but due to another issue with bd playback and the buildin bd drive in my HTPC which is not recognized by the lib used in XBMC Win I switched over to xbmcbuntu, but there I cant write a batch file with a wakeonlan command like in win...so issue after issue.

Does anyone already have a eden xbmcbuntu build with this feature?
Thanx

[kricker]

I don't believe anyone has made any custom builds of this, besides those of us working with it. You can grab the source code from the patch attached to the ticket. It is a .patch file, but it is really just a text file. You can go thru and and make the changes contained within the patch on your own. I'm not sure how OS agnostic the path is. If you can't do it manually, then you might just be better off waiting on it to get pulled.

[t4_ravenbird]

The patch is supposed to be OS agnostic ..
Did you test anything with the new 'wait'-parameter yet?

[kricker]

Not a thorough test yet sorry. I've only tested with my dev PC. I need to test with the more problematic HTPC. I will do that this weekend for sure.

[kricker]

I think it is time to get a Pull request on this to get it into mainline, unless anyone has any objections or wants to add some tweaks to it.

[tocinillo]

I think it is time to get a Pull request on this to get it into mainline, unless anyone has any objections or wants to add some tweaks to it.

Finally it was merged into mainline?

I tried to apply this patch into FernetMenta latest GIT (support for PVR, new Audio Engine and improvments over VDPAU) and when I try to compile the process fail...

Thanks.

[kricker]

No, not yet. Since there have been no objections, I will do a PR for it tonight. It would have been nice to get the advanced settings put into the GUI, but no one stepped up to help with that so it'll just be as it is.