Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Wake On Access (woa) - 'Just in time' WOL when accessing MySQL or FileShare Server #1892

Merged
merged 1 commit into from May 10, 2013

Conversation

Projects
None yet
Contributor

t4-ravenbird commented Dec 6, 2012

Forum thread : http://forum.xbmc.org/showthread.php?tid=124340

Replacement for abandoned pull request #1112

Refactored solution based on work by @pieh including simple GUI-setup as discussed in old PR.

Working for Windows (tested by @kricker) and Linux (tested by @bilbonvidia) - but needs verification for other platforms.

Owner

Memphiz commented Dec 6, 2012

I'm not able to do a pull request to your repo (no clue why - but github doesn't show it as a target repo for pull requests).

For getting this to work on osx and ios add this patch (git am )

http://pastebin.com/Y4PcyF9N

Seems your repo is a bit messy in general. You shouldn't work in the master branch normally.

Contributor

t4-ravenbird commented Dec 7, 2012

OK, I grabbed the "../network/osx/ioshacks.h" file in your patch, but this is a new and unreferenced file so how will it matter? Was your patch incomplete?

Owner

Memphiz commented Dec 7, 2012

Ohh yeah - sorry. Somehow i mixed up my patches.

You need this one too of course:

https://github.com/Memphiz/xbmc/commit/0985c90b85a09cd214af74795a09f547555d3507#diff-3

Contributor

t4-ravenbird commented Dec 7, 2012

Thanks a lot ! (Hope I got it right)
I assume you built it .. did you test out anything also?

Owner

Memphiz commented Dec 7, 2012

I only tested if it recognized/discovered the macs of my sources/mysql server when i enabled the feature in power management. If i got it right this is the only thing which is platform dependend - everything else should work on all platforms right? I'm not able to test wakeup because my server is a arm-based dockstar which doesn't sleep ;)

Owner

Memphiz commented Dec 7, 2012

Yep you got the commit right - though we need to redo the xcode sync when this PR is merged most likly - but thats no problem ...

Contributor

t4-ravenbird commented Dec 7, 2012

There is also a new ping-function in the network class but I assume it must have compiled as is then .. It just does system("ping ..") and if we are lucky it will work.
The rest should be platform independent, but it does not work until it is verified;-)

Member

da-anda commented Jan 17, 2013

just gave this a try. Working nice in general, but I have some issues with it:

  • I don't want my NAS to be woken unless I want to play a movies, but something seems to wake it always (maybe a script from the skin that's checking for a file)
  • I got several KaiToasts that the device is already awake - do we really need those?
  • I'm not sure if it was related to this feature enabled (will test again), but starting playback of a video with device already awake took very long
  • My NAS needs a long time to do a cold boot and the timeout the WOL action was waiting for it was to short. IIRC there is some advanced setting to change it, but IMO it should be possible to change it in GUI as WOL is really nothing "advanced" anymore these days.
Contributor

