hocky

Sounds good. I´m not requesting a book that could be read as a novel before going to bed Tieing it all together and keeping it up-to-date is more or less editorial work that doesn´t require to actually write large pieces of text. Again, sounds good. If you´re eager to use a brand-new, but more or less undocumented feature you´re good to go. If you prefer to have a documentation on the feature (like me), you just have to wait a bit. However, the "bit" has to be predicatable (at least to some degree). And again: sounds good. :-) :-) So i understand there are a couple of activities pointing into the right direction. I´d like to emphasize that i´m pretty new to UNRAID and that i like what i see. I´m critizing because i like the product and would like to see it improve further, not for bashing.

Why should they? They know they have a "enthusiastic user community work for free" :-) In my opinion, the community could reduce effort on the first and focus more on the latter with a bit better documentation in the background. But i know i´m on lost post with my opinion, so i´ll leave it for now. EDIT: Oh, and since jonp already mentioned above that updating the documentation is on the to-do-list, everything should be fine. :-)

Your bullet-list is already a statement for having proper documentation in one place: atm, documentation is scattered in multiple places and it´s up to the user to find it. If the user finds it, chances are that the piece of information he found is outdated/doesn´t fit to the version he uses. Saving effort for documentation on developer side just pushes the effort to the user (and is multiplied there). I don´t say that it´s neccessarily the developer himself who should do the documentation. On the contrary, often it´s best not to let the developer document what he´s created if you want people to understand it. That´s fine for me if it´s advertised as such. If it´s converting to a standard feature, that´s a different story. I´m hearing what you´re saying, but that doesn´t make it better. I understand that most people demand to have the latest and greatest feature and spend hours in finding out how it works, rather than having the existing features properly documented. I would prefer the latter. Call me old-fashioned. :-)

Documentation and coding (feature updates) should be handled with equl priority. If there´s not enough time for updating documentation, one should slow down development.

Hi, i just set up an UNRAID server as a media server including PMS in a docker container. Hardware is an Intel i7-8700 sitting on a ASRock Z370-Extreme4-board with 24GB RAM. I´m currently moving from FullHD to 4K-content and found as well that plex requires significant more performance for 4K than for FullHD-transcoding. My current setup (described above) plays three 4K streams simultaniously without a problem. CPU load is at 30%. Hardware transcoding is enabled in the plex docker and is used for all streams. AFAIR i spend less than €500,- (~$590,-) for the board an the cpu.

Hi, i´ve recently build a rackserver based on a FANTEC SRC-2080X07 case. It´s 2HE height and has 8 external drive slots. You have to take a bit on the height of the cpu cooler. I´ve got an Intel 8700K installed and it works just fine with the box-cooler. It has enough space for a standard-size atx-board. However, you need low profile add-on cards (nic, hd controller, etc.) if you want to add sth. Fantec also has standard-size 4HE cases. These storage cases usually have a backplane for the drive slots which needs to be connected to the mainboard or disk-controlller ports with a special cable. As an accessoire, you want sliding rails to be able to open the case while in the rack.

Hi, just had a look at your CPU specs: i´m afraid your the CPU of your Plex Server is not powerful enough for transcoding 4K. It has a Passmark of 7.800, Plex recommends at least a passmark of 13.000 for 4K content.

Same for me Can you please try without? It´s just for testing.

Hi, i found that using subtitles heavily increases the load on the Plex server. Can you please try to play without subtitles enabled?

Thanks for the information. I think that´s also what i´m going to do. Seems to me to be the "cleaner" solution than putting them on a cache drive.

Ah OK. Good point. So, would placing the VMs on an unassigned drive (via the plugin) a possible solution?

I´ll do another test later with running diagnostics before and after the change. I read that as well. My impression was that putting them on the cache drive is the unsafest place to put them because there is no redundancy (unless you add another cache drive). At the moment, my dockers/vms are placed on the array itself. Actually i´m looking for a solution that they are able to keep running even when the array is down.

Hi, i moved around the disks a bit today and indeed, the parity disk was recognized if attached to a different sata port on the motherboard. However, this didn´t work with the cache drive. Not a big deal since a missing cache drive only degrades performance, but any idea why this could be?

Well, the cause of that could be the trial period. If you want to test everything, you are a bit in a hurry and tend to do the second step before the first.

Yep, i need to think about it. Propably, i´m too much influenced from testing. During testing, i´m changing relatively often. During normal operation, there shouldn´t be too much changes, that´s true. I guess it´s also good practive to first set up a stable array and then add additional dockers or VMs on top of it.

Hm, good point. If i have to stop the array anyway, then hot-swapping doesn´t bring much benefit. I´m planning to run a couple of services in VMs on the box. These services would go down when stopping the array as well. I´m not so sure if UNRAID is the right system for me in that case. As far as i understand UNRAID supports only one array. If i could my VMs and data on different arrays, that would prevent the VMs from going down every time a do a change on the data array.

Hi, no, i didn´t move disks in powered on state so far. So that shouldn´t be the source of the problem. However, adding new and/or removing faulty drives during operation is one of my desired modes of operation. Both the ports on the motherboards (at least six of the eight available ports) and the backplane i´m using supports hot-plugging. So that´s sth i´ll be testing in the near future.

I´ll wait until the parity build is done and give it a try moving disks again. I´ll report back in any case. For now, thanks a lot guys, i learned a lot about the system in this conversation.

Hm, no - it says "unassigned", not "missing" in my case. So probably there was an issue with my config right from the beginning. Update on the issue: In the meantime, i reassigned both the cache drive and the parity drive to the array. The cache drive was recognized right away. Unfortunately, that´s not the case with the parity drive, it´s rebuilding from scratch right now...

No, i added the parity drive about the same time i added the cache drive. The reason why it didn´t show up in the screenshot i posted was because it wasn´t detected by the motherboard´s internal SATA adapter (which is actually the reason the issue start at all: both, the cache and the parity drive were attached to the two internal sata ports i mentioned above. And both ports seem to be dead now, not detecting any drive attached to them)

Must be about 3-4 weeks ago when i assigned the SSD as a cache drive. Because i´m still in testing, i rebooted a couple of times since then. I also upgraded RAM on the machine last week or so, so i even switched it completely off at least once. BTW: i´m still testing, the system is not yet in production. So probably it´s the best idea to restart from scratch. However, the purpose of testing is to find issue like this one that shouldn´t appear in production so i´d like to understand the root cause of the problem. Addition: I just did a test moving the parity drive to a different bay/port in the chassis. Same as with the cache drive: it´s listed as an unassigned drive and not recognized as the parity drive. Is there sth wrong with my system?

Well, i had. :-) I can even mount the cache drive as an unassigned disk and there i can find the cached data. No, i was referring to the /dev/sdd which was different before. But as i learned, UNRAID doesn´t seem to refer to this name anyway.

Voilá unraid-diagnostics-20180829-1709.zip

Sorry for confusion. To clarfiy: I moved the disk to a different bay in the storage chassis which is connected to a different SATA-port on the motherboard. This is how it looks like now: and here with the array stopped:

Thanks for the replies. That was actually what i was hoping: that the drive is recognized by UNRAID although it came back in a different slot. The ASRock MB has 8 ports: 6 of them are tied to one controller, the remaining 2 tied to another. The cache disk is now on the other controller, so that is probably what is preventing UNRAID from recognizing the drive. OK, so you think there´s a chance that UNRAID recognizes it´s a previously used cache drive?