Plex: Guide to Moving Transcoding to RAM


jonp

356 posts in this topic Last Reply

Recommended Posts

Please read the last page. This is not correct.

 

Thanks for the quick reply. I changed that in Plex transcoder page but the video is not working.

 

Transcoding in RAM stopped working around Plex 0.9.14.  See the other comments on this page.

 

For more info on moving the transcoding directory, see: https://lime-technology.com/forum/index.php?topic=40937.msg419495#msg419495

 

 

You can get ram transcoding on the current dockers. You merely need your Plex properly configured.

Link to post
  • Replies 355
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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 fo

By this guide Plex uses your RAM while transcoding which prevents wearing out your SSD.   Edit the Plex Container and enable the "Advanced View":   Add this to "Extra Paramet

That should be correct, also make sure that the "Transcoder temporary directory" in Plex is set to /transcode Transcoding can require a lot of space and there might be risk of running out of RAM.

Posted Images

I do not care about new features. I would rather have an old working version for transcoding to ram.

 

I'm not convinced that it makes a big difference, but if you are sure you want to try...

 

How can we install an old plex docker image that works with ram transcoding?

 

Note: you might want to backup your Plex config folder first, in case reverting to an older version causes problems.  I offer no warranty on this :)

 

You'll need to be running the LinuxServer docker, because it allows you to specify the exact version of Plex you want to run.

 

Go here and decide which version you want to try:

  https://plex.tv/downloads/1/archive

Click the "Computer" button next to that version, then go to Linux -> Ubuntu and copy the entire "Version" string.  For instance, for 0.9.12.19 the version string is "0.9.12.19.1537-f38ac80"

 

Then go to the Volume Mappings docker page and enable the Advanced View option.  Add an Environment Variable named VERSION and paste in the value you got from the archive page.

 

Then start the Plex docker.  It should download and install the requested version.

 

 

 

Link to post

I used to use RAM for transcoding and thought I was getting the best possible performance that way BUT when the change came to Plex where it was claiming the temp folder didn't have enough room (it was seeing only whatever was reported as free space in RAM) with it showing up at my end as some titles just refused to play, I switched back to using the SSD (same as docker is installed on) and all those errors went away.

 

Now the followup to the "BUT"... when using RAM to transcode, my remote users had frequent issues with buffering and freezing. Even at relatively low settings (3 Mbps over a 30 Mbps connection). Once I switched back to using SSD, it all went away and they now can stream at higher settings with no issues.

Link to post

Its depending on what Plex container you are using if you are able of doing it or not.

 

I know that if you are using Linuxserver.io there is a possibility to do this since you can specify what version to download.

 

Edit the container, enable Advanced View, look for the Variable Name: Version and set the Variable Value: to the version you like. You can find the different versions with release notes on the Plex download page.

Plex_version.png.103c19c4eea6b97b8f367fdccdee72ba.png

Link to post
  • 3 weeks later...

My SSD is plenty fast, but transcoding in RAM would be nice just to avoid unnecessary wear on the SSD for those of us who have enough RAM.

 

Based on the way Plex is calculating the required free space, i'd argue you don't have enough RAM  :P

 

SSD's can handle the rigors of writing the transcode, most are rated at 100's of TB's before they start "dying".

 

http://www.extremetech.com/computing/201064-which-ssds-are-the-most-reliable-massive-study-sheds-some-light

Link to post

My SSD is plenty fast, but transcoding in RAM would be nice just to avoid unnecessary wear on the SSD for those of us who have enough RAM.

 

Based on the way Plex is calculating the required free space, i'd argue you don't have enough RAM  :P

 

SSD's can handle the rigors of writing the transcode, most are rated at 100's of TB's before they start "dying".

 

http://www.extremetech.com/computing/201064-which-ssds-are-the-most-reliable-massive-study-sheds-some-light

 

I would take that argument!  ;D

Link to post

Based on the way Plex is calculating the required free space, i'd argue you don't have enough RAM  :P

 