t4-ravenbird commented Jan 17, 2013

  • The patch is supposed to do just that (wake server only when accessed). Log should show why it kicked in, but you need to enable Debug-logging. (I used LOGINFO, maybe LOGNOTICE should be used instead so it comes up without debug-logging)
  • Maybe just drop them, yes. (They only come if your 'timeout' corresponds badly with your server's actual idle-time before it enters suspend, so if you tune 'timeout' in wakeOnLan.xml it would help)
  • WakeOnLan.xml ...
Member

da-anda commented Jan 18, 2013

@t4-ravenbird

  • in my case it also wakes the NAS when checking for thumbnails/fanart it seems although they already are cached (need to check log with a new build)
  • I noticed that this patch queues WOL messages even if the device is already running. Why is that needed? To prevent it from going to sleep again? Shouldn't active file access prevent this?
Contributor

t4-ravenbird commented Jan 18, 2013

I dont understand what you mean by queuing wol messages? Only scenario where more than 1 wol gets transmitted would be if more than 1 thread accesses server at 'same time' - there is no mutex around the wakeup since worst thing that can happen due to multithreading would be just that ; more than 1 wol is transmitted in a short time-window.
After a wakeup is performed there will be no more attempts to wake until 'timeout' expires, and then only if host-up-check (ping) fails.

The patch will by design NOT prevent server from going to sleep. (If keeping server alive was acceptable behavior then this patch would not be required at all as I see it - keep-alive wols could be done by plug-ins already)

@t4-ravenbird t4-ravenbird and 1 other commented on an outdated diff Jan 19, 2013

xbmc/Application.h
@@ -204,6 +204,7 @@ class CApplication : public CXBApplicationEx, public IPlayerCallback, public IMs
virtual void Process();
void ProcessSlow();
+ void ProcessSlowEnable(bool enable);
@t4-ravenbird

t4-ravenbird Jan 19, 2013

Contributor

I have discovered that an issue I was struggling with has (re?)occured and seems to be present in current patch. I already made a construct to avoid the problem, but it is not rock-solid it would seem, so I would appreciate some advice from you or anybody else with more overview of the inner workings of Xbmc than myself.

Problem;
-when Gui-thread drives the wakeup we display the progress-dialogue while periodically pinging to see if server gets online.
-to maintain the dialog there is the dialog::Progress() function which does various stuff and also ends up in Application::Process() and Application::ProcessSlow()
-ProcessSlow in turn can also do stuff that does remote MySQL or FileAccess and so there is a recursive situation that breaks the whole thing
-To avoid the situation, I put in a function to disallow execution of ProcessSlow() while waiting for server but apparently there are still cases where this recursive loop happens (I suspect it is in distribution of suspend/wakeup events)

Any advice howto handle this would be appreciated

@elupus

elupus Jan 19, 2013

Member

There can be background jobs accessing disk too. But maybe those are less
problematic.

You probably need to detect the recursion somehow and block until done.

@t4-ravenbird

t4-ravenbird Jan 19, 2013

Contributor

Background jobs are no problem, they dont display the progress-dialog and just sit and wait until ping-response.

I detect the recursion already (just to log it and avoid entering a loop that could overflow the stack) - so there is no crash but the progress-dialog freezes until server is online (which looks bad, off course)
So : effect is achieved (Xbmc wakes server and then proceeds) - problem is the visual feedback hickup

Contributor

t4-ravenbird commented Jan 30, 2013

update;

  • removed 'server already running' notification
  • changed log-messages from level 'info' to 'notice'
  • additional protection to avoid recursive progress-dialog (as I have experienced on my openelec build, still collecting experience on my latest build)

@mcaptur mcaptur referenced this pull request in xbianonpi/xbian Jan 30, 2013

Closed

Add ondemand WOL capability to XBian #239

Member

da-anda commented Feb 8, 2013

is this one ready for prime time now? If so, please rebase.
XBMC devs please check and give green light so it can go in this merge window.

Owner

Memphiz commented Feb 8, 2013

-1 from me for this merge window - i'm not around until monday for this. If @davilla wants to test it for osx/ios then of course this can go in if he made it till close of the merge window. (it needs at least a resync of xcode projects)

Member

kricker commented Feb 8, 2013

There is still one thing that bothers me with this patch. I've discussed it in the past with t4-ravenbird and he wasn't sure how to "fix" it. For some reason it will wake server when you are accessing Add-ons. I don't think it is a big deal, but I find it odd I have to wait for me server to wake up in order to access Add-ons to watch content from the web.

Contributor

t4-ravenbird commented Feb 8, 2013

@da-anda ready or not, I am not sure to be honest. It seems to work fine for windows-users as far as I have heard, but my own openelec-build is giving me concerns. It works as expected when booting and if xbmc as been idle for a while, but when xbmc resumes from suspend I have some observations I dont like. There appears to be various things that kicks in because of the 'OnWake' event .. and I also for some reason get premature ping-response when resuming.
In any case, I will update my repo

@kricker , that observation should be handled separately IMO. The woa feature just helps to reveal that accessing add-ons for some reason causes db-access (probably) and if that is not a justified behavior than it should be addressed.

Contributor

t4-ravenbird commented Feb 8, 2013

Last update also adds a new 'ping'-function by trying connect on specified port
This was suggested in the thread here http://forum.xbmc.org/showthread.php?tid=124340&pid=1316368#pid1316368 and I think it is a good idea and implemented.

Owner

Memphiz commented Feb 8, 2013

Is that last connect osx/ios/android save?

Contributor

t4-ravenbird commented Feb 9, 2013

I merged your original stuff (including proj files) so they might be OK already, can you check it?

Owner

Memphiz commented Feb 9, 2013

Yes they are ok - i've ment the new connect ping stuff - i will try to test next week (am out of town atm).

Contributor

t4-ravenbird commented Feb 9, 2013

OK, yes I hope it builds on all targets (unless there is some diff in fcntl/sockopt/errno codes?)

When will this get merged with mainline?

@ghost

ghost commented Feb 14, 2013

later than initially. we now have to go to yet another puppy funeral. every time one of you guys write these useless messages, one dies, and we have to attend the funeral.

Contributor

t4-ravenbird commented Feb 25, 2013

Seems I have been chasing a ghost when I had issues with stability ; it all boiled down to a misbehaving server that occasionally responded to ping prematurely. It was an xp-machine, after I upgraded to win7 there is no issues at all.

so I combined all my changes into one commit and updated the repo ; it is also rebased

@t4-ravenbird t4-ravenbird and 1 other commented on an outdated diff Feb 25, 2013

xbmc/Application.cpp
@@ -5058,17 +5058,23 @@ void CApplication::Process()
// dispatch the messages generated by python or other threads to the current window
g_windowManager.DispatchThreadMessages();
- // process messages which have to be send to the gui
- // (this can only be done after g_windowManager.Render())
- CApplicationMessenger::Get().ProcessWindowMessages();
+ // only do full processing when m_slowTimer running
@t4-ravenbird

t4-ravenbird Feb 25, 2013

Contributor

the changes here may be controversial ; in the application::process() loop I found it necessary to selectively skip some tasks to avoid recursive attempts at connecting to server.
when gui-thread does something that requires server-connect the progress-dialog is shown while waiting for server to wake. displaying progress-dialog means calling application::process() and so further db or fileshare access must be avoided

@jmarshallnz

jmarshallnz Apr 4, 2013

Member

Yeah, this is going to be a no-go. As I understand it, you really only need this due to the way you have a modal progress dialog and re-entry off the app-thread? Is the only problem an apparently frozen progress, or is there a real issue if this is removed?

@t4-ravenbird

t4-ravenbird Apr 5, 2013

Contributor

yes, this is a problem on app-thread only. the freeze of the dialog is not just apparent, it is very real and blocks the entire thread for as long as the attempted server-connect takes (50secs for samba I think)
Without this section the dialog (entire app actually) will freeze but in best case come to live again.. If you investigate log-file there will be a lot of complaints. In worst case (openelec) it will reboot, my guess is OE maybe has a 'alive'-test somewhere that does a reboot if timeout.
I understand you dont like it, neither do I - but it does not break anything that was not broken allready. With the fix we are able to do some of the mechanics in the function, without it nothing at all gets done.
*
Another approach may be to hunt down and rewrite all 'offenders' , that is ; any piece of code that (on app-thread) does DB or file-share access? But that task seems overwhelming to me..

@jmarshallnz

jmarshallnz Apr 5, 2013

Member

Can't you just always make sure when you're blocking on app thread that you keep processing? i.e. if on app loop you need to make sure you spin a while loop, calling the app process loop. If you get re-entry, then you'll just be spinning on the inner loop, and once that exits, the outer loop will also exit, right?

@t4-ravenbird

t4-ravenbird Apr 5, 2013

Contributor

When the problem first arose it gave full recursiveness, ie ; if I kept processing it came back again every time so it led to stack overflow.
However, you set me onto something ; Maybe the problem was that some of those dispatchers is using a sequence of 'first call, then remove' on the jobs/messages it dispatches? In that case it is clear that recursiveness would spin out of control (same job woulb be re-dispatched upon next process())
I will try your approach and see if I can tweak any dispatchers into doing 'pop job first, then call it'

@t4-ravenbird

t4-ravenbird Apr 9, 2013

Contributor

I believe I found the root (atleast one) ; CPowerManager::OnSleep/OnResume can get called in re-entry, at least on some targets ; ref https://github.com/xbmc/xbmc/blob/master/xbmc/powermanagement/osx/CocoaPowerSyscall.cpp#L234
https://github.com/xbmc/xbmc/blob/master/xbmc/powermanagement/windows/Win32PowerSyscall.cpp#L82
(unsure about other targets)
*
Now I can think of a few ways to fix this;

  1. as you suggested, redo WakeOnAccess::ProgressDialog-display to handle re-entrancy. There is a drawback here ; implementation gets complicated! (and OnWake/OnResume still gets fired recursive which may be problematic by itself)
  2. fix setting of "m_OnSuspend/m_OnResume" variables in files listed above.. drawback : will we get all?
  3. detect & handle nesting here ; https://github.com/xbmc/xbmc/blob/master/xbmc/powermanagement/PowerManager.cpp#L217

I prefer 3) - what is your thoughts?

