I have had a similar problem with my ReadyNas Duo v1, RAIDar 4.1.15, sitting in a small home network.
The 2 disks are set to spin down after 5 minutes of inactivity.
Every 2 minutes after spin down, both disks spins up again, even if no devices are connected, and no clients asks for any services running (CIFS and minidlna).
This drove me crazy.
I found out by trial-and-error what caused the situation. The Samba/CIFS server was running as a WINS server. It seems that the WINS server function browse the network, or perform some other activity, every 2 minutes, which causes the disks to spin up.
I have browsed the content of the configuration files for Samba in /etc, but have not been able to locate any parameter governing the behavior of the WINS server, except for an "on-off switch" in /etc/smb.conf. (The "wins support = [yes/no] switch). Therefore my guess is, that the timings of the WINS server functions are hardcoded into the Samba software.
The only remedy I can point at is to untick the "Network -> WINS -> "Become a WINS server" setting.
I've found that another service have the capability of spinning up disks for no reason, namely the media streaming server ReadyDLNA/minidlna. (A great service that will push subtitles all the way through Chromecast to your flatpanel
After a cold boot and the ReadyDLNA is fired up, there is no symptoms of untimely disk behavior.
This seems to change after the first upnp/DLNA device have made a connection and pulled media from the ReadyDLNA server.
When the streaming service have been dragged out of idle and put to use by some client device, your disks might not spin down at all, or spin down just to spin up again after a short while, even if no device is anyhow connected to the server.
The cure is not found in the RAIDiator web configuration. You will have to edit the file /etc/minidlna.conf by hand, with a texteditor such as vi from a SSH connection.
The file contains the parameter: "notify_interval". Comments says 30 seconds is the default value. Changing the value to 86400 = 24hrs makes the problem go away.
(I don't know for sure what the parameter do, but a guess is, that it tells the service how often it should look whether new media have been added to the library. If so, a 24hrs interval won't hurt, unless you add new media several times every day. Updating the media library is a different topic though).
As in many other aspects of life, I recon it must be a trade off between two evils. Do you want your drives to spin down and kept silent, or do you want a fast and secure upnp recognition at the price of disks spinning idly most of the time?
I won't argue with StephenB, that a 24hrs setting, or anything more than 30 seconds, of the "notify_interval" would (should?) cause a corresponding delay in the ReadyDLNA server showing up on some smarttv's Upnp/DLNA renderers. That is just not my empirical experience. My stuff has been running properly across my various gadgets and devices with the 24hrs setting, without any knowledge of this problem. But StephenB's reply prompted my curiousity to make an experiment with the ReadyDLNA-thingy (version 1.1.4 it says), keeping the 86400 seconds setting of the "notify_interval".
First a brief description of my setup: Router1, building 1, "the hub", connects to the Internet via a DSL, is Upnp enabled, supplies DHCP to the LAN, and acts as a WiFI(1) ap. Router2, building 1 (a guest house), is hooked up to Router1 via ethernet, and is set in bridge mode. (Tomato firmware for the augurated). It de facto acts as a switch with a WIFI(2) ap. Extender1, building 2, supplies WiFi(3) from building 1 to building 2, and is connected to LAN and the Internet from WiFI(2). The ReadyNAS Duo v1, running the Upnp AV server "ReadyDLNA", is hooked via ethernet to Router2. A cheap Android tablet is connected via WiFi(1) to Router1. It has 2 tasks, A: to act as a Upnp AV control point with "Slick Upnp" and a local Upnp AV renderer "MX Player". B: to act as a Upnp AV control point with "BubbleUpnP" in conjunction with Chromecast2 acting as a Upnp AV renderer, passing stuff via a Pioneer AV-mediacontroller to a Panasonic plasma panel. A Chromecast2 device as mentioned, connected via WiFi(1) to Router1, and the beforementioned Pioneer AV-mediacontroller, and controlled by the beforementioned cheap Android tablet. A Pioneer BDP-S580 BluRay Player, sitting in building 2, and connected to WiFi(3) and a cheap Sony flatpanel. The BDP-S580 is obsolete in many areas, but have a marvellous Upnp AV control point/renderer, that plays whatever ReadyDLNA throws at it, including subtitles to the benefit at the folks in the guest house. (As good as the Android "SlickUpnp" and "BubbleUpnp" apps).
To see if the setup would go blind with the 24hrs setting as suggested by StephenB, everything except the ReadyNas was shut down. All data, caches and whatever on the control points and the renderer devices was flushed and deleted, in order to emulate an "if you restarted your Smart TV". A few changes was made to the media library, on the ReadyNAS and a library update performed. The ReadyNAs was rebooted, and left to its own for half an hour, in order to have the first-on-boot notify go by without the other devices knowing of it, since they where off. Then the rest of the arsenal was lit, and - love and behold - the cheap Android tablet control point as well as the Pioneer control point/renderer immediately found the ReadyDLNA and the played stuff.
I am not a Upnp AV expert, and don't know why my devices recognizes the ReadyDLNA, while they in theory should not, but you might strike luck as I have, having all your Upnp AV stuff working across 3 points, but if not go back to a 30sec setting.
The ReadyNAs was rebooted, and left to its own for half an hour, in order to have the first-on-boot notify go by without the other devices knowing of it, since they where off. Then the rest of the arsenal was lit, and - love and behold - the cheap Android tablet control point as well as the Pioneer control point/renderer immediately found the ReadyDLNA and the played stuff.
That is an interesting result.
My information on the setting came from a stackoverflow post ( http://stackoverflow.com/questions/5180409/why-is-the-minidlna-database-not-being-refreshed😞So to clarify, notify_interval controls how frequently the (mini)dlna server announces itself in the network. The default value of 895 means it will announce itself about once every 15 minutes, meaning clients will need at most 15 minutes to find the server. I personally use 1-5 minutes depending on client volatility in the network.
I also noticed the old 2011 posting StephenB quoted, about af SmartTV having problems discovering the streaming service, and was surprised that things worked ok anyhow keeping notify at bay for 24hrs.
My first suspicion was, that the controller-point software maybe saved some info about previous connections, and tried that on next start up. This was the reason for deleting cache and data from the mentionend apps, and clearing the entry from the BD-Player.
When the ReadyNAS was disovered in all 3 instances, my best guess is, that newer control-point software don't rely only on "pokes" from servers notify function, but themselves perform af "peek" function to see what is alive on the LAN, and that the ReadyNAS responds without spinning up disks. But I will leave all that to the geeks.
When the ReadyNAS was disovered in all 3 instances, my best guess is, that newer control-point software don't rely only on "pokes" from servers notify function, but themselves perform af "peek" function to see what is alive on the LAN, and that the ReadyNAS responds without spinning up disks. B\
There is a way for the client to send out a multicast query (your "peek"), and I am thinking that your clients must be doing that.
The net is that your setting change isn't causing any problems for you, and that it is eliminating needless disk spinups.
