I’m running a 2GB MBL with firmware 02.32.05-044 that has worked great for the last 6 months and spent most of its time asleep (as it should since it is infrequently accessed redundant backup storage).
I installed wd2go on an iPad3, an older iPod Touch, and a Blackberry Bold 9780 (yes all in the same day, I wasn’t thinking of debugging issues because wd2go was working so well…) and now my MBL remains awake, will not go to sleep, enter energy save mode, hibernate, or whatever other lingo you want to call it.
On my MBL’s web interface, “Mobile Access” was enabled (I’m pretty sure it was disabled previously) and all three devices were listed with a status of “connected” (after having some fun figuring out the activation code for the BB which activation was completely seamless on the Apple devices).
Since installing wd2go, I haven’t seen any other status for these mobile devices despite all efforts to turn off wd2go on them and despite powering off these devices. As nothing else in my network has changed, I suspect that any of enabling “mobile access” or the permanent “connected” status of my devices or both is what is keeping my MBL from going back to sleep.
To be sure it’s not a settings issue, I disabled then re-enabled the sleep feature.
Please let me know if you have any experience with this problem (or a related one) to help me debug and resolve this issue.
I’ll update with details of what I’ve tried to do to resolve this later.
I disabled all wireless connections on all three devices (airplane mode for iPad & iPod, disable all connections for BB) then turned them all off. Two hours have passed and the MBL still isn’t going to sleep when it normally would. Powered off with all wireless disabled, there’s no way those devices are transmitting to the MBL (they’d be in violation of many aviation laws).
I disabled Remote Access from the MBL web interface to see if I can get the MBL back to normal (still waiting on the sleep time…)
The “status” of the mobile devices remain “connected” despire Remote Access being disables. Somebody at WD needs to figure that one out… Perhaps “connected” is the wrong word and it should say “activated” or “linked” to indicate access code authentication has been completed and so as not to suggest the mobile device is in communication with the MBL. Maybe just remove the word altogether…
If my MBL goes to sleep again like it should, I’ll uninstall wd2go from all devices, re-enable Mobile Access, disassociate all connected devices and see if the MBL goes to sleep with Mobile Access on, but no devices authenticated.
If that’s successful, I’ll install and connect wd2go on one device to debug further.
Grand plans, but I’m not hopeful… I’ve had more than one run around the NAS block.
I disabled Remote Access from the MBL web interface to see if I can get the MBL back to normal (still waiting on the sleep time…)
My MBL went back to sleep right on queue.
rplatham wrote:
If my MBL goes to sleep again like it should, I’ll uninstall wd2go from all devices, re-enable Mobile Access, disassociate all connected devices and see if the MBL goes to sleep with Mobile Access on, but no devices authenticated.
Uninstalling wd2go from the devices was uneventful. However, when I re-enabled remote access on the MBL web interface, it appears that the wd2go server forces a rebuild of its database. Too bad the MBL can’t tell there hasn’t been a single file change since Remote Access was last disabled… (it wouldn’t DELETE that database when I disabled Remote Access would it?) [Edit: A scheduled Win7 backup started close to the time I re-enabled Remote Access, thus I can’t conclusively say that reactivating Remote Access caused the activity or that the activity could be rebuilding the database…]
The rebuild [backup] will take a while before I can see if the MBL goes to sleep with Remote Access enabled, but not authenticated device (and no devices with wd2go installed)…