@jmarshallnz

jmarshallnz Apr 10, 2013

Member

Well, I think as you point out those functions should be able to handle re-entrancy. By moving the setting of m_OnSuspend you avoid callback->OnSleep() being executed twice for example.

But I should think that your code that you add should also be able to handle re-entrancy. It seems the idea is quite simple:

  1. The ping/wake to the network server has to be waited on (plus any bringing up of the network) so the function needs to be blocking.
  2. The app thread loop should still be processed periodically to both display a progress bar to the user, and also to allow messages etc. to be processed as required.

Thus, if on app thread, you need to spin a while loop, periodically running the app loop. If not on app thread you can just wait on a condition. This type of handling is done in CDirectory::GetDirectory() and elsewhere. I'm not sure why this wouldn't work in this case. You could well get some sort of deadlock I guess, where app thread is waiting on some other thread/critical section which is waiting on your ping/wake event. In that case it's a problem with that thread holding a critical section while doing something that takes time, not your code, however.

@t4-ravenbird

t4-ravenbird Apr 10, 2013

Contributor

Yes, that pretty much describes it - and it is also how it actually is made. There is the while-loop like CDirectory::GetDirectory() , only difference is there are multiple steps.
But I suspect CDirectory::GetDirectory() would also get into trouble if (for some reason) it got called re-entrantly when doing ProcessRenderLoop() with a request to open same directory again. As I read the code it would bring up yet a new Dialog as opposed to render the first that was shown? That is the situation wakeOnAccess ran into.
(I will update PR with changes based on review so far)

