First off I’d like to say that rockstor and its admin/devs are top notch. Anytime I’ve had a problem its been solved with a quick response. Couldn’t ask for more from the rockstor team. Thank you
I’ve had my machine up and running for probably going on a year and its been pretty awesome. I’ve got some rockons going, one of them being plex which is great. Now, my understanding is that plex can utilize a graphics card for hardware transcoding so I had an extra one laying around (GTX1060) and I threw it in the machine. Started poking around in few forums on how to install drivers but until now I have not gone through with the driver installation other than installing "el repo’ and NVidia detect. Did some more reading and came across some that where reporting that their machine wouldn’t boot up after the gpu driver update, I don’t want to go that route so now I’m here. I know that rockstor’s underlying os is centos so I took that approach when attempting to install the drivers. Just haven’t gone through with the full installation. My question now is, is it worth it to install the GPU and drivers on my rockstor machine for hardware acceleration in plex? If it is what would be the appropriate steps to get the drivers up and running?
Ive recently upgraded my mobo and cpu from an old phenom setup to an I5 8400 for quicksync capabilities. From what ive gathered in this post https://github.com/rockstor/rockstor-doc/issues/214 is that my best bet for Intel QS is to wait for the openSUSE update?
It shouldn’t be required but it’s definitely the way to go I would say as the last CentOS based released is 3.9.2-57 and we didn’t update the elrpo kernel-ml it used for a very long time. Where as our ‘Built on openSUSE’ offerings have an upstream (openSUSE/SuSE) maintained kernel. So in that sense alone you are more likely to get better hardware support/fixes/improvements. Especially for newer hardware. Plus any fixes/enhancements we release of course.
See the following forum thread for the progress on what is currently Release Candidate 6 (4.0.5) released as of yesterday (3rd Jan 21):
I’m not familiar with using quicksync myself but as long as you have post 3.9.2-39 it should at least be an option within the Rockon install.
For the nvidia support and it’s associated hardware acceleration elements you are again advised to go the Rockstor 4 route, again for the newer kernel and current OS underneath, i.e. CentOS 7 for Rockstor 3, openSUSE Leap 15.2 for Rockstor 4.
Hopefully others more knowledgable / experienced in this area can chip in as I’ve not tried the Plex hardware acceleration yet myself, although I have a machine lined up ready to try it. As you have gathered the feature itself, within the Rock-ons config area, was added by our forum Admin and major contributor across the board @Flox.
Note that a fresh re-install will be required to move to the ‘Built on openSUSE’ but your existing pool/share/snapshots can be imported in the same way as in the CentOS variant. And if you first save/backup you config (and download it), much of you settings can also be imported. See the following doc section of config save and restore:
I’m definitely excited for rockstor 4 and I’m very much looking forward to updating my machine soon. I will wait until rockstor 4 on openSUSE to go ahead with the gpu install. Thank you for taking the time to help me out!
I second all that @phillxnet said, but wanted to bring my two cents on one point: using the GPU.
I personally do not have a GPU so I never had the occasion to try, but I know that using GPU acceleration in Plex would require you to use a different docker runtime than the default one. Indeed, you would need to install the nvidia-docker runtime and configure the docker daemon to use it. Then you would be able to bind the GPU device and configure Plex to use it for hardware acceleration. As you can probably tell, this is not a particularly lightweight process, and certainly not something that is currently supported by Rockstor; this means you would have to manually do so.
As you do seem to have a CPU supporting Intel QuickSync, I would strongly recommend giving it a try first as you would only need to input its device path at the time of the Plex rock-on install (and then configure it within Plex, of course). I’ve heard very good things about QuickSync and its performance even for very high use. Of course, if you need to run a very high number of transcodings at the same time, it may not be enough, but its simplicity of use when compared to GPU hardware acceleration would justify to give it a try first, I believe.
Of course, let us know how either way will work and don’t hesitate to ask around for any feedback… we’ll try to help as much as we can.
Thanks for chiming in, your help is much appreciated. So I went ahead and attempted to enable HW transcoding with QuickSync in rockstor and in plex but I’m still not getting the magic “(hw)” on my plex dashboard.
As you can see here Im still not hw transcoding (Not utilizing QuickSync)
Before all of this I also deleted and re-installed my RockOn share if that helps?
Also Im not 100% sure I set up the transcoding share to the Plex rock-on correctly.
/mnt2/transcode vs /transcode.
I unfortunately can’t give you a solution for sure as I don’t have a Quicksync hardware to test it, but I’ll try to see what I can do.
Yes and no… There’s nothing wrong with the way you did it, but I don’t know whether (somehow) Plex “expects” this directory to be accessible at the /transcode path rather than /mnt2/transcode as you have. The way you have it, the Plex container sees the Transcode share present on your Rockstor machine at /mnt2/transcode with the /mnt2/transcode path from the Plex container. While this shouldn’t be wrong given you specified the correct path in the Plex UI (/mnt2/transcode), I wonder whether Plex expects it to be with the /transcode path. I would be surprised, but you never know.
In your screenshot, the field label Rock-on directory defines the path with which the rock-on will see the share in question (transcode in your screenshot).
Going back to Plex, I would maybe have a look at @Hooverdan’s post linked below as he was the contributor who brought QuickSync support to Plex; they might thus have a better idea than me on what is needed.
Otherwise, I would maybe make sure the local dir looks as it should…
ls -la /dev/dri
… and that all requirements on the Plex side are met, for instance it seems you may need a Plex Pass to use the feature.
Sorry I can’t help more than that at the moment, but hopefully we’ll get to the bottom of it.
So I was able to mess around with my box a little today, I pulled the gpu since I figured there’s no point in having it in there right now if its not being utilized, but now plex has a new problem…
So when I initially ran the command
I did get a result but I didn’t screen shot or save the output, but now that I’ve taken out the gpu I get…
And plex would not install with the /dev/dri option enabled.
This is what came up on the logs.
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 127, in install
generic_install)(rockon)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 260, in generic_install
run_command(cmd, log=True)
File “/opt/rockstor/src/rockstor/system/osi.py”, line 176, in run_command
raise CommandException(cmd, out, err, rc)
CommandException: Error running a command. cmd = /usr/bin/docker run -d --restart=unless-stopped --name plex-linuxserver.io -v /mnt2/Media1:/data -v /mnt2/Plex_Config:/config -v /etc/localtime:/etc/localtime:ro --device /dev/dri -p 32400:32400/tcp -p 32400:32400/udp --net=host -e PUID=1000 -e VERSION=latest -e PGID=1000 linuxserver/plex:latest. rc = 127. stdout = [‘4b1a589b2ec4f877c45a554bb7e47ded1a6345b468537ae187bcc73b0529c243’, ‘’]. stderr = [‘/usr/bin/docker: Error response from daemon: linux runtime spec devices: error gathering device information while adding custom device “/dev/dri”: no such file or directory.’, ‘’]
I was able to get it going without the /dev/dri option though. This all happened after i removed the gpu.
Seems like we’re making progress here as if your GPU was connected during your last test, there might have been some “conflict” between GPU and the integrated GPU (iGPU) so that maybe the system was trying to use the GPU without actually having proper nvidia-runtime for it. All suppositions, though, so let’s try to see what is going on now.
As mentioned before, I unfortunately can’t try that myself as I don’t have the hardware, but from looking online, it seems like a common issue. It might be worth verifying first that the iGPU is indeed enabled in the BIOS, which should activate QuickSync and create the /dev/dri device. You can have a look at this post in the unraid forums, for instance, as it describes the case for a particular motherboard. Of course, it probably differs between motherboards, so I would thus recommend you to check the manual for yours and seek mention of Quicksync/iGPU/onboard graphics, etc…
If all seems OK from the motherboard, it seems it might be needed to activate the corresponding drivers using:
Sorry, I’m late to the discussion. I have not tried the nvidia GPU transcoding, but this is what I did for the QuickSync on my Skylake CPU. I added a transcode share in this manner:
At the file share level (though created through WebUI) that share is located at /mnt2/transcode.
In Plex I am using the standard: /transcode entry.
As soon as the transcoding is started, it will create a sub-directory named “Transcode” (note the capitalization despite the lower case config entry in Plex), and some additional sub-directories (at the least it will be the “Sessions” folder).
and in the dashboard I can see the transcoding taking place:
Only one comment on the GPU, in some of my BIOS’es of the past, I was able to explicitly enable/disable external GPU vs. using on-board GPU set. Not sure whether that might work in your case as well…
So I did everything I could in regards to setting the bios correctly to IGFX and tried
but no progress still no /dev/dri…
@Hooverdan I will try this for sure as soon as get my /dev/dri situation figured out.
Also, Ive got an m.2 SSD in the mail and will probably end up doing a fresh install of rockstor… Might go ahead and go for rockstor 4 but I’m not 100% sure yet. Maybe with a fresh install /dev/dri will show up? I appreciate everyone’s help
Only other thing I saw was that it might help if you plug a monitor into the Mobo HDMI port … though you might be doing that already, depending on whether you SSH into your server or do it all “in person” …
While this is not Windows a fresh install could solve your problems … but, as usual that’s no guarantee. BTW, my above setup is still on the Centos flavor of Rockstor, and my i3 is about 2 years older than yours …
It wouldn’t harm to try this I think and bodes better for getting any fixes in. But as indicated by @Hooverdan it’s not a pre-requisite. But if/when you discover issues they can only be addressed in the 4 + variant as that is all we are now releasing rpms for. Plus our source is no longer CentOS compatible due to breaking changes we made in our final stages towards the release candidate phase.
As always keep us informed and I’ve unfortunately go no other suggestions re the missing device that what @Flox and @Hooverdan have already put forward. But the monitor attached idea looks like a promising one.
Well I tried plugging in a displayport cable to the motherboard with no luck. My ssd gets here today so Ill install rockstor 4 on it and see how that goes. Ill Update whenever Im up and running again.
None the less all is working as it should!
On a side note, for Rockstor4 I know that its still a testing channel, but when i tried to activate my “stable subscription” I recieved an error.
Great to hear. On the transcoding share (or lack thereof), I think it means that without the transcoding share mapping, it creates the directory within the container which could pose a problem for massive transcoding activities if the Rockon is on a fairly small drive …
Cool thanks for the heads up, I went ahead and reinstalled the /transcode share to the rock on. Thanks to everyone who took the time to help me get this figured out!
a fresh install could solve your problems … but, as usual that’s no guarantee. BTW, my above setup is still on the Centos flavor of Rockstor, and my i3 is about 2 years older than yours …
