I tested this package with my wd elements external hdd, on the USB3.0, it works good.
I also tested it on my RaspberryPi, the same result.
Thanks for this useful post.
I installed the deb package by the command dpkg -i …/hd-idle_*.deb
and started it up after editing /etc/default/hd-idle file and by isueing the command /etc/init.d/hd-idle start
Result showed OK and I could see the process ID when listing processes.
However, it doesn’t seem to work, because my hdd doesn’t spin down after the specified minutes of inactivity. (Waited for longer time after turning off all access to the device to make sure no application is accessing files)
This is the content of my /etc/default/hd-idle file:
I have a 4TB drive with the same issue and I logged a ticket with WD Support (although I only hear from my “assigned” support person about once every 2 weeks so any progress resolving the issue is very slow).
I had some partial success after the support person suggested, as a test, that I disable the DLNA Media server and Remote access options in the web dashboard. After about 20 mins the unit did go into standby mode (the front LED changed from a static blue to a slow, pulsating blue and the drive spinning noise was absent). Then, when I accessed the drive again via the WD dashboard, everything fired up and the LED returned to a static blue.
Next I re-enabled the DLNA Media server in the dashboard settings but left the Remote access option disabled (as this functionality is less important to me than being able to stream media to my TV). The drive went into standby mode after a period of inactivity.
However, since then its returned to not working despite still having retained the same dashboard settings. So, I’m at a loss as to what the issue actually is and I await the next suggestion from WD Support but I’d be interested if anyone else gets similiar (or better!) results.
Does WD have a fix for this bug? Is a fix planned? The drive should definitely stop spinning after a period without any read/write activity. That’s a very serious bug, unnecessarily damaging the reputation of an otherwise excellent company.
I have received this further suggestion from the WD Support rep I have been dealing with:
“Please set the rescan interval of the Twonky server to 0.
Therefore, please enter //192.168.0.x:9000 into the address bar of a browser (Internet Explorer, Firefox, Chrome, etc.). This will open the Twonky setup page.
On the setup page, please click on Setting → Advanced → and enter in the Rescan Interval the value 0. Save the setting and restart the My Cloud.”
I have applied this setting this morning (without rebooting the device) and it did enable the device to enter standby mode after 10 minutes. I then went to seach the contents of the device through the Windows Explorer view and this action brought it back online (as you’d expect). Then, after 10 minutes of not accessing the device, it went into standby mode again. So, this setting change appears to have had the desired outcome but I will monitor if this is a permanent resolution.
I believe the possible downside to making this change however is that the content of the My Cloud device won’t be continually re-scanned and therefore changes, such as adding new share folders, won’t automatically be picked up and so you’ll have to perform a manual scan through the WD dashboard website after you’ve made any changes. I will have to test if new media files being added to existing share folders on the device are detected automatically by my media streamer (Boxee Box) with this rescan interval set to zero. I’ll aim to post an update on my findings within the next week.
I received a notification this morning from my WD My Cloud that a firmware upgrade was available. So I upgraded from v03.03.01-156 to v03.03.02-165. The upgrade went flawlessly, so thank you Western Digital!
The release notes on v03.03.02-165 did not say anything about fixing the failure to spin-down. However, over the next day or so I expect I will be able to see if the My Cloud log shows longer sleep periods than before. SSH commands:
cd /usr/log
cat user.log
As I do NOT want remote access to My Cloud (using it only as a Network Accessible Server on LANs), I again disabled all the processes that index media files and make thumbnails. Those processes were causing 24x7 thrashing of the disk drive (lots of new image files are uploaded each day). SSH commands:
Do you think that convert still would be started even when you disable the other two?
Does twonky itself also start convert?
Thx
To be honest, I don’t even know what Twonky is. But since I am disabling the execute permissions of ‘convert’, as opposed to just stopping the process, I assume that nothing can start it. Am I right?
Alastair_Gordon wrote: To be honest, I don’t even know what Twonky is. But since I am disabling the execute permissions of ‘convert’, as opposed to just stopping the process, I assume that nothing can start it. Am I right?
Yes and No.
Things with no execute permissions can still be executed from a wrapper.
In other words doing this:
./execute_this
won’t work if execute this isn’t executeable.
But
sh ./execute_this
will still work regardless of permissions if ran from root.
Alastair_Gordon wrote: To be honest, I don’t even know what Twonky is. But since I am disabling the execute permissions of ‘convert’, as opposed to just stopping the process, I assume that nothing can start it. Am I right?
Yes and No.
Things with no execute permissions can still be executed from a wrapper.
In other words doing this:
./execute_this
won’t work if execute this isn’t executable.
But
sh ./execute_this
will still work regardless of permissions if ran from root.
So it just depends on how “convert” is invoked.
True, but when I used to check for running processes using SSH ‘top’, I always saw wdmcserver, wdphotodbmerger, and convert running almost all the time, and the disk endlessly thrashing 24x7. After I did
those processes disappeared, and the disk thrashing stopped.
However, the failure to remain spun down even during long idle periods persists, a much less destructive problem than the 24x7 thrashing caused by indexing new content and generating new thumbnails.