Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So I'm a new to the wake on LAN functionality of MC/Gizmo, and it's working pretty well for me so far, but I'm having trouble with one piece of it.  

My network is setup with a central server PC and two client PCs, all running the latest version of MC.  The media network portion of my experience works flawlessly, both clients can see and play what's on the server PC with no problems.  In addition to basic media network functionality, I have the server setup as a DLNA controller, and both clients setup as DLNA renderers.  This allows me to play to the clients from the central server PC, and also to play to either of the clients through Gizmo (which is logged into the server PC's library, just like the clients).  

When the server goes to sleep, both clients seem to have no problem waking it up, and Gizmo has no problem waking it up.  When dealing with the server wake on LAN seems to "just work."  

However, I've been having trouble getting wake on LAN to work on the clients.  Tonight, for example, one of my client PCs was sleeping, and I tried to play to it from Gizmo, but no dice.  When I manually woke it up, Gizmo had no problem playing to it, but I couldn't get Gizmo to wake it up no matter what combination of firewall/port settings I tried.  All three computers are on the same home network router, and the device I'm using Gizmo on is connected to the same router using Wi Fi.

I'm wondering, is it because I'm trying to control the client through DLNA?  The forum posts I found on the subject seemed equivocal.  Have other people gotten this kind of setup to work with wake on LAN?  If so, I'll keep plugging away in my router settings, etc., but I wanted to make sure that wake on LAN was supported through DLNA before I spent too much more time on it.

[jmone]

I'm only guessing (not tried) but can you wake these PC's from other progs (like remote desktop)?  Also check your NIC's Properties and make sure "Wake on...." options are enabled.

[AndrewFG]

^

AFAIK MC does not push WOL packets to UPNP/DLNA renderers. However, I don't think there is any real reason to prevent such a feature being added.

[mwillems]

^

AFAIK MC does not push WOL packets to UPNP/DLNA renderers. However, I don't think there is any real reason to prevent such a feature being added.

That's what I was afraid of; there was a thread (that you were in) from a few years ago that seemed to suggest that Gizmo might have that functionality, but the core program might not, but I may be misreading that:

http://yabb.jriver.com/interact/index.php?topic=75187

So assuming wake on LAN over DLNA isn't currently an option, does anyone have any recommendations for using Gizmo as a control point for multiple computers all of which may be asleep at some point?  I guess I can just turn off sleeping, but one of these computers is an energy hog and I'd like for it to sleep when not in use.

I'm only guessing (not tried) but can you wake these PC's from other progs (like remote desktop)?  Also check your NIC's Properties and make sure "Wake on...." options are enabled.

I don't normally use remote desktop, so I don't know, but that's a good troubleshooting step. I'll check on both of those things and report back later on.

[mwillems]

