Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hi,
I'm having a problem with drive spindown on my DNS-323 running the latest v1.09 firmware from D-Link. Ever since I installed ffp v0.5 and Twonky v6.0.30, my hard drives no longer spin down after the configured 60-minute interval. There seems to be some process accessing the disk every few minutes or so even with the LAN cable unplugged.
I'm aware of the printer queue issue but I've never used the print server functionality. It's either ffp, twonky, or both. I've set twonky to update the media library every 1440 minutes (24 hours).
Any fixes?
Thanks
cinergi
Last edited by cinergi (2011-01-02 20:29:13)
Offline
cinergi wrote:
Hi,
I'm having a problem with drive spindown on my DNS-323 running the latest v1.09 firmware from D-Link. Ever since I installed ffp v0.5 and Twonky v6.0.30, my hard drives no longer spin down after the configured 60-minute interval. There seems to be some process accessing the disk every few minutes or so even with the LAN cable unplugged.
I'm aware of the printer queue issue but I've never used the print server functionality. It's either ffp, twonky, or both. I've set twonky to update the media library every 1440 minutes (24 hours).
Any fixes?
Thanks
cinergi
install ffp and twonky on a usb stick and spindown will work again
Offline
usb stick solution is a bit radical...
First find out what it is that is accessing the disks and preventing them from spinning down. Do you have any script running periodically? If the script is on the harddisks that will prevent them from spinning down. One possible solution is to make the script copy itself to the ramdisk on boot and then run from there. But before thinking about that you need to find out what it is that's accessing the disks...
Offline
bgravato wrote:
usb stick solution is a bit radical...
First find out what it is that is accessing the disks and preventing them from spinning down. Do you have any script running periodically? If the script is on the harddisks that will prevent them from spinning down. One possible solution is to make the script copy itself to the ramdisk on boot and then run from there. But before thinking about that you need to find out what it is that's accessing the disks...
Thanks! How would I find out what is accessing the disks? My Linux skills are somewhat limited.
-cinergi
Offline
First thing I would do is start the NAS without starting twonky and then see if the disks spin down. Twonky seems to be the most likely cause.
If the disks spin down without twonky running, then you would need to figure out if twonky can be configured to run so that it does not access the disks when idle. (Obviously there will be disk accesses when it serves up media.)
I noted in the howto on this site that there is a recommendation to modify the starttwonky.sh file to move the log and "appdata" files off of the ramdisk and onto the hard disk to prevent the root filesystem from filling up. Presumably, if there are a lot of media files, twonky's "work" files can get pretty large. This may be what is keeping the disks spinning. There's probably some sort of "state" file in "appdata" that is open all the time that twonky is constantly accessing, even if serving up no media. Sorry, I don't know enough about twonky to be more precise.
If you "undo" the recommended changes to starttwonky.sh in order to move the work files back onto the ramdisk, you'll likely fill up the ramdisk and get the pink drive lights. It may work if you have a small number of media files, but that is not useful.
It is my guess that you won't be able to keep the disks from spinning up AND have a large number of media files with the DNS as it is. As suggested, a USB key may help. If it were me, I'd follow the howto to add a USB key filesystem and then redo the instructions in the twonky howto to move at least the log and "appdata" files to the USB key. If that does not stop the disks from spinning up, then move the other twonky files as well to the USB key and modify the starttwonky.sh file accordingly.
First step is to verify that it is twonky, and if so, get a USB file system running. After that, we can perhaps help you more with the changes to starttwonky.sh.
BTW, one way to see which files are being used is the linux command 'lsof'. You might run that and look for files that twonky has open. It may be useful.
Offline
I don't use twonky so I can't give you any specific recommendations regarding twonky, but first try disabling twonky like karlrado said just to see if it's twonky that is preventing the disks from sleeping.
If there's a way of disabling logging for twonky that might be a good idea. Unless something is not working properly and you need to debug it, you probably won't need any log files for twonky.
lsof will probably give you a big list of files... you can narrow the results to the ones in the harddisks only. Something like:
lsof |grep HD
Still that will give you a few results of opened files (such as libs, etc) that are probably already loaded in memory and are not actually being accessed continuously so those results might be a bit deceiving.
A better way of finding out which files were last accessed is to use the command 'find' unfortunately it looks like the find version in ffp does not have the '-amin' or '-atime' options implemented (those would allow to search files based on the last access time). The best you have available is '-mmin' which gives the last modified time. For example to search which files where modified in the last 60 min or less type the command:
find /mnt/ -mmin -60
Offline
I am using a USB stick for ffp, and I just installed Twonky on HD_a2 as karlrado mentioned in the howto on the wiki. I noticed that after building the database (17,000 songs, 13,000 pictures and 250 movies) the db grew to about 40MB. This is fine for HD_a2, but I didn't want my disks spinning up everytime. Also, I initially had default logging (basically just logs when twonky starts up, nothing else) enabled. I like logs, bc more info about running processes is great for troubleshooting, so I went into the twonky web inteface and wen to Logging and just clicked enabled...um now I had a 40,000 log file that was 155MB (JUST the log file!). So, i removed, recreated and disable THAT logging. So, word of caution if you want to enable logging.
Further, I moved the twonky folder to the USB drive, changed BOTH .ini files (one in root of twonky, the other in appdata folder) and also modified the starttwonky.sh script to call the USB location. Everything has been working fine, after twonky rebuilds once after reboot it sits and waits for the filesystem to change to cache any new songs.
NOTE: you should go in to the web interface for twonky and change the rescan time (forget what it's called) to -1, instead of default 60. Default of 60 will rescan every hour, but -1 will make twonky update its db only when new media is added/changed because it monitors the inotify program. Maybe this is why you discs don't spin down?
Long story short, twonky (and ffp for that matter) run fine on my 4GB USB stick with the discs spinning down just fine. Also have transmission running from the USB stick.
Hope that helps.
Last edited by bound4h (2011-01-04 04:51:11)
Offline
Thanks guys! Using find as suggested, I was able to determine that the file twonky/appdata/clients.data gets modified every minute, which would obviously keep the disks from spinning down. It seems to be the only file in the twonky directory that is modified so often. I'll therefore try moving the appdata folder to a USB stick and pointing twonky to it instead of /mnt/HD_a2 and will report back with my findings.
Now, to read the howto on setting up a USB filesystem!
Thanks,
cinergi
Offline
Success! I decided to run the entire twonky off the USB stick rather than just its appdata folder, just in case there were other files being accessed (but not modified) that "find -mmin" didn't detect.
The hard drives now power down and stay powered down until accessed.
Thanks to all!
cinergi
Offline
cinergi wrote:
Success! I decided to run the entire twonky off the USB stick rather than just its appdata folder, just in case there were other files being accessed (but not modified) that "find -mmin" didn't detect.
The hard drives now power down and stay powered down until accessed.
Thanks to all!
cinergi
thanks for your question... it helped me too
Offline