Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Hoopster last won the day on May 27

Hoopster had the most liked content!

Community Reputation

197 Very Good


About Hoopster

  • Rank
    Advanced Member


  • Gender
  • Location
    Utah USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I followed this guide a couple of years ago to convert my Reiserfs drives one at a time to XFS. Worked flawlessly.
  2. There are varying opinions in these forums regarding the necessity for ECC RAM. My main server is on 24x7 and I opted for server-grade hardware. I use a Xeon processor which, of course, supports ECC RAM. Given my configuration it just makes sense to use ECC RAM. My backup server uses an i5-4590 and has non-ECC RAM, however, it is only on occasionally. I have been using unRAID for almost 8 years. The first four years was with more consumer-grade hardware and non-ECC RAM. The last 3+ years I have used ECC RAM in my main server. In both cases, I have never had an error or data corruption that could be attributed to RAM problems. Actually, to my knowledge, I have never had any kind of data corruption (knock on wood). In your case, perhaps ECC RAM support or lack thereof should not be the deciding factor in your hardware choice. My MB and CPU choices recently have all supported ECC RAM so I use it. Other previous choices did not. FYI - you should format your array drives in XFS (BTRFS if you prefer) and not Reiserfs. There is no ongoing support for Reiserfs and XFS is now the default file system choice in unRAID.
  3. Yes. It is just a current limitation until such time as unRAID implements a newer Linux kernel. Sent from my iPhone using Tapatalk
  4. If you want to do hardware transcoding with Plex leveraging the iGPU in the 9900K, be aware that the i915 drivers in the Linux 4,19.xx kernel in unRAID 6.7.0 do not support the 9 series Intel chips. Of course, you could always install a discrete nVidia GPU and use the LSIO nVidia unRAID plugin, but, you cannot currently utilize the 9900K iGPU. Supposedly, support for the iGPU in the 9900K requires Linux kernel version 4.20 or greater. Software transcoding is a different issue as that is all CPU and the more/faster CPUs you throw at it the more you can do.
  5. Your problem is that the Linux Kernel in unRAID has no iGPU support for the 9900K. That requires at least Linux kernel 4.20 and unRAID 6.7.0 (and previous versions) currently uses 4.19.xx. At some point the Linux kernel in unRAID will be updated to 4.20.xx or greater, but, for now you are stuck with i915 drivers that do not support the 9 series Intel chips.
  6. I don't actively transcode at all with the i5-4590 based server; it is my backup server in case something goes south with the main server. I backup all content to it, but, I hope I never have to use it on a daily basis. I did test it with transcoding and it seemed to do fine, but, I never stressed it. The Skylake Xeon machine is my daily use machine, and I rarely get any "server too slow" messages. I have it set to 720p 4Mbit transcodes for remote devices and my kids access the server content at that resolution as do I when traveling. Yes, from time to time I see a bit of blockiness in dark or fast scenes; but, nothing too distracting.
  7. If you want/need to do transcoding in software (usually better quality), then CPU matters. It matters a lot with 10-bit HEVC with and even an i7/Xeon may struggle with that depending on which generation it is. If your CPU has an iGPU and supports Quick Snyc Video, you can do 10-bit HEVC transcoding in hardware with a Kaby Lake or Coffee Lake generation CPU. Any of them will do, even a Pentium. They struggle a bit with HDR content and it appeasr a bit washed out as Plex and others figure out how to deal with HDR. If you want to run a lot of dockers and VMs, you will need more than a Pentium, but, for Plex transcoding, many are getting good performance and are happy with Pentiums with iGPU and QSV. Personally, I have a Xeon in one server and and i5-4590 in another. I find that hardware transcoding at 720p 4Mbps and above produces very good quality. Neither of my chips would do 10-bit HEVC without dropping to their knees and begging for mercy. I know, I tried 😀. That's the next upgrade!
  8. Hoopster


    iotop is included in the Nerd Tools (aka Nerd Pack) plugin. I use it all the time; works great with unRAID.
  9. The most common cause for disks going missing in unRAID 6.7.0 is that these disks are attached to a Marvell chipset-based controller (PCIe or motherboard). I believe at least one other user also had problems with an ASMedia-based controller that used to work without issue. Rolling back to a prior version of unRAID resolved the problem, but, not because there is a bug in unRAID. The Linux kernel version used in 6.7.0 apparently has different drivers that cause these controllers to break whereas prior kernel version drivers work with these controllers. Were the drives that went missing by chance attached to the navy blue SATA ports on your motherboard?
  10. If you have docker containers with custom IP addresses on br0 and your call traces are macvlan related due to broadcast messages (which they appear to be), join the club. I had to create a VLAN (br0.3) and assign custom IP addresses on that VLAN to avoid the problem. Call traces do not always result in system crashes immediately. With this situation, after several days of call traces, my server eventually locked up hard and had to be powered down manually. With the br0.3 VLAN, I have not seen these call traces in almost a year. It does not happen to everyone and it does not always happen on br0, although for most of us it does. This is not a core unRAID issue. There is not much Limetech can do to solve this as it appears to be related to the macvlan implementation in Docker.
  11. What @Squid said. /mnt/user galore and running unRAID 6.7.0 And I am neither Canadian nor a mollusk so there is no reason for me to be special!
  12. I know this will not be very helpful, but, like Squid, I have always used /mnt/user/appdata for Plex and other dockers and have never had any Plex/SQLite database corruption. I have been running unRAID 6.7.0 since the day it was released. I am using the LSIO Plex docker container and not the Plex official, but, the problem does not seem to be container specific. Now, having declared that all is well for me in Plex/SQLite land, I will likely start seeing corruption today as the Karma Gods usually can't leave me alone. 😀
  13. I went with the WD NAS drives for data because the 8TB NAS drives are helium-filled. Helium supposedly reduces wear on the heads and platters. The 4TB WD NAS drives are air only. My backup server uses my old 3TB WD Red NAS drives from my original server. With only a $15 difference per drive for NAS vs. non-NAS at the time I brought them, I opted for the NAS drives because, somehow I reasoned, they must be "better." 😀 Again, I am not sure NAS vs. desktop drives for data drives makes a big difference unless there are other factors of importance to consider.
  14. This is not really an unRAID issue in the sense that Limetech could release a version that "solves" it. This appears to be an issue with the macvlan implementation in Docker which only shows up with certain server and/or LAN hardware and configurations. It is really hard to tell what causes the issue. Perhaps it is not macvlan/Docker at fault at all. Maybe it is the hardware not properly handling network broadcast messages in certain LAN/VLAN configurations. There are just too many variables. For me the fix is to avoid br0 and set up a VLAN (br0.3) in which the problem disappears.
  15. There are systems built with unRAID that use all types of drives from plain desktop drives to NAS drives to Enterprise-grade drives to NAS Pro, etc. These are used as both parity and data drives. The parity drive(s) get a lot of activity any time any data is written to the array (not cache) and during parity checks, which, depending on the size of the drives can take many hours (or even more than a day with the largest drives). Disk rebuilds of failed drives will cause a lot of parity drive activity as well. My parity checks with 8TB drives take about 16 hours. I personally use 7200 RPM HGST NAS drives for parity and 5400 RPM WD Red/White NAS drives for data. It is a preference and not a requirement. Many others are using non-NAS drives for both parity and data. I don't think it makes a lot of difference. Drive reliability should be the biggest concern regardless of brand, use/rating, etc. Again, there are many opinions on what drives are the most reliable. Some swear by the Backblaze reports and others have had very different experiences (differences due to sample size, I am sure). There really are no "recommended" drives for unRAID other than user recommendations based on their experience.