barrygordon

I have a Home Theater that is fully controlled by a Windows 10 PC. The NAS (Unraid) stores a large collection of DVD's ripped and kept in Matroska format. If I am looking to select a movie to watch there is a full indexing system on the PC that when is selected will load the desired movie from the NAS. I would like to be able to spin up the disks on the NAS and spin them down when all done. I used to have the code to do that (spin up/down over TCP/IP) and it worked fine. I used port 8010 at the IP address of the NAS, but that has stopped working several software generations ago. Is there any capability available today (version 7.0.3) ? I believe there is a shell that does that but I am not conversant with "shell" capability, and very familiar with TCP/IP

I would like to be able to send my unRaid NAS to be able to disk up/down the hard drives. I would like to be to all the drives or specific ones. My Home Theater, has about 600 DVD's stored on the NAS. I would like to be select a movie (DVD) when the Home Theater application starts, living the drives spin up to eliminate the delay when I select a movie. Has any one be able to help me do that.

My house is highly automated and an Unraid NAS is a key part of that automation. I have registered a new domain and a corresponding email for that domain. When the new owner takes posession they will use the new email address and password which I will leave them. The question I have is whether a can register the new email and password at this time, in effect transferring the Unraid registration to the new email and new password as the registered owner

I am looking into HDHomeRUN tuners for ATSC 3 by Silicon Dust. They feature the use of a NAS. I was wondering if any Unraid users have experience with their product line and have successfully integrated one of their tuners with Unraid. If so how did you do it and how well does it operate.

I am very interested in this. I would like the APi to have a nice TCP/IP interface or a REST interface. IIRC an earlier version of unraid (way back in time) had the ability to do things using TCP/IP and GET. I used that to spin up/down disks asynchronously when I started my home theater so that I would have the wait on first access when a movies stored on the unraid NAS was selected.

I am looking for a script that would monitor a TCP port and accept commands to spinup, spindown, or return status of a disk. The the minimum capability I need would be a command to spin up all the disks in the array. I could have them spin down after 4 hours of inactivity. The major use of the array is to feed my own home theater movie system. The delay when loading a movie bothers me and I would like to spin up the the array disks when I open the theater's movie librarian. It is my belief that if disks are generally not being used keeping them in a spun down state will increase their longevity Any help or advice would be greatly appreciated.

After about 5 years I had a power supply fail. My system was designed with redundant 2U/3U power supplies. So all that has happened so far is a whistling noise to tell me that the redundant power supply system is down to one supply. The supplies are made by Emacs (originally Zippy) and my system is R2W6500P. It consists of two independent R2W6500P-R units which are hot swapable. Everything in my case is hot swapable except the cables the Controller card and the motherboard. Perhaps some day in the future I will be able to swap the drives too if and when the unRaid software permits it. I started to hunt for a replacement. I found one new for $278.50. I then tried eBay. It seems that a lot of server farms are being upgraded and that exact power supply system is becoming available at very low prices. I picked up 3 of the R2W6500P-R units for a total of $52 including shipping. They are used but tested and guaranteed working. When they come in I will slip one into the RM case from the rear and plug the power cord in and the whistling should then stop. No down time. A nice complimentary system to the Unraid

The trap I fell into on controlling the environment in the zone for where the servers are, is that I forgot that in the winter the house is heated by forced air. If your servers are in their own zone with nothing else okay, but beware an error of omsiion like the one I made. I ended up installing a small two part AC system, for just the room (actually a very large closet) that all my servers are located in and just keeping it at 72 degrees F.

What works - Works!! As Rajahal recognized, I was only commenting on the general case of cooling design as related to heat flow.

Sorry Rajahal, I have to disgaree (Partially), although the use of "hot Air" makes you technically correct. The following is general in nature and offered as a guideline, not a design. Assuming that the room ambient is cooler than the air in the case you want that air to flow across componets heating up thereby removing thermal energy from the components (cooling them) before exiting the case. Ideally you want it (the air) to exit the case when the temperature of the flowing air is the same as the components it is cooling. Heat transfer always flows from the warmer body to the cooler body, and the efficiency of the transfer is related to the temperature difference between the two bodies. What you do not want is a "Short circuit" flow where air sucked into the case immediatly exits the case before being allowed to remove heat from the components. Not knowing the specific case design, it is hard to comment further.

There have been many posts involving SAS to SATA breakout cables of the Forward vs Reverse types. Which type to use where is generally the question. To make it simple, if the host-controller side is a SAS connector (SFF-8470) and the target side is SATA drives then you must always use a SAS to SATA Forward Breakout Cable. If The Motherboard/host-Controller side are SATA connectors and the backplane is a SAS connector then you must always use a SAS to SATA Reverse Breakout Cable. For SATA to SATA you just use a "SATA" cable as there is only one type, although they do come in different lengths. For SAS to SAS connections there is also just a single cable type. The two breakout cables, forward and reverse, are not the same although they look outwardly to be the same, not withstanding the fact that some of these cables have the SATA portion of the cables at staggered lengths and some have them at fixed length. If you just want to follow the rule you can stop reading now. Why are there two different cable types for SAS to SATA connectivity? An objective of the SATA system design was that SATA cables would have identical connectors at each end, and that SATA devices would have identical connectors independent of whether they were disk drives or disk controllers. This helps to make interconections foolproof and reduces the cost of cables. If you ever look at a SATA to SATA cable they are identical and wired as a 1:1 cable. In a 1:1 cable pin 1 of end-A goes to pin 1 of end-B, pin 2 to pin 2, pin 3 to pin 3, etc. If you were to look at the SATA connector on a host-controller or motherboard and the SATA connector on a disk drive they look the same, and are physically the same, but each are wired differently. A SATA connector has 7 pins. Two of the pins make up the receive pair and two of the pins make up the transmit pair. The other three pins are all used for ground signals. If a 1:1 ("straight-through") SATA to SATA cable is to work, then the receive pair can not be the same pins on each of the two device connectors (Host vs disk)! If they were the same pins then we would need what is generally referred to as a "cross-over" cable. The "Absolute Rule" is that the transmit pins on one side must connect to the receive pins on the other side and vice versa. This is true for PC-PC RS232 connections, Ethernet Connections, SATA connections, and almost all types of serial connections which are duplex, i.e. separate receive and transmit cables. The SATA cable connector design puts the Host/controller side transmit pair on pins 2 & 3, and the Receive pair on pins 5 & 6. On the Disk drive the receive pair are pins 2 & 3, and the transmit pair are pins 5 & 6. As a point of reference pin 7 is the keyed pin. All SAS connectors have their pins structured the same way no matter if they are on a host controller card, or a SAS backplane. Since for each port of the four that make up the SFF-8470 connector the transmit pins and the receive pins are physically in the same location, and we must connect SAS transmit to SATA receive and SAS receive to SATA transmit (for each port); the cables must be different depending on whether the SATA connector is on a disk drive or a Motherboard/Host-Controller. A SAS to SAS cable must therefore be a "cross over" cable to connect the transmit pairs of a port to the receive pairs of the corresponding port on the other side. Hope that helps clear up the mystery.

Thanks Joe. Now I have to figure out whay it is not working. When I was first building the unRaid I tested it and it worked but had poblems on waking up. It did not restore the Monitor correctly so I decided to put off the use of that feature completely. I am now looking at it again. I will have to check it all from scratch. I am assuming that if the array is stopped before I try the S3 suspend, that should be enough to keep unraid happy.

Just getting back to look into this. When I issue echo 3 > /proc/acpi/sleep nothing happens. I will check everything but first a little question. If I look at /bin/acpi/sleep (cat /proc/acpi/sleep) all I see is a single line that looks like S0 S3 S5. That looks strange to me as I would have expected to see a bunch of gibberish being the code of a program. Is it correct? Or did it somehow get destroyed?

ahhh yes I have seen posts from this idiot before