16 GB right now, which is significantly more than all but one of my current video files (because I haven't reencoded it to a reasonable size yet). I did just get a 4k TV and an Nvidia Shield Android TV, so I *might* try out some 4k videos. Planning on getting 128 GB when I upgrade later this year (yes, partially just because I can).

 

I know I'm just being paranoid about the SSD. I went with an 850 Evo instead of the Pro and, IIRC, it's rated for half as many writes by Samsung (but will likely still outlive all my spindle drives). Still... there's really no reason *not* to use the RAM if it's available. If the server crashes/loses power/whatever then that data doesn't matter anyways.

Link to post

The problem with Plex failing when using /tmp for transcodes came when the authors  decided they needed at least 3x the file size in available space as an arbitrary buffer/insurance or it would fail with message about drive being full. While they dialed it back a bit, there is no guarantee they won't do it again. As for SSD write cycles, I am pretty sure I will be long gone before I use up its "finite number" of writes. What is more likely is it will be replaced sometime in the future with a 10TB SSD I picked up on Amazon for $50. :D

 

http://www.zdnet.com/article/intel-preparing-to-unveil-10tb-ssds-or-you-can-pick-up-a-13tb-drive-today/

Link to post
  • 1 month later...

I'll set this on my PLugin as well.....

 

Did it work on your plugin? I am using Phaze's plugin, for some reason when i moved from 6.1.8 to 6.1.9 all of my BD movies will not play without buffering every 5 seconds.

 

Anyway please let me know if it worked.

Link to post

Transcoding to RAM is no longer supported in Plex as the transcode directory will no longer be configurable. This thread should be locked going forward and the OP updated accordingly.

Does anyone happen to know why the Plex devs made this change?  Seems like an unnecessary limitation without other info, as quite a few people like to configure this (heck, I even put my transcode directory on a spinner before I switched it over to RAM, since my ESXi environment had serious SSD space limitations).

Link to post

Transcoding to RAM is no longer supported in Plex as the transcode directory will no longer be configurable. This thread should be locked going forward and the OP updated accordingly.

 

It is no longer configurable via environment variable, yes, but users can still use the normal advanced setting in Plex Web to change the Transcoder temporary directory

 

https://support.plex.tv/hc/en-us/articles/200250347-Transcoder

Link to post

I asked and got a response from a Plex "Ninja" about it:

 

I got the answer that the change of transcoding directory as such will not be removed or altered, but the idea of putting the transcoding director for Plex in a RAM wasn't a good one. The output of a transcoding session can be quite large. if it fills your RAM - kernel will start killing things (but this I'm sure you already know). So I'm under the impression that there might be some sort of misunderstanding. That Plex doesn't want their software to use initramfs (as in Unraid) and possibly not even tmpfs, so that will be limited, but the actual change the location to another disk will be kept.

 

So I should remove this?  I have 32Gig of Ram.  Does the server delete the transcoded files?

My setup is like this.

ahCb11D.png

wnCk1CG.png

 

Link to post

I asked and got a response from a Plex "Ninja" about it:

 

I got the answer that the change of transcoding directory as such will not be removed or altered, but the idea of putting the transcoding director for Plex in a RAM wasn't a good one. The output of a transcoding session can be quite large. if it fills your RAM - kernel will start killing things (but this I'm sure you already know). So I'm under the impression that there might be some sort of misunderstanding. That Plex doesn't want their software to use initramfs (as in Unraid) and possibly not even tmpfs, so that will be limited, but the actual change the location to another disk will be kept.

 

So I should remove this?  I have 32Gig of Ram.  Does the server delete the transcoded files?

My setup is like this.

ahCb11D.png

wnCk1CG.png

 

It all depends where your /transcode, actually transcodes to disk or to ram.

 

I have 16GIGs of ram and following Jonp guide that once transcode would eat up about 430MB or so, I thought even if it doubles or triples i have enough ram. NOPE it choke the ram on a 720p tv show, move it back to the disk and the show played with no issues.  For me the disk is better than the ram option.