@jmarshallnz

jmarshallnz Apr 10, 2013

Member

There is only one instance of CGUIDialogBusy and CGUIDialogProgress, so you
can't get two of 'em up. As the second entry is the app loop, it'll be
pretty much similar to first entry except that the dialog is already on
screen, so the StartModal() call (or the Show method on busy) will
basically be a noop, then the Progress() calls will run the rest of the app
loop.

Perhaps the problem is continual re-entry, causing stack overflow?

On Wed, Apr 10, 2013 at 6:56 PM, t4-ravenbird notifications@github.comwrote:

In xbmc/Application.cpp:

@@ -5058,17 +5058,23 @@ void CApplication::Process()
// dispatch the messages generated by python or other threads to the current window
g_windowManager.DispatchThreadMessages();

  • // process messages which have to be send to the gui
  • // (this can only be done after g_windowManager.Render())
  • CApplicationMessenger::Get().ProcessWindowMessages();
  • // only do full processing when m_slowTimer running

Yes, that pretty much describes it - and it is also how it actually is
made. There is the while-loop like CDirectory::GetDirectory() , only
difference is there are multiple steps.
But I suspect CDirectory::GetDirectory() would also get into trouble if
(for some reason) it got called re-entrantly when doing ProcessRenderLoop()
with a request to open same directory again. As I read the code it would
bring up yet a new Dialog as opposed to render the first that was shown?
That is the situation wakeOnAccess ran into.
(I will update PR with changes based on review so far)


