wildchild22 Posted February 14, 2016 Share Posted February 14, 2016 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. Quote Link to comment
ljm42 Posted February 14, 2016 Share Posted February 14, 2016 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. Quote Link to comment
interwebtech Posted February 14, 2016 Share Posted February 14, 2016 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. Quote Link to comment
Leifgg Posted February 14, 2016 Share Posted February 14, 2016 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. Quote Link to comment
gilahacker Posted March 3, 2016 Share Posted March 3, 2016 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. Quote Link to comment
mr-hexen Posted March 4, 2016 Share Posted March 4, 2016 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 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 Quote Link to comment
StevenD Posted March 4, 2016 Share Posted March 4, 2016 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 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! Quote Link to comment
gilahacker Posted March 4, 2016 Share Posted March 4, 2016 Based on the way Plex is calculating the required free space, i'd argue you don't have enough RAM 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. Quote Link to comment
interwebtech Posted March 4, 2016 Share Posted March 4, 2016 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. http://www.zdnet.com/article/intel-preparing-to-unveil-10tb-ssds-or-you-can-pick-up-a-13tb-drive-today/ Quote Link to comment
gilahacker Posted March 4, 2016 Share Posted March 4, 2016 What is more likely is it will be replaced sometime in the future with a 10TB SSD I picked up on Amazon for $50. I can hardly wait. :-) Quote Link to comment
ijuarez Posted April 13, 2016 Share Posted April 13, 2016 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. Quote Link to comment
mr-hexen Posted April 13, 2016 Share Posted April 13, 2016 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. Quote Link to comment
kaiguy Posted April 14, 2016 Share Posted April 14, 2016 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). Quote Link to comment
chvb Posted April 14, 2016 Share Posted April 14, 2016 Hey, thanks for this Information. I'm using Emby. The same thing here. Maybe you can change the Topic: Plex/Emby: Guide to Moving Transcoding to RAM Many thanks Quote Link to comment
WingmanNZ Posted April 14, 2016 Share Posted April 14, 2016 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 Quote Link to comment
Paul_Ber Posted April 15, 2016 Share Posted April 15, 2016 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. Quote Link to comment
ijuarez Posted April 15, 2016 Share Posted April 15, 2016 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. 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. Quote Link to comment
gilahacker Posted April 15, 2016 Share Posted April 15, 2016 Now I really want to try this once I have stupid amounts of RAM, even if it's just to see if I can make it work. Quote Link to comment
Jcloud Posted April 16, 2016 Share Posted April 16, 2016 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.# Quote Link to comment
mr-hexen Posted April 16, 2016 Share Posted April 16, 2016 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. Quote Link to comment
Jcloud Posted April 16, 2016 Share Posted April 16, 2016 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? Quote Link to comment
Squid Posted April 16, 2016 Share Posted April 16, 2016 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 Quote Link to comment
Jcloud Posted April 16, 2016 Share Posted April 16, 2016 /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). Quote Link to comment
Squid Posted April 16, 2016 Share Posted April 16, 2016 /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. Quote Link to comment
Jcloud Posted April 16, 2016 Share Posted April 16, 2016 /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. Quote Link to comment
Recommended Posts
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.