jonp

Yes. Q35 is a more modern machine type, but still heavy in development and not fully supported by libvirt yet. Some folks who have attempted GPU pass through with the PC machine type and failed had success when switching to Q35. That said, it's advised that new users as of the latest beta first try the PC type before attempting Q35. The fate of the Q35 machine type longer term is yet to be determined.

In theory, you shouldn't have to use vfio-bind either with this. Instead, libvirt should manage all that for you (binding to the vfio-pci driver). This is the supported method.

If you have a non-GPU device that you wish to assign to a guest in KVM and are using the machine type of PC (not Q35), you can use this XML and skip the <qemu:cmd> arguments at the end. This goes in between the <devices> and </devices> tags in your domain XML. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> </hostdev> For "bus", "slot", and "function", this should be your PCI device address. The above XML will pass through PCI device 02:00.1. Again, this only applies to non-graphics PCI devices (NICs, USB controllers, capture cards, tuners, etc.) Happy virtualizing!!

Hmm. I'll ask Tom about this.

I think there is a bit of a chicken and egg problem here. If there is a problem on the flash device, wouldn't the boot process not occur at all anyway?

I love Plex. It was the first app I had Eric dockerize when we were testing before beta 6. It is the most simple and intuitive to use media player solution on the marker IMHO. I love XBMC and have heard great things about some of the others, but I just can't get over the completeness of vision that Plex has consistently shown me since my time using it.

Thank you. There's so much FUD about SSD wear that I see all sorts of goofy workarounds in lots of places. Your write up was quite succinct. I think the biggest driver of that is confirmation bias. People forgetting that stuff fails early. They hear about, or experience, an SSD failure and it validates their feelings that SSDs must be treated with kid gloves. But an HDD fails and they call it what it is; poor QC, poor shipping, dumb luck whatever. Sure there were some models known for having problems [cough] OCZ [cough] but even those were over blown anecdotes versus actual data. They were also usually failures due to poor firmware and not wear of the actual chips. In any case, it doesn't hurt to have options so I can't argue with that. If you don't have an SSD or want to limit IO contention to the device used for transcoding, this tweak could help. Even on an SSD, if you have a bunch of VMs or containers all running on the same device and if they are doing lots of IO work, this could impact performance in those instances. While you'd have to be doing some pretty intense stuff, it is possible. And at the end of the day, flash based memory will always eventually suffer burnouts. Over years and years of use, between both Plex transcoding and front ending writes to the array, this could add up. So am I trying to say that by moving transcoding to ram you "triple ssd life"? No. I'm simply stating that RAM does not ever burn out from writes...ever. So if you are RAM rich, why not implement this tweak? I don't see anything to lose here unless you just don't have enough memory.

I would think so but what other apps are you running and are you running VMs at all?

Yes, but in that instance, you have a little more work to do. option a: use virtfs and mount /tmp to a path somewhere in the VM. Then use that as your transcode directory following the guide I outline in step 2 in the original post. Not sure how well this method would work exactly. Option b: manually create a virtual disk under /tmp and mount that to the VM, then specify a path to that mount for transcoding. Downside with this is you'd have to recreate the vdisk on every reboot (or script it in through the go file). Option C: get on the docker bangwagon and ditch that old VM to the curb!

Hahahahah!!!! These are great!!

Careful with calling it CLI Tools...... WOW! I DIDN'T EVEN THINK OF THAT! I TRULY DID AN LMAO WHEN I READ THAT JUST NOW! Yeah, I think "Power Tools" is probably good to avoid any less than desirable acronyms ;-)

Oh, and you should probably read through that link you posted. I don't think that was a statement against using /tmp in general, but just one guys issue. Also, the recommendation in there about "making it as large as your largest piece of media" is just nonsense. The transcoder doesn't need that much space as it's default setting is to only transcode 60 second of content at a time.

Good write up. I'll concede that this may or may not be a big deal, but no one can dispute the fact that cells on flash memory do suffer from endurance wear and will eventually burn out whereas RAM does not. As far as people having issues, I haven't researched anything on Plex forums or otherwise regarding that. All I can say is that I personally have yet to have an issue from doing it this way and I've been doing this pretty much since Docker was implemented in beta 6. If someone has undesirable effects on their system, of course they should change it back. I just wanted to put this out there because I do it this way, don't have issues, and can see the logic in doing this especially for those that don't have an SSD in their system. Edit: Regarding RAM consumption for multiple streams, I think you're just restating what I mentioned in the OP. If you don't have enough RAM, don't do this, or try tweaking settings. I don't know how many folks out there ever have 4 concurrent streams in their home. Guess it depends on the size of your family. For my household of 3, it's pretty much no more than 1-2 streams at a time. I also have 16-32GB of RAM in every system I own, so I'm "RAM rich" and don't worry about the # of streams.

I think we're going to go with either unRAID Power Tools or CLI Tools. It really does not matter to us. It's just a name. I am a little worried about what dlandon said about removing inotify... Guess we should probably figure something out for that, eh?