Reply to this email directly or view it on GitHubhttps://github.com/xbmc/xbmc/pull/1892/files#r3728399
.

@t4-ravenbird

t4-ravenbird Apr 11, 2013

Contributor

I think you are spot on - but I also think that this scenario might give the impression of "looping" progress-dialog(s) because of the flickering

@t4-ravenbird t4-ravenbird commented on the diff Feb 25, 2013

xbmc/main/main.cpp
@@ -66,13 +66,6 @@ int main(int argc, char* argv[])
if (setrlimit(RLIMIT_CORE, &rlim) == -1)
CLog::Log(LOGDEBUG, "Failed to set core size limit (%s)", strerror(errno));
#endif
- // Prevent child processes from becoming zombies on exit if not waited upon. See also Util::Command
@t4-ravenbird

t4-ravenbird Feb 25, 2013

Contributor

'ping' on *nix is implemented by doing a "int result = system("ping host") ;" ..
I had to remove this sigaction tweak to get the response from the call ..

Owner

Memphiz commented Feb 25, 2013

Someone should implement a true ping for nix ... calling system is nothing we want to do for sure!

Contributor

t4-ravenbird commented Feb 25, 2013

true ping would certainly be better but requires root AFAIK so that is why I made it like this.
I assume you dont like the overhead (or is there something else wrong with system()?) but code using ping() must in any case be prepared that it is blocking for a while

Owner

Memphiz commented Feb 25, 2013

nvm - just forget what i said ;)

Member

kricker commented Mar 8, 2013

So we appeared to have stalled out again on the PR. What can we do to move this forward again? Has Androis and OS X been tested yet?
If we could somehow get the PVR Power saving integrated into this, I think it would be full featured and ready to merge. It seems silly to have PVR with its own wake settings.

Contributor

t4-ravenbird commented Apr 4, 2013

I just updated to match latest changes (some settings have been shuffled around a bit that affected this PR)
There is only 1 commit, but parts of that is (still) thanks to @pieh and @Memphiz

Please have a look and let me know if something should be changed or anything else I can do to make it ready to be merged

@jmarshallnz jmarshallnz and 1 other commented on an outdated diff Apr 4, 2013