Link to post

The same idea for Emby.

 

I added container volume /transcode and /tmp/emby host path for Dockers Volume mappings. Afterwards I then had to:

[*]ssh into my unRAID: #: chown nobody:nobody /tmp/emby

[*]open Emby webui >> go to: /web/encodingsettings.html

[*]change "Transcode temporary path " to: /transcode

 

Note: one downside, if you reboot unRAID the /tmp/emby folder's ownership changes to root, so you have to go in and change ownership back to nobody.

 

#Edit: hopefully this is useful to people.#

Link to post

Note: one downside, if you reboot unRAID the /tmp/emby folder's ownership changes to root, so you have to go in and change ownership back to nobody.

 

#Edit: hopefully this is useful to people.#

 

This can be corrected in the Go file so it "appears" to be persistent on reboot.

Link to post

Note: one downside, if you reboot unRAID the /tmp/emby folder's ownership changes to root, so you have to go in and change ownership back to nobody.

 

#Edit: hopefully this is useful to people.#

 

This can be corrected in the Go file so it "appears" to be persistent on reboot.

 

Sorry for being obtuse, I still consider myself an "end user" making my way towards "power-user." Can you, or someone in the community, point me to either the Go file, or to the link of documentation which outlines the Go file (so I can RTFM)?  I'm assuming the go file is something other then rc.d scripts?

Link to post

Note: one downside, if you reboot unRAID the /tmp/emby folder's ownership changes to root, so you have to go in and change ownership back to nobody.

 

#Edit: hopefully this is useful to people.#

 

This can be corrected in the Go file so it "appears" to be persistent on reboot.

 

Sorry for being obtuse, I still consider myself an "end user" making my way towards "power-user." Can you, or someone in the community, point me to either the Go file, or to the link of documentation which outlines the Go file (so I can RTFM)?  I'm assuming the go file is something other then rc.d scripts?

/config/go on your flash drive (/boot/config/go)

 

Standard bash script.  I guess you would wind up adding these commands to it

 

mkdir -p /tmp/emby
chown nobody:nobody /tmp/emby

Link to post
/config/go on your flash drive (/boot/config/go)

 

Standard bash script.  I guess you would wind up adding these commands to it

 

mkdir -p /tmp/emby
chown nobody:nobody /tmp/emby

 

Thank you sir. Actually all that I need is line-2; if I'm remembering what occurs correctly (it's been a month since my last reboot).

Link to post

/config/go on your flash drive (/boot/config/go)

 

Standard bash script.  I guess you would wind up adding these commands to it

 

mkdir -p /tmp/emby
chown nobody:nobody /tmp/emby

 

Thank you sir. Actually all that I need is line-2; if I'm remembering what occurs correctly (it's been a month since my last reboot).

You'll need them both, because without the mkdir, when it hits the chown it will error out if the directory isn't already made (and since emhttp starts in the background and whenever it gets around to it starts up the docker apps, the odds are really against the directory existing no matter where you put the chown in the go file unless you add appropriate waits.

 

Link to post

/config/go on your flash drive (/boot/config/go)

 

Standard bash script.  I guess you would wind up adding these commands to it

 

mkdir -p /tmp/emby
chown nobody:nobody /tmp/emby

 

 

Thank you sir. Actually all that I need is line-2; if I'm remembering what occurs correctly (it's been a month since my last reboot).

You'll need them both, because without the mkdir, when it hits the chown it will error out if the directory isn't already made (and since emhttp starts in the background and whenever it gets around to it starts up the docker apps, the odds are really against the directory existing no matter where you put the chown in the go file unless you add appropriate waits.

 

Understood, but that's what I was trying to say before, /tmp/emby had stayed on reboot but the ownership reverted back to root. Minor point - the information you provided me earlier is enough for me to get that working (regardless of the actual behavior). Thanks again for your time and post.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.