Ok, Jmone I checked on your two points; the NIC settings are set to enable "Wake on LAN."  Unfortunately, the machine is running the "Home" edition of windows 7 (bought in an era when I didn't do home networking), which means it doesn't actually support remote desktop log ins.  

What I did do is try to log into the client computer as though it were a server, which is to say I fed Gizmo it's access key, and tried to see if I could get it to wake on LAN in the normal way.  And that didn't work, so I guess that means that even if Gizmo were sending a WOL packet over DLNA, the computer isn't receiving it.  It's a laptop, and on further investigation, it seems as though it may be turning it's wireless connectivity completely off when it's sleeping (even though I thought I configured it not to do that).  I'll try it wired and see if I can get it working that way.  Thanks for the help folks.

[AndrewFG]

So assuming wake on LAN over DLNA isn't currently an option, does anyone have any recommendations for using Gizmo as a control point for multiple computers all of which may be asleep at some point?

I think we might take this conversation over to the beta board ?? It probably needs some more detailed thought about architecture and failure modes, but in principle I think the mechanism could potentially be made to work in MC roughly as follows:

When a UPnP renderer comes online (including when it wakes up from sleep) it must send an SSDP ALIVE broadcast, and when it goes offline (including when it goes to sleep) it must send an SSDP BYEBYE broadcast. The MC UPnP server tracks these Alive and ByeBye messages, and adds or removes the respective renderer from its list of players. So the entries in the list dynamically come and go depending on who is Alive.

In order to handle a sleep plus WOL mechanism, MC would need to track three states of renderers:

1. Alive
2. Gone ByeBye, presumed sleeping
3. Gone ByeBye, really gone...

Imagine MC showing those "presumed sleeping" renderers as grayed out. And if the user in MC were to select Play To such a grayed Renderer, then MC would first send a WOL packet to that device's last known IP address. And if the respective renderer were then to come Alive, MC would un-gray the renderer, and send the UPnP play commands to it. But if the renderer did not come alive in response to the WOL packet, then MC would consider it as really gone and would delete the grayed device entirely from its list of renderers.

The same logic would also be used when controlling via Gizmo. In that case Gizmo first sends a WOL packet to wake the MC Server itself. And later when Gizmo sends a Play command to MC to play to one of the attached presumed sleeping renderers, this would trigger the now awake MC to send another WOL packet to the respective presumed sleeping renderer.

[mwillems]

I think we might take this conversation over to the beta board ?? It probably needs some more detailed thought about architecture and failure modes, but in principle I think the mechanism could potentially be made to work in MC roughly as follows:

When a UPnP renderer comes online (including when it wakes up from sleep) it must send an SSDP ALIVE broadcast, and when it goes offline (including when it goes to sleep) it must send an SSDP BYEBYE broadcast. The MC UPnP server tracks these Alive and ByeBye messages, and adds or removes the respective renderer from its list of players. So the entries in the list dynamically come and go depending on who is Alive.

In order to handle a sleep plus WOL mechanism, MC would need to track three states of renderers:

1. Alive
2. Gone ByeBye, presumed sleeping
3. Gone ByeBye, really gone...

Imagine MC showing those "presumed sleeping" renderers as grayed out. And if the user in MC were to select Play To such a grayed Renderer, then MC would first send a WOL packet to that device's last known IP address. And if the respective renderer were then to come Alive, MC would un-gray the renderer, and send the UPnP play commands to it. But if the renderer did not come alive in response to the WOL packet, then MC would consider it as really gone and would delete the grayed device entirely from its list of renderers.

The same logic would also be used when controlling via Gizmo. In that case Gizmo first sends a WOL packet to wake the MC Server itself. And later when Gizmo sends a Play command to MC to play to one of the attached presumed sleeping renderers, this would trigger the now awake MC to send another WOL packet to the respective presumed sleeping renderer.

That's interesting, because when my clients go to sleep, they remain available as zones to playback to (both in MC and in Gizmo).  The playback just fails when attempted.  To be fair, I've mostly been testing within a few minutes of sleeping.  They may well properly disappear in due time.  That was why it wasn't immediately obvious to me that this wake on LAN over DLNA wasn't supported in MC; if my client zones vanished as soon as they went to sleep, I'd have probably figured it out  

What you're describing sounds like a good fix to me, but I was mostly asking if anyone had any workarounds using MC's existing functionality.  It sounds like it's not really possible as is, which is a-ok.  I'll just need to rethink how I'm going to structure my media server setup for the time being.

[connersw]

In addition to basic media network functionality, I have the server setup as a DLNA controller, and both clients setup as DLNA renderers.  This allows me to play to the clients from the central server PC, and also to play to either of the clients through Gizmo (which is logged into the server PC's library, just like the clients). 

When the server goes to sleep, both clients seem to have no problem waking it up, and Gizmo has no problem waking it up.  When dealing with the server wake on LAN seems to "just work." 

When you say "Gizmo (which is logged into the server PC's library, just like the clients)" does that mean you are not logging into the server for each Client PC on Gizmo when you control it?  You should have an access key for each PC loaded into Gizmo, and then load that server when you play to it.  It's a little confusing in terminology since you're still playing the Library from the Server PC. 

If you are not using Gizmo that way, that might solve your WOL issues from Gizmo.  Unless there is a reason you are using DLNA (ie you want to do conversion and have the Server PC do the work).  Or maybe I didn't understand you correctly.

The other topic is still a good one though since it would be a nice feature to wake by pushing from the Server PC. 

[mwillems]

When you say "Gizmo (which is logged into the server PC's library, just like the clients)" does that mean you are not logging into the server for each Client PC on Gizmo when you control it?  You should have an access key for each PC loaded into Gizmo, and then load that server when you play to it.  It's a little confusing in terminology since you're still playing the Library from the Server PC.  

Yes, you're correct, I am not logging into the server for each client PC on Gizmo when I control it.  Instead I'm controlling the clients through DLNA from the server with Gizmo logged into the server's library.  

If you are not using Gizmo that way, that might solve your WOL issues from Gizmo.  Unless there is a reason you are using DLNA (ie you want to do conversion and have the Server PC do the work).  Or maybe I didn't understand you correctly.

That would solve my wake on LAN problem, most likely, but wouldn't be much good to me with the way my current system is configured.  All of my media is on the main server, imported into the main server's library.  I don't maintain multiple parallel libraries; which is to say that each of my client PCs logs directly into the server's library on startup.  Logging in to the clients with Gizmo using the clients' access keys just logs me into the clients' local libraries, but those local libraries are completely empty.  So logging into the local library on each client with Gizmo would solve my wake on LAN problem, but I would have nothing to play with my current configuration.  Unless I'm missing something critical or you're suggesting something else (some kind of pull-based DLNA setup)?

In part, that's what I meant by exploring other network configuration options.  I could set them up so each client has a separate library that sees a shared drive on the server, effectively bypassing MCs server/client system.  But I really like the current server/client system because for most of my uses it's really frictionless: no fiddling around with multiple libraries, no manual updating or periodic syncing, etc.  I can even control all three PCs easily through Gizmo, provided, of course, they're all awake

I'm a dope, you just solved my problem for me    Everything works as expected when I use gizmo to log into the client's server directly (I was under the mistaken impression that logging in that way would only load the client's local library).

Big thanks!

To close the other loop, I did need to plug the computer into the router directly though, I still haven't gotten wake over LAN using Wi-Fi to work, but that's a networking problem, not an MC problem.

The other topic is still a good one though since it would be a nice feature to wake by pushing from the Server PC.  

I agree, but it seems like it might be a tall order.

[bob]

Yes, you're correct, I am not logging into the server for each client PC on Gizmo when I control it.  Instead I'm controlling the clients through DLNA from the server with Gizmo logged into the server's library.  

That would solve my wake on LAN problem, most likely, but wouldn't be much good to me with the way my current system is configured.  All of my media is on the main server, imported into the main server's library.  I don't maintain multiple parallel libraries; which is to say that each of my client PCs logs directly into the server's library on startup.  Logging in to the clients with Gizmo using the clients' access keys just logs me into the clients' local libraries, but those local libraries are completely empty.  So logging into the local library on each client with Gizmo would solve my wake on LAN problem, but I would have nothing to play with my current configuration.  Unless I'm missing something critical or you're suggesting something else (some kind of pull-based DLNA setup)?

In part, that's what I meant by exploring other network configuration options.  I could set them up so each client has a separate library that sees a shared drive on the server, effectively bypassing MCs server/client system.  But I really like the current server/client system because for most of my uses it's really frictionless: no fiddling around with multiple libraries, no manual updating or periodic syncing, etc.  I can even control all three PCs easily through Gizmo, provided, of course, they're all awake

I'm a dope, you just solved my problem for me    Everything works as expected when I use gizmo to log into the client's server directly (I was under the mistaken impression that logging in that way would only load the client's local library).

Big thanks!

To close the other loop, I did need to plug the computer into the router directly though, I still haven't gotten wake over LAN using Wi-Fi to work, but that's a networking problem, not an MC problem.

I agree, but it seems like it might be a tall order.

I do like the three state idea.
I did test some renderer devices that went into a power sleep mode for response to WOL packets (they didn't) however some may and MC renderers certainly would.

[AndrewFG]

That's interesting, because when my clients go to sleep, they remain available as zones to playback to (both in MC and in Gizmo).  The playback just fails when attempted.  To be fair, I've mostly been testing within a few minutes of sleeping.  They may well properly disappear in due time.  That was why it wasn't immediately obvious to me that this wake on LAN over DLNA wasn't supported in MC; if my client zones vanished as soon as they went to sleep, I'd have probably figured it out  

Your clients are not properly sending their ByeBye notifications when they (are about to) go to sleep. (Many renderers and servers forget to send their ByeByes). The reason why your clients do nevertheless eventually disappear is that each Alive notification has a time validity. And if no new Alive notification comes in before the previous Alive validity expires, the device will eventually be considered to have gone offline. This behaviour (not sending your ByeByes) is not compliant to the specification, but it does somehow still work...

[jmone]

Unfortunately, the machine is running the "Home" edition of windows 7 (bought in an era when I didn't do home networking), which means it doesn't actually support remote desktop log ins.

Sounds like you have it sorted by FYI, if you want to test WOL is working, there are heaps of utils to do this, eg - for Andriod : https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=en