xbmc/network/WakeOnAccess.cpp
+ ULONG dst_ip = HostToIP(m_server.host);
+
+ return g_application.getNetwork().PingHost(dst_ip, m_server.ping_port, 2000, m_server.ping_mode & 1);
+ }
+
+private:
+ class CHostProberJob : public CJob
+ {
+ public:
+ CHostProberJob(const PingResponseWaiter* parent) : m_parent (parent) {}
+
+ virtual bool DoWork()
+ {
+ while (!ShouldCancel(0,0))
+ {
+ if (m_parent->Ping())
@jmarshallnz

jmarshallnz Apr 4, 2013

Member

This is problematic - the parent could be removed between the check for cancellation and the pointer deference. It's better to pass in the material you need to the job rather than assuming that the callback will be there.

@t4-ravenbird

t4-ravenbird Apr 5, 2013

Contributor

Ouch, indeed.. will do

Member

theuni commented Apr 5, 2013

Echoing what @Memphiz said above.

Please don't use system() for ping, but implement an actual ping. If root is required, then it will be required to spawn/use the program too, so I'm not following your logic there.

This probably won't work on android (if it does, it will be hit or miss), and ping is not guaranteed to exist on embedded systems. Please track down a simple implementation (c/p from busybox should work i'd think) and use it instead.

Contributor

t4-ravenbird commented Apr 5, 2013

@theuni OK, will investigate busybox. Regarding spawning it works since the 'ping' command has some special permissions if i recall correctly

Contributor

t4-ravenbird commented Apr 9, 2013

Some links on ping ;
http://stackoverflow.com/questions/1189389/python-non-privileged-icmp
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man4/icmp.4.html
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/Xnc8c3A3OLw

As I understand it ;

  • ping requires opening a socket in raw mode ; socket (AF_INET, SOCK_RAW, IPPROTO_ICMP)
  • opening socket in raw mode requires root
  • ping utility (and busybox) is installed with permissions to "auto-switch to root" if started by non-root user and are therefore able to get the job done.
  • for DARWIN it is explicitly permitted to do ; socket (AF_INET, SOCK_DGRAM, IPPROTO_ICMP) to get around the problem and be able to do a non-root icmp ping
  • it is unclear if Linux supports the same and for which versions/distributions ; Android fails according to discussion on google above.

I checked my old Android-phone (v 2.3.7) and it has 'ping' utility on it (but phone is rooted and running MIUI so I dont know what its worth)

I think using "system("ping")" is the approach with the best chance of getting it to work on most targets ; and if it does not work this patch also adds a "ping by tcp-connect" feature that can be used, check https://github.com/xbmc/xbmc/pull/1892/files#L13R358

Contributor

t4-ravenbird commented Apr 10, 2013

Updated PR and

My private machines (openelec) are running this and behaving well so far

Contributor

t4-ravenbird commented Apr 11, 2013

The pointer dereference issue made me check again and I realized that after merging with changed handling of settings-files (and inheriting ISettingsHandler) protection is needed for the list of wake-up-servers, so latest commit adds that

Contributor

t4-ravenbird commented Apr 18, 2013

@jmarshallnz Thanks for your input on this PR. After I changed the protection against reentry as discussed above it has run without faults so is looking OK. If you have the time please have a new look and let me know if there is anything more I should look at or if it can be queued for merge?

@MartijnKaijser MartijnKaijser commented on an outdated diff Apr 18, 2013

language/English/strings.po
@@ -4534,7 +4534,51 @@ msgctxt "#13025"
msgid "Joystick unplugged"
msgstr ""
-#empty strings from id 13026 to 13049
+msgctxt "#13026"
@MartijnKaijser

MartijnKaijser Apr 18, 2013

Owner

please add the file locations where the strings are used. You can see examples in the strings.po how it's done

@MartijnKaijser MartijnKaijser and 1 other commented on an outdated diff Apr 18, 2013

xbmc/network/WakeOnAccess.cpp
@@ -0,0 +1,758 @@
+/*
+ * Copyright (C) 2005-2013 Team XBMC
@garbear

garbear Apr 18, 2013

Member

Technically, code in this file is arguably derived from XBMC code elsewhere, so it would be appropriate to keep this date range.

@MartijnKaijser MartijnKaijser commented on an outdated diff Apr 18, 2013

xbmc/network/WakeOnAccess.h
@@ -0,0 +1,82 @@
+/*
+ * Copyright (C) 2005-2013 Team XBMC
Contributor

t4-ravenbird commented Apr 18, 2013

@MartijnKaijser Done. @garbear I checked other recently added files and they are stamped only 2013 so I stick to that too

Contributor

t4-ravenbird commented May 2, 2013

Updated for refactored settings system.

Member

da-anda commented May 4, 2013

I noticed that if my NAS didn't wake up in time (and not even in "extra time") and WOL is aborted, I'm not able to play the movie or anything else from that share even after my NAS is finally up. I have to exit and reenter the current view/folder in order to finally play it. Is it related to code of this PR or some temporary flag XBMC core is setting for a file/share? I'm on windows.

Member

kricker commented May 4, 2013

I'm pretty sure that is core XBMC code. Since your server did not wake in time XBMC thinks the item is missing and will not play it.

Contributor

t4-ravenbird commented May 5, 2013

I think it is windows networking that flags a share as unavailable for a while after a failed connection attempt. I think you could make a similar observation connecting a share using windows explorer.

Contributor

t4-ravenbird commented May 6, 2013

Any chance this can be merged in this window? What is missing or wrong, as far as I know I have resolved all findings that has been pointed out and I am still ready to amend whatever is preventing it from going in

Member

da-anda commented May 9, 2013

could you please rebase again @t4-ravenbird ? I try to convice devs to hit the green button :)

Contributor

t4-ravenbird commented May 9, 2013

@da-anda rebased .. and thanks for your involvement! and thanks to @Memphiz for darwin port, I hope I managed to merge that work correctly (there has been many iterations but hopefully it did not break on the way)

Member

da-anda commented May 10, 2013

Thanks @t4-ravenbird. @Memphiz or any other mac user - could you please check if it still compiles and is working?

@t4-ravenbird can you explain why this had to go?

Member

FernetMenta replied May 11, 2013

I don't think this can be removed without other handling of zombie processes: FernetMenta/xbmc@89c2fab

Forgot to mention: removing those lines fixes hang with Nvidia driver 319.17

Member

FernetMenta replied May 11, 2013

@bobo1on1 this might also be the cause for the hang in video ref clock when calling nvdia-settings.

Contributor

t4-ravenbird commented May 10, 2013

@da-anda had to go in order to get response from system("ping")
result from the system() call would fail always when SA_NOCLDWAIT was installed (might differ between distributions)

edit : i think this is same issue ; http://stackoverflow.com/questions/11084959/system-always-returns-non-zero-when-called-as-cgi
and this http://compgroups.net/comp.unix.programmer/system-fails-with-errno-echild/536132

Member

da-anda commented May 10, 2013

@t4-ravenbird I unfortunately can't find a OSX tester. I did a test-compile via Jenkins (link in according form topic), so compile seems fine, but function test is missing. We still have a couple of hours, but chances are that it (again) might not make it into this merge window - sorry.

regnets commented May 10, 2013

I'm not a developer, but i got a working macbook and willing to test the pr. Where can i find the compiled binary?

Contributor

t4-ravenbird commented May 10, 2013

@da-anda well you have in any case done a great job, maybe now if it misses this window it could be 'staged' to go into next at least?

@regnets http://forum.xbmc.org/showthread.php?tid=124340&pid=1417537#pid1417537

@da-anda da-anda pushed a commit that referenced this pull request May 10, 2013

da-anda Merge pull request #1892 from t4-ravenbird/master
Wake On Access (woa) - 'Just in time' WOL when accessing MySQL or FileShare Server
2e96671

@da-anda da-anda merged commit 2e96671 into xbmc:master May 10, 2013

@Karlson2k Karlson2k commented on the diff May 11, 2013

xbmc/powermanagement/PowerManager.cpp
@@ -216,7 +216,12 @@ int CPowerManager::BatteryLevel()
}
void CPowerManager::ProcessEvents()
{
- m_instance->PumpPowerEvents(this);
+ static int nesting = 0;
@Karlson2k

Karlson2k May 11, 2013

Member

Are you trying to avoid race conditions?
Don't you need 'volatile' and 'AtomicIncrement/AtomicDecrement'?

@t4-ravenbird

t4-ravenbird May 11, 2013

Contributor

No, avoid re-entrance. Function is only called on gui-thread so threading-protection not needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment