OMGerm

Thanks again. I'm doing my 1080p HandBrake h265-10b encodes (from a 4K source) on an 8700K (Coffee Lake), then uploading to my UNRAID box to stream; I have only encountered an issue when streaming from the UNRAID box to a Roku 3. Transcoding needed to happen server-side and it basically melted the CPU (8-Year-Old AMD Sempron). Streaming to Plex Media Player on Windows was fine. Streaming to my TCL Roku TV was fine. The clients were direct playing I believe. I need to upgrade the UNRAID server anyways, otherwise I'd just roll the dive on an Apple TV 4K or something of that nature. Which is what led me down the current rabbit hole of needing help with suggested parts for a Node 304 build.

Thank you for the latest reply. I've turned on signatures, and appreciate what you've got listed. I've been eyeing the Node 304 (your backup) to build in with 6x10TB (50TB w/1 Parity). I've quoted another one of your replies and have a question. My use case would be streaming Plex/HandBrake optimized 1080p versions of my 4K collection in h265-10bit. Does the h265-10bit caveat mean similar things for CPU transcoding as mentioned above? That is, does the h265-10bit by itself mean I'll likely need a GPU or a higher-end CPU? Or is it rather the resolution of 4K that pushes the need?

@Hoopster Would you mind linking a PCPartPicker for your current build? I'm curious about what case/components you're using. Thank you for all of the information you've shared, it's very helpful.

I started the process of upgrading to 5.0.4, swapping my removable USB with my pro stick, and installing my ssd. Parity ran successfully and I finished formatting the ssd this morning via unraid. Everything seems good so far. I was curious though, what makes your screenshot so pretty? Is that an updated unmenu, the updated web gui I read about somewhere, or something similar? Sorry for the silly question, but it looks much more manageable than the stock gui I've got.

Related, maybe helpful: To configure a Mac OS X user account so that .DS_Store files are not created when interacting with a remote file server using the Finder, open up Terminal and: defaults write com.apple.desktopservices DSDontWriteNetworkStores true This will affect the user's interactions with SMB/CIFS, AFP, NFS, and WebDAV servers. Either restart the computer or log out and back in to the user account for your change to have taken effect.

Excellent responses, thank you very much. I think this answers everything; great!

I've been doing a lot of reading lately about adding a cache drive, running plex, and getting the most out of ssd's used in this regard. While there is plenty of information available, I'm having a bit of trouble lining everything up in my head. I'd like to use a cache drive (Samsung 840 Pro 128) with mover script and also host Plex Media Server in an applications share (using method shown here: http://lime-technology.com/forum/index.php?topic=28868.0). Given that I literally just opened my ssd's box, I have a couple questions. [*]Do I format this drive prior to install, or does UNRAID take care of that bit as part of the add-to-array process? [*]How does the mover script know not to move over my Applications share when it kicks off at 3:40 every morning? I'm pretty new to this (just purchased my license around Christmas time). I've been running the freebie version for a couple years (2 + parity). And I'm looking to get my media pushed to a Roku 3 with minimal transcoding (single core CPU). I think Plex is the way to go, but the cache drive install has me hung up on the above. Any insight is apprecated.

Thank you for the advice!

Hi! Recently purchased a pro license to be delivered via pre-configured flash. I've been running the free version (5.0rc8a) for a long while (a year?) and I have all of my shares setup and everything works great. Is the move from freebie to paid in this instance as simple as moving over my config files on my old flash to the pre-configured flash and booting (given the pre-configured flash will be running 5.0.3)? There's so much information out there I may have complicated things that aren't at all complicated! Any thoughts appreciated!

Well, I swapped SATA ports on the MOBO (from 4th to 3rd) and I tried booting with much success. I guess I'll keep an eye on things as I find it in me to reboot the server over time. Thanks for the thoughts.

I haven't done any troubleshooting, as I wasn't too sure it was an issue. It's always the third hard drive. And it's always been plugged into that same SATA port. I suppose I'll swap the SATA port it's plugged into on the MOBO to see if that has any effect and go from there. As far as the PSU goes and its cabling, I believe the cable line has multiple connectors and one of them is powering a non-issue drive. I'll have to give it another look tonight. Since I had finally gotten things working and am in full backup mode with my dvd collection I got a bit wary of trying anything.

So, I have a new UNRAID build; 3 2TB WD Reds, all passed 3 preclears no problemo. UNRAID setup went great, everything working super duper. I'm even hosting files, parity syncs are working as intended. BUT! Sometimes when my server starts it takes awhile for the third hard drive to be recognized prior to booting UNRAID (ya know, on that fancy MOBO black screen that lets you enter setup or change the boot order). It's plugged into the 4th SATA port. I have the 1st SATA, 2nd SATA, and 4th SATA port plugged in (I skipped the 3rd on the MOBO for some reason). Is this something I should be worried about? Sometimes it's recognized right away and startup is super snappy. Other times it takes > 1-2 minutes. I even had one time, upon getting rather frustrated, when I entered BIOS setup prior to the detection finishing and it wasn't shown in my drive list at all. Bad SATA cable maybe? Having an empty 3rd SATA slot is an issue? Any ideas?

I don't think the presence or absence of the cache drive would affect uploads speeds at all. It's really a non-factor. The cache drive is only for buffering writes to the unRAID array so parity calculation does not slow down initial writes. Crashplan is backing up the data once it hits the unRAID share, it doesn't even look at the cache drive (unless for some strange reason, you pointed Crashplan at the cache drive as a backup source). I am currently backing up my Pictures share (543 GB). It does not use the cache drive. If it did, it would just mean that pictures, when first copied to the array, would go to the cache drive and then be moved to the Pictures share as scheduled by the mover. During this second write, parity is calculated and the pictures become part of the protected array. Crashplan doesn't "see" the pictures until they get to the share. While backing up a share, you can add content all you want (I have done this several times during the last six weeks) and Crashplan will add them to the data to be backed up. Again, the cache drive (present or not) should have zero affect on Crashplan backup speeds. That's a great explanation. I re-read your previous reply and understood what you were saying (alt-tab at work is both a wonderful and detrimental thing), then deleted my question. Regardless, thanks for taking the time to reply anyways, I appreciate it. What you say makes total sense. I'll take a look at those complaints on speed you were referencing and see if I can't give it a go anyways (for better or worse).

Thank you both. After reading through the thread provided by prostuff1 and given the frustrations expressed by Hoopster, would it be possible to give this plugin mash-up a go without a cache drive? As noted in my original post, I currently utilize the Basic version of UNRAID (which disallows the use of a cache drive).