Hey everyone, just thought I'd put this up here after reading a syslog by another forum member and realizing a repeating pattern I've seen here where folks decide to let Plex create temporary files for transcoding on an array or cache device instead of in RAM. Why should I move transcoding into RAM? What do I gain? In short, transcoding is both CPU and IO intensive. Many write operations occur to the storage medium used for transcoding, and when using an SSD specifically, this can cause unnecessary wear and tear that would lead to SSD burnouts happening more quickly than is necessary. By moving transcoding to RAM, you alleviate the burden from your non-volatile storage devices. RAM isn't subject to "burn out" from usage like an SSD would be, and transcoding doesn't need nearly as much space in memory to perform as some would think. How much RAM do I need for this? A single stream of video content transcoded to 12mbps on my test system took up 430MB on the root ram filesystem. The quality of the source content shouldn't matter, only the bitrate to which you are transcoding. In addition, there are other settings you can tweak to transcoding that would impact this number including how many second of transcoding should occur in advance of being played. Bottom line: If you have 4GB or less of total RAM on your system, you may have to tweak settings based on how many different streams you intend on transcoding simultaneously. If you have 8GB or more, you are probably in the safe zone, but obviously the more RAM you use in general, the less space will be available for transcoding. How do I do this There are two tweaks to be made in order to move your transcoding into RAM. One is to the Docker Container you are running and the other is a setting from within the Plex web client itself. Step 1: Changing your Plex Container Properties From within the webGui, click on "Docker" and click on the name of the PlexMediaServer container. From here, add a new volume mapping: /transcode to /tmp Click "Apply" and the container will be started with the new mapping. Step 2: Changing the Plex Media Server to use the new transcode directory Connect to the Plex web interface from a browser (e.g. http://tower:32400/web). From there, click the wrench in the top right corner of the interface to get to settings. Now click the "Server" tab at the top of this page. On the left, you should see a setting called "Transcoder." Clicking on that and then clicking the "Show Advanced" button will reveal the magical setting that let's you redirect the transcoding directory. Type "/transcode" in there and click apply and you're all set. You can tweak some of the other settings if desired to see if that improves your media streaming experience. Thanks for reading and enjoy!

Your GPU virtualization stuff is more geek / nerd than these basic tools. Why don't you change the name of that stuff then? Your proposed name chosen gives no insight into what it contains and it will be referred to for the immediate and indefinite future as people ask how to do basic operation of adding a drive to their array without upsetting the wife or family or to troubleshoot why their array isn't shutting down. Why not name it properly now to avoid seeing it used for the next year or two? OK OK, point taken. Jeez, I was just joking ;-)

Lol, are we going to petition the willy wonka company to change the name of their candy too? I guess its not a big deal to change the name, I just have to laugh at the thought of someone honestly being offended by the name when www.thinkgeek.com is a real website. I'm a nerd / geek and proud of it!!!

DOH! Thanks Eric. Must have been running out of steam last night and forgot to include the link. Will update the OP.

From discussion that start in this thread, we decided to create a simple plugin that installs a set of additional command line tools onto your unRAID server. WARNING: These tools are for advanced users. Their use is not officially supported by Lime Tech. Use at your own risk and do not ask for direct support from us on the use of these tools. Eric put this plugin together mainly so that folks who want to do development or more advanced functions can have access to do so without having to manually download and copy the Slackbuilds to their USB flash device. Here are the packages that are included in this plugin: apr 1.5.0 apr-util 1.5.3 bwm-ng 0.6 cpio 2.11 git 2.3.5 iftop 1.0pre2 inotify-tools 3.14 iotop 0.6 iperf 3.0.11 kbd 1.15.3 lftp 4.6.1 lshw B.02.17 neon 0.29.6 p7zip 9.38.1 perl 5.22.0 python 2.7.9 readline 6.3 screen 4.2.1 sshfs-fuse 2.5 strace 4.10 subversion 1.7.16 unrar 5.2.5 utempter 1.1.5 vim 7.4.898 If someone wants to write up a small description of each of these tools, I will incorporate into the OP here. Otherwise, google is your friend Here's the link to the PLG itself (now on dmacias' repo). Copy and paste this on the "install plugin" page of the webGui and you'll be on your way! https://raw.githubusercontent.com/dmacias72/unRAID-NerdPack/master/plugin/NerdPack.plg

What if a plugin generates more than one page file?

I think the challenge here is that plugins do not necessarily need to enumerate a control panel at all. Some just modify the existing look/feel of unRAID's standard page files. Dynamix at one point was a great example of that as a web UI plugin. It itself didn't need a control panel for the base plugin at all. The second challenge is that plugins today enumerate icons typically under the settings page, but technically can do so to any page. We'd like to avoid redundancy where possible, so what's the right answer here? Centralize all plugin icons to the plugins page and remove the ability to create new icons for plugins outside of that page? Simply instruct developers to not bother creating icons on other pages because this method is available? Another challenge is familiarity. Many users are already comfortable with how the existing plugin system works. We could end up with a lot of threads asking "where did my settings page for X plugin go?" While I agree that fundamentally, this makes sense to do, there are other considerations that we should take into account before we do such things.

Right, this is something I've been meaning to address with Tom. There is a way to make the icon either clickable or not. PHAzE, I'll ask Tom to either chime in here or give me feedback on this so I can share here. Beat me over the head with a stick if I don't get back to you on this by end of next week ;-).

ok, that seems complicated, LOL Exactly! We want to get to testing this at some point, but not something we will get to play with before the release of 6.0.

https://btrfs.wiki.kernel.org/

Not easily. Its all commandline right now and relies on subvolumes on btrfs. This is still a feature request we will need to address.