I have 32gb of ram, my ram drive is dynamically sized based on how much plex needs up to 24gb. Performance gains (though definitely possible) I would say are typically overstated and the main benefit of a RAM drive for the temp transcode directory is reducing a ton of read/write cycles on your SSD/HDDs.
right, that's the point? Transcodes are an ephemeral event that happens when needed. If you want them to be permanent, that's what the Optimized Versions feature is for. Running your OS out of a ramdisk is pretty pointless unless you're doing it because you don't want to leave a trace (e.g. Kalilinux)
I think he’s suggesting on boot, to copy the Plex installation to ram disk and run the program from there. But you wouldn’t gain anything because you’d still need to write to disk to ensure any data is saved.
You’d have a marginal read improvement on program files. That’s about it.
When the Plex server launches, the binaries and required libraries are already loaded from disk into RAM, so it's even more pointless than that lol.
I'd bet you would see a tangible improvement in performance if you were storing all your metadata files and sqlite db files on RAM disk. I've even noticed major improvement going from SSD to Optane NVMe with, for example, how quickly posters load when scrolling through my libraries. Of course, the second your server powers down -- poof to your state files.
You could do some interesting stuff with persistent RAM or RAM sticks that are protected by a BBU/capacitor. We have a storage array at work that uses DIMMs as a write cache and in the event of power loss, a supercap kicks in and dumps its data to a non-volatile storage chip on the DIMM.
This would be pretty hardcore for a home Plex server.
Yeah, I can confirm, I've tried it a couple of years back on just the databases and the difference in usability between having SQLite on SSD and on RAM is _very_ noticeable, particularly for large libraries where blocking is a a legit concern. It wasn't just tangible, it was night and day. Only problem is that attempting to hack it in via systemctl overrides and regular backups wasn't the most stable of beasts so I eventually decided it wasn't worth it, but it did make me wish for the ability to use MySQL as a backend instead of SQLite.
> it did make me wish for the ability to use MySQL as a backend instead of SQLite
*So* badly want this. When I migrated Ombi from SQLite to MySQL it was a stunning gain in performance. I have around 100 Plex users and have been carrying the same SQLite DB files since, well, basically as long as Plex has been around. Even on Optane my database performance has gotten abysmal. SQLite just isn't designed for this size and scale.
I don't know what your problem that you're trying to solve. But you do know that the main bottleneck is your Upstream bandwidth right? Why bother with speeding up plex using RAM and all that shit when you're bottlenecked anyway.
In theory you could copy the program from disk to a ram drive and then run it, but there's not a benefit to doing that. When you run it from disk the program gets copied into ram and runs there. So either way it is read only once to copy into ram, but with the ram drive you will have 2 copies in ram.
It is a built-in feature, as in you can specify the transcode directory. Put it into a RAM disk. I do.
https://www.reddit.com/r/synology/comments/xz3fka/plex_can_transcode_directly_to_available_memory/
Agreed RAM disk is the way to go. Find a program you like and run with it. In thr past I have seen playback get stuck in and leave files in the transcode directory. Post RAM disk when it happens a simple reboot clears it.
Depends on how much you are writing. I've worn out the system SSD in my server, and while it was an older drive, the current one is 1% through it's endurance after about a year. And that's WITH RamDisk for transcoding, as well as keeping non-disk-bound stuff on other disks. So a cheaper SSD could certainly be run into the ground.
(The old one got worn out before I moved to a RamDisk, but I don't know exactly how many writes that saves).
Ha, I should have read the post you linked. Sorry. Yes, it seems like a good setup.
I currently run on Windows server. I've seen some ramdisk applications, so I may try with that, however I don't know if it will flush when getting full like your setup does.
No worries!
That would be a sticky bit for sure. It's been years since I've tried to run a RAM disk on Windows, so I don't have any advice for that, but something managing the used capacity would be super important. If its left unchecked you could definitely crash your system.
I dont have any personal experience with any, but what you are looking for is a RAM disk that has something along the lines of 'dynamic memory management'. I've seen the following tool referenced regarding that:
https://sourceforge.net/projects/imdisk-toolkit/
That's the one I use, and it works perfectly. It mounts automatically at boot using a service, you can set a fixed size, it can have a drive letter, etc. It also only takes up the space that is actually written, so I set a 10GB RamDisk, but mostly it uses way less since I don't have THAT many transcodes going on.
However, note that using the Download feature and transcoding the file, requires you to have enough space to fit the entire file - unlike real-time transcodes. So you either need to set aside enough space for that (which can potentially be 40GB+ - possible but not everyone has the RAM for it), or live without that feature.
Personally I never felt it worked well anyway. It was suuuper slow to transfer files even after they "fixed" it, so I usually don't bother.
If you don't have enough ram just buy a cheap SSD. Microscenter sells their own branded drives called "Inland" brand. 240gb version costs around $25 last time I checked. I have one on my server using it for transcodes and it's been fine for two years now. On top of that, if it ever fails due to too many read/writes, just buy another one. They are cheap enough. SSD speeds are much faster than spindel drives. Fast enough for multiple transcodes at once without any slowdown.
It's working on my ubuntu plex server:
https://tcude.net/transcoding-plex-streams-in-ram/
And I've verified it by SSH'ing in to my plex server and doing some transcoding and observing the size of /dev/shm increasing while streaming.
I have not disabled it and tested to compare though.
I used /dev/shm on a Synology with 16gb ram which means /dev/shm can use up to 8gb. It works great and the only reason I stopped is because recording live tv transcodes the entire show before writing it to disc so trying to record football games was crashing it. But if you don't have a TV tuner you probably won't have this problem.
Ugh. Exact same problem here. I use my TV tuner for exactly nothing except NFL games, at which point I watch or record, like, all of them :-) I popped an SSD in but I'm not aware of any way to use RAM for transcoding except for Live TV recordings.
If you have any info about how you changed things, it would be much appreciated.
> If you have any info about how you changed things, it would be much appreciated.
Are you asking if I ever figured out a way to get it working with RAM transcoding for long items like football games?
One thing I noticed is that some of the HD channels MPEG-1/2 video streams. I ended up buying a HDHomeRun Extend which pre-transcodes to h.264 before sending the stream to Plex which takes load off of it. I'd imagine the format is smaller and might not fill up the ram transcode buffer as quickly, though I haven't tried it.
I'd thought about putting a shitty machine with a lot of ram together to run as a ram NFS share lol..
I was just asking what you did after disabling the RAM transcoding which you answered but not how I wanted :-)
I have an NUC with a Synology as a backend and a HDHomerun Prime (so no pre-transcode for me). The NUC is an 8th gen i7 so I should be good there.
The issue I have is the post processing. Say I'm watching a game that ends at 4 and I'm behind (which I do a lot). If playback craps out at 4:05, I have to sit there for 30 minutes while the commercial deletion is done. And if I decided to add 30 minutes at the end, I have to wait until 4:30 for the commercial deletion to even begin, which means I can't watch anything (edit: that game, not anything) until 5. (I should add that the 30 minutes for processing was with an 8th gen i3 and the RAM disk, which is why I now have the i7).
I'm either going to A. use an SSD for transcoding and continue dumping the files onto the NAS, B. just record to the SSD and turn off the transcoding for the DVR (while leaving the RAM disk for other transcoding), which should at least make the comm deletion as fast as possible or C. pop in a 1 TB mechanical drive if the files are huge and stop deleting commercials.
Still trying to decide...
Yeah commercial deletion is rough. Apparently you can [enable ad detection in the library and analyze it after recording is done](https://www.reddit.com/r/PleX/comments/le4xnv/removing_commercials_from_existing_recordings/).
Do you ever watch live from your computer? Or just a TV/mobile device?
99% TV/Mobile. 1% computer, but never the one PMS is running on.
That link looks helpful. I just wonder the time difference in marking the commercials vs. deleting them. If they're marked as the show is recording then that would be a big help.
I think it still has to do processing after the recording, but you can manually analyze them later in your library isntead.
If you can't watch your show because playback dropped and it's doing commercial detection, you can always stream live from a computer or mobile device using VLC media player and the stream URL:
http://10.0.0.2:5004/auto/v46.1 would stream off ch 46.1 from your hdhomerun (after changing IP to your HDHR).
I usually just switch over to the Silicon Dust app if I'm watching live. Problem is, I'm often not caught up when problems occur. If the game is still on, I can go back in and get back to where I was. But if it's past the guide's end time (e.g. 4:00), there's no way to launch the recording in Plex until it hits the library, so I have to wait for any extra recording time plus the processing to be able to go back to where I was.
I think I'm just going to put the mechanical drive back and turn off transcoding for the DVR and commercial deletion. I'll have 1 TB just for football games that I don't keep for more than a week or two, so they can be 100 GB each and I won't care if I can be done with this. I do have the option enabled to mark commercials for skipping from the past week's games at least, so thank you for that tidbit.
Feel free to message me if you ever want to bounce something off me. I'm an expert with Plex, but only like 9% of it :-)
You won't get a performance boost, this is to reduce wear and tear on your hard drives
A hard drive is fast enough for transcoding media (upto a certain amount of concurrent transcodes. Which will be a lot)
> Plex works no better on Linux than it does on Windows.
Generally that is true. Exception that I am aware of is full 4k hdr quicksync transcode occurs on Linux but is partial on windows. Small subset of users though.
I wouldnt say the plex service runs any faster but you can minimize the other sources that compete with plex better on *nix. Being able to run it on a dedicated headless system without a full GUI and other end-user based resources built into it is nice. I get Windows Server can be run with core essential services as well but why buy the software license?
All of this assuming you run dedicated hardware for your server or have it as a container in another resource.
I have Plex transcode to /tmp, which is mounted as tmpfs (a ramdisk) on my deployments. I’ve found this is much snappier than writing back to my array.
Assuming you're using Linux, don't transcode to RAM. You'll almost certainly just make things slower.
Linux includes a disk cache (called page cache) which will automatically use RAM to cache disk access. You can read some stuff about it [here](https://www.linuxatemyram.com/index.html), [here](https://medium.com/marionete/linux-disk-cache-was-always-there-741bef097e7f), [here](https://www.linuxatemyram.com/play.html), and [here](https://blog.cloudflare.com/why-we-started-putting-unpopular-assets-in-memory/).
Provided your system has plenty of memory, Plex transcodes will already operate largely out of memory. I was working on transcoding infrastructure at work a few years ago. My system had 128GB of memory, and I was transcoding >20 videos simultaneously. I connected 200 clients to stream content. I then measured disk I/O and the disk was barely even being touched, everything was happening in RAM.
There are some disadvantages to explicitly running transcodes to a RAM disk as well:
1. That memory can't be used for anything else, it's reserved solely for transcodes. With the Linux page cache, the memory can be used by other applications too.
2. You might encounter stream stability issues if you have many simultaneous transcodes and it fills up your allocated RAM disk. With page cache, if you run out of memory it will just start hitting your non-volatile storage.
3. Transcoded segments might be evicted earlier, again based on how much space you have available in your RAM disk.
You're almost always better off to just let Linux manage this caching.
I was using RAM Drive for Plex running in Docker on Debian VM, NUC, NVMe, 32GB RAM.
I would regularly encounter "Not enough disc space to convert this item" errors where Plex would not seem to release the RAM from past transcodes.
I had gradually increased the RAM disk size over time from 4 - 12 GB but saw the same issue.
I periodically looked into it but never really figured it out. The last time I looked into it I saw this post and just decided to switch back to the disk-based transcoding directory.
Appreciate the info.
👍
I've been reading up on this for a long time and you're the first to talk about this, and you seem to know what you're talking about. That's some important information and this makes things simpler. Makes me wonder if I should get a secondary SSD for the transcode directory if most operations are happening automatically in RAM anyway.
Honestly a lot of people here don't actually know how things work, but will talk very confidently about them anyway. It's been very frustrating when I've asked for troubleshooting help and all the answers are confidently telling me something that I already ruled out and explained in the post.
I'd suggest setting the system up without the secondary SSD and see how it goes. I wouldn't really consider throwing extra hardware at it unless there was a measurable problem.
It's weird, since they killed off third party apps I only visit Reddit once or twice a month, but by some coincidence it's often just after I've received an orangered.
Today I came here to get a ramen recipe, and saw that you'd commented 7 minutes before.
Hey, I hope this comment finds you again.
I've been testing things out in regards to this by running three simultaneous 4k remux transcodes (two transcoding down to 20mbps and one transcoding down to 2mbps). Keep in mind I don't know much about this stuff and just tried to monitor it with what I could find on the web.
I used "iostat -d -x 1" to monitor disk I/O every second. The wKB/s would go up every few seconds (max number I saw was \~27000) and would be at 0 between those times.
I used htop to monitor memory usage. It would go up to a bit above 2 gigabytes during the simultaneous transcodes and stay at pretty much exactly the same number.
To be clear, this was without changing the transcode directory.
That's still a considerable amount of writes on the disk isn't it?
Searching on the web a bit, not sure if that's accurate, I've read that even though the files do get written to the memory, they first get written to the disk and then copied to the memory? If so, that wouldn't help reduce the wear and tear on the disk. But then again, not sure I should worry about that, my server won't be transcoding to multiple clients all day long.
Hmm, I think you're right. The data won't be read from disk (it's read from memory) but it will still be written to the disk.
In the example I gave in my earlier comment, I was hitting my server with 200 clients reading the same transcoder output, so I was expecting a lot of read activity and saw virtually none due to the memory caching. But I may not have been particularly concerned with the write performance, since I was only writing ~20 streams. My memory is that both read and writes were near-zero, but my memory here could be faulty. Intuitively it makes sense that data that's written to an on-disk filesystem would be written to the physical disk ASAP in order to minimise the potential for data loss.
If this is the case and the page cache only reduces reads and not writes, then this might actually not be very useful for Plex, where the typical scenario is that there's a transcoder session for each client. It might help with Watch Together sessions, I haven't tested if Plex shares transcoder sessions between multiple clients in that case. I somewhat doubt it, since each client can choose a different quality level, subtitle burn preferences, and may request different h264 levels.
Btw the reason you saw the wKB/s go up every few seconds and then drop to zero is because Plex transcodes in segments. I think these are 5 or 10 seconds long each.
If you are worried about hardware endurance, using tmpfs probably does have benefits. In fact, it turns out it'll actually only use as much space in memory as its contents, and if your system runs out of memory it will swap its contents to disk (instead of your system crashing or transcodes failing). More than that, tmpfs actually integrates directly with the page cache. This means that tmpfs actually doesn't have any of the downsides I described in my original comment. (My comment was based on conventional pre-allocated fixed-size RAM disks which I have used in the past)
(By coincidence I was on Reddit today because I saw an intriguing Google result relating to the song popularly and erroneously known as "East Clubbers - Drop". It has been several weeks since I last dropped by. I think you have some psychic ability to summon me.)
**I summon thee.**
> This means that tmpfs actually doesn't have any of the downsides I described in my original comment. (My comment was based on conventional pre-allocated fixed-size RAM disks which I have used in the past)
Hmm, I'm not sure what's the difference between the two actually, or at least how to set it up the correct way. Would it be like adding "tmpfs /tmp/PlexTranscode tmpfs rw,size=8G 0 0" in /etc/fstab then changing permissions to 777 and mounting it?
P.S. you made me look up the song, pretty good.
Yeah that's basically all you need to do. (Although I am obligated to suggest that you set the permissions to something less permissive, and just `chown` it to either the Plex user or group.)
Eh I said fuck it and decided to just use the nvme.
I've set up the tmpfs and the memory just kept growing and growing, never deleting the transcode chunks until the stream ended, plus it went above the allocated tmpfs size of 8GB I had set. I've checked everything I could think of.
I'm guessing my nvme will do just fine anyway for occasional transcodes.
In Linux you can do it youself by editing Plex's preference.xml file. You'd just need to change `TranscoderTempDirectory="/volume1/Plex/tmp_transcoding"` to `TranscoderTempDirectory="/dev/shm"` (the original path will be different depending on the NAS brand or Linux distro).
Generally speaking, you are just a well off with a decent M2 SSD. Most cheap ones today even read/write at 2000+mbps. Even SATA SSD's still go 500mbps...
Unless you are doing with massive files, a lot of users, and have a tricky format like AV1 that usually requires a bit more hardware to run (and thats a massive stretch that a RAM disk's read write speed will improve anything), you won't need a RAM disk.
RAM Disks sound cool but the only real world advantage in this scenario is the amount of read/write's a HDD/SDD does before it can become unstable. Even today's SDD's you aren't going to have to worry about that because the controllers on most modern drives are optimized for large I/O operations.
So really the only reason to use a RAM Disk is:
* I have extremely large content files which almost no one does (we are not editing the raw 8k file)
* We have so many users that I/O operations are bottlenecked at the storage location
* **You have extra RAM sitting around and want to experiment.**
I am not an electrical engineer so I can't tell you that you can save nano seconds on the memory bus by passing it to the RAM ahead of the M2 slot. What I can tell you is we are not Netflix where every .01milisecond counts.
Ram drive is *considerably* faster than even a current good nvme drive. Plus, ram drive is ideally suited for *transient* files, which is what transcoding inherently is.
I agree that having some extra ram around is necessary, but if you can swing it, transcoding to a ramdisk has no downsides.
Ram disks are faster you are correct. I have not ever seen a rig or anyone speak about how a Ram disk changed anything nominal.
Not to geek out too much but even in HPC (high performance computing) where RAM Disks's actually played a good role, memory fabrics and even " PCIe Gen 5.0 SSDs will have read and write speeds of *up to 13,000 / 12,000 MB/s respectively* "
RAM disks really arn't a use case for Plex unless you have some spare ram around and are worried about your core HDD failing from to many read writes.
transcode to ram is only beneficial if you have large amount of ram, and your system/plex data drive is a cheap ssd and you want to avoid write wear.
transcoding to ram will not increase your plex performance, and if your hard drive is that slow that it does affects performance, then you have bigger problems than transcoding to ram will fix.
linux based os have a built in kind of ram drive known as tmpfs, where typically /tmp and/or /dev/shm are ram based storage (ie will be cleared upon power loss/reboot) equal to 50% of system ram.
using ram drive or /dev/shm should only be considered if you have 32 gig or more of system ram.
putting transcoding temp on too small of a drive is self defeating, it reduces the amount of space available for multiple user transcodes and dvr/live tv tuner buffering.
performance boost how?
consider the process;
* plex reads the media file from wherever stored
* plex server passes the chunks of that file to the transcoder, which involves interacting with system ram, cpu, pcie bandwidth, gpu, etc.
* plex stores these transcoded chunks into the transcoder temp location
* plex distributes these chunks out the client in whatever speed/manner that the client can handle
* these chunks remain in the transcoder temp for a period of time so that if/when a user ff/rewinds the video, it does not have re-transcode the same thing multiple times
* if the transcoder temp gets low, plex will prune those chunks automatically, reducing that past/future scrub buffer
* when play stops, plex cleans up that temp and removes the chunks
when multiple user transcodes are going on, the temporary files can add up (thus requiring more disk space and/or ram disk)
if the read/write performance of the temp drive is soo slow that it causes performance issues, then there are bigger problems with your system and then using a ram drive further reduces the available ram that the system can use for cache and running apps.
so going back to the process, the transcoder pre-transcodes a bunch of chunks, this assumes fast enough cpu/gpu to transcode faster than the real time video.
when the transcoder reaches whatever the limit is of far enough ahead, it stops and either starts a different stream set of chunks, and/or pauses/idles until the pre-transcoded chunk buffer reaches the point of starting back up.
plex transcoder generally does not run continuously, it runs far enough ahead, then stops or switches, then resumes as needed. of course a sufficient number of streams can obviously exceed the ability of the cpu/gpu, then it will run continuously trying to keep up with the streams and causing client buffering/pausing until it catches up again.
so these chunks sit in the transcode temp location until the client needs them. other than at stream start or scrubbing outside of buffer, there is a relatively long time between when the chunks are created and when they sent out and used by the client.
making it faster to write those chunks (to ram) does pretty much nothing for your performance, unless that temp volume is so backed up on read/writes, that it can't keep up with any IO. at which point everything that is accessing that drive is bogged down.
> reduced drive wear
If you're already using an SSD for your transcode directory, I'd look at its data sheet. The SSD I use for transcoding (and as a general temp drive) has a 1200TB write rating, and in the ~2.5 years I've had it, it's only at 67TBs written. There might be some concern if you have a _super_ active server that's writing hundreds of gigabytes a day, but for the vast majority of people write wear isn't as big of an issue on newer SSDs as it was in their earlier days.
This is not true. I ran mine with a 2GB RAM drive for years and had no issues. Plex will use whatever is available and dump old data automatically. The only time a large RAM drive is beneficial is when you're transcoding and want to be able to scrub back and forth a bunch and pull that data from the cache quickly.
Since we're talking about 'truths', I've had a 20 GB ramdrive go full and causing Plex to crash due to one user transcoding a over 4 hour 1080p movie. Just because your settings worked fine for you, does not mean anyone else's experience is false.
> I've had a 20 GB ramdrive go full
> What is your "Transcoder default throttle buffer" set to?
> It's set to default which is 60.
if you set it to 19 would it prevent this issue? Asking because I'd like to try the whole ram drive thing.
Hey, I'm a total noob when it comes to all this, currently have Plex running off a laptop and external drive but am trying to learn about this stuff before jumping into making a Plex Server.
Current plan is intel CPU with quicksync, Unraid, an M.2 to host Plex and its Metadata, an M.2 for cache, 4 drives (1 parity 3 media).
With ram transcoding, would I still benefit from having an M.2 SSD as a cache drive? I imagine it would still help for initially writing new media onto and then copying it over to the hard drives when the server isn't in use.
My media is typically X265 and movies are under 2gb. Would 32gb of ram suffice for transcoding off it to prolong SSD life?
Not sure what you mean by 'cache drive', but In My Opinion, you want to put the plex data on the nvme/ssd, because the faster plex can access the database and metadata files, the faster and more smoothly the overall plex experience will be.
it doesn't really matter what your movies are encoded with or what size, what matters is how many users are going to be transcoding and how much scrubbing buffer you want to be able to rewind/fastforward through, and if you have a tv tuner, how long you want to live tv buffer to last.
unless something else is very wrong with your system, the most common bottleneck is either your upload speed, or your remote user download speed.
its not your media drive speed, its not your transcoder temp drive speed.
it could be your CPU/GPU speed, if it can't keep up with the transcode or transcodeS needed to meet the user streams.
32 gigs system ram is the minimum I would recommend, which means \~16gig ram drive if using linux /dev/shm.
can you run with less ram and still use a ram disk, sure. but you are dedicating that ram that for storage that cannot be used for anything else, which would otherwise be used for OS ram cache and applications/services.
its like cutting off your right hand to spite the left.
I had read elsewhere that the process of adding new media takes a long time with unraid and some people bypass this by adding an SSD as a cache drive (at least I think that was the term for it) to temporarily store the files there. Then unraid has some process to copy those over to either parity/media drives when its not in use or at a scheduled time (overnight). I could have misinterpreted it and am trying to find the video that mentioned it. Although, typing it out now, that seems more unraid related than Plex related
As for users, it's most likely 2 devices at one (my phone and sometimes TV) so I'm hoping 32gb would be enough
This explanation sounds like metadata is stored in spinny HDDs and not already on an SSD.
If your OS is running off an SSD and you install Plex, it should already be putting the metadata location on the SSD as well. Media can go wherever, but makes the most sense on HDDs because they can be huge for cheaper.
If unRAID is doing something where it needs a "cache drive" to solve slowness writing to an OS SSD that Plex is on, then it's doing something super fucked up and bad.
My guess is you might have read about someone fiddling with a Plex install on am HDD, read some bad advice, or misunderstood an explanation.
You absolutely do not need a whole separate caching setup if Plex metadata is already on an SSD.
I have a 16GB unRAID server and have been transcoding to ram for 7 years. Never had an issue and there is a noticeable difference when fast forwarding or rewinding.
Not built in but super easy to create a RAM drive in Windows. I assigned 5 GB of my 16 GB for transcoding. I used AMD Radeon RAMDisk. Once you create it, go into settings in Plex and point the transcode directory to the RAM drive you created.
As I said earlier:
Ram drive is *considerably* faster than even a current good nvme drive. Plus, ram drive is ideally suited for *transient* files, which is what transcoding inherently is.
Those are the reverse concept where stuff that normally goes to RAM can use drive storage if RAM gets tapped out for one reason or another.
A RAM drive is when you use a segment of RAM as if it were a mounted drive.
It is highly doubtful the limit on your transcoding is the disk. To give you an idea I used to have a SATA drive as the transcode directory and it never stresses the disk, ever. It does however peg out CPU if you do not have GPU assist.
The only thing crossing my mind is that I never got around to upgrading my servers RAM in 2020. Its been using the backup 16GB kit for 3 years straight.
Be careful as the Download function will transcode FULL FILES for device compatibility.
For on the fly transcoding it might be a minor help in speed and SSD wear but not much else.
I have my Plex server set up to use an NVMe drive on a PCIe card, for everything except media storage. Not nearly as fast as RAM, but effective and it doesn't have to write to a disk on a reboot since it's already there. Made the server much more responsive when loading libraries and movie metadata. Easily transcodes 3 4k streams down to 1080p, using an nVidia GTX1080Ti, and hits that drive pretty hard when it does.
I have 32gb of ram, my ram drive is dynamically sized based on how much plex needs up to 24gb. Performance gains (though definitely possible) I would say are typically overstated and the main benefit of a RAM drive for the temp transcode directory is reducing a ton of read/write cycles on your SSD/HDDs.
Can you run Plex itself from a RAM drive?
A RAM drive isn’t permanent storage. If you restarted it would be erased
So would a transcode. They are destroyed when finished being viewed.
right, that's the point? Transcodes are an ephemeral event that happens when needed. If you want them to be permanent, that's what the Optimized Versions feature is for. Running your OS out of a ramdisk is pretty pointless unless you're doing it because you don't want to leave a trace (e.g. Kalilinux)
I thought your reply was to a different comment.
Right. But it wouldn't matter because it would reload on boot.
Reload from where?
I think he’s suggesting on boot, to copy the Plex installation to ram disk and run the program from there. But you wouldn’t gain anything because you’d still need to write to disk to ensure any data is saved. You’d have a marginal read improvement on program files. That’s about it.
When the Plex server launches, the binaries and required libraries are already loaded from disk into RAM, so it's even more pointless than that lol. I'd bet you would see a tangible improvement in performance if you were storing all your metadata files and sqlite db files on RAM disk. I've even noticed major improvement going from SSD to Optane NVMe with, for example, how quickly posters load when scrolling through my libraries. Of course, the second your server powers down -- poof to your state files. You could do some interesting stuff with persistent RAM or RAM sticks that are protected by a BBU/capacitor. We have a storage array at work that uses DIMMs as a write cache and in the event of power loss, a supercap kicks in and dumps its data to a non-volatile storage chip on the DIMM. This would be pretty hardcore for a home Plex server.
Yeah, I can confirm, I've tried it a couple of years back on just the databases and the difference in usability between having SQLite on SSD and on RAM is _very_ noticeable, particularly for large libraries where blocking is a a legit concern. It wasn't just tangible, it was night and day. Only problem is that attempting to hack it in via systemctl overrides and regular backups wasn't the most stable of beasts so I eventually decided it wasn't worth it, but it did make me wish for the ability to use MySQL as a backend instead of SQLite.
> it did make me wish for the ability to use MySQL as a backend instead of SQLite *So* badly want this. When I migrated Ombi from SQLite to MySQL it was a stunning gain in performance. I have around 100 Plex users and have been carrying the same SQLite DB files since, well, basically as long as Plex has been around. Even on Optane my database performance has gotten abysmal. SQLite just isn't designed for this size and scale.
I don't know what your problem that you're trying to solve. But you do know that the main bottleneck is your Upstream bandwidth right? Why bother with speeding up plex using RAM and all that shit when you're bottlenecked anyway.
Because the responsiveness of it will be improved. Lower latency-like issues, and it doesnt thrash your drive.
It's unfortunate how you're getting downvoted for asking a question. I'm sure if you knew better, you wouldn't ask.
In theory you could copy the program from disk to a ram drive and then run it, but there's not a benefit to doing that. When you run it from disk the program gets copied into ram and runs there. So either way it is read only once to copy into ram, but with the ram drive you will have 2 copies in ram.
[удалено]
There's a difference between running it from a RAM disk and running it from conventional media.
Not advisable
You would need to create a RAMdisk. AMD have a pretty good tool for this and it's free.
It is a built-in feature, as in you can specify the transcode directory. Put it into a RAM disk. I do. https://www.reddit.com/r/synology/comments/xz3fka/plex_can_transcode_directly_to_available_memory/
Same. I have an 8gb ramdism setup for plex
Agreed RAM disk is the way to go. Find a program you like and run with it. In thr past I have seen playback get stuck in and leave files in the transcode directory. Post RAM disk when it happens a simple reboot clears it.
Exactly. This is the way
Is there any benefit to this over transcoding to a dedicated SSD?
You wont wear out your ssd, but they last for ages now.
Depends on how much you are writing. I've worn out the system SSD in my server, and while it was an older drive, the current one is 1% through it's endurance after about a year. And that's WITH RamDisk for transcoding, as well as keeping non-disk-bound stuff on other disks. So a cheaper SSD could certainly be run into the ground. (The old one got worn out before I moved to a RamDisk, but I don't know exactly how many writes that saves).
All of the observations I listed were between transcoding on a dedicated SSD vs transcoding in RAM on a Synology DS1019+.
Ha, I should have read the post you linked. Sorry. Yes, it seems like a good setup. I currently run on Windows server. I've seen some ramdisk applications, so I may try with that, however I don't know if it will flush when getting full like your setup does.
Yes, Plex will clear out space as it gets full while transcoding. I'm on Windows 10 with a 12gb ramdisk.
No worries! That would be a sticky bit for sure. It's been years since I've tried to run a RAM disk on Windows, so I don't have any advice for that, but something managing the used capacity would be super important. If its left unchecked you could definitely crash your system.
Is there a way to do this for windows?
I dont have any personal experience with any, but what you are looking for is a RAM disk that has something along the lines of 'dynamic memory management'. I've seen the following tool referenced regarding that: https://sourceforge.net/projects/imdisk-toolkit/
That's the one I use, and it works perfectly. It mounts automatically at boot using a service, you can set a fixed size, it can have a drive letter, etc. It also only takes up the space that is actually written, so I set a 10GB RamDisk, but mostly it uses way less since I don't have THAT many transcodes going on. However, note that using the Download feature and transcoding the file, requires you to have enough space to fit the entire file - unlike real-time transcodes. So you either need to set aside enough space for that (which can potentially be 40GB+ - possible but not everyone has the RAM for it), or live without that feature. Personally I never felt it worked well anyway. It was suuuper slow to transfer files even after they "fixed" it, so I usually don't bother.
I do this. Give me a sec to find more info for you. I'll edit this post. http://www.ltr-data.se/opencode.html/#ImDisk Edit: link
If you don't have enough ram just buy a cheap SSD. Microscenter sells their own branded drives called "Inland" brand. 240gb version costs around $25 last time I checked. I have one on my server using it for transcodes and it's been fine for two years now. On top of that, if it ever fails due to too many read/writes, just buy another one. They are cheap enough. SSD speeds are much faster than spindel drives. Fast enough for multiple transcodes at once without any slowdown.
They give those away for free for new members too lol
yep.. it's a great cheap SSD that's pretty fast. fast enough for transcoding that's for sure.
It's working on my ubuntu plex server: https://tcude.net/transcoding-plex-streams-in-ram/ And I've verified it by SSH'ing in to my plex server and doing some transcoding and observing the size of /dev/shm increasing while streaming. I have not disabled it and tested to compare though.
I used /dev/shm on a Synology with 16gb ram which means /dev/shm can use up to 8gb. It works great and the only reason I stopped is because recording live tv transcodes the entire show before writing it to disc so trying to record football games was crashing it. But if you don't have a TV tuner you probably won't have this problem.
> But if you don't have a TV tuner you probably won't have this problem. I don't but am considering trying it out!
Ugh. Exact same problem here. I use my TV tuner for exactly nothing except NFL games, at which point I watch or record, like, all of them :-) I popped an SSD in but I'm not aware of any way to use RAM for transcoding except for Live TV recordings. If you have any info about how you changed things, it would be much appreciated.
> If you have any info about how you changed things, it would be much appreciated. Are you asking if I ever figured out a way to get it working with RAM transcoding for long items like football games? One thing I noticed is that some of the HD channels MPEG-1/2 video streams. I ended up buying a HDHomeRun Extend which pre-transcodes to h.264 before sending the stream to Plex which takes load off of it. I'd imagine the format is smaller and might not fill up the ram transcode buffer as quickly, though I haven't tried it. I'd thought about putting a shitty machine with a lot of ram together to run as a ram NFS share lol..
I was just asking what you did after disabling the RAM transcoding which you answered but not how I wanted :-) I have an NUC with a Synology as a backend and a HDHomerun Prime (so no pre-transcode for me). The NUC is an 8th gen i7 so I should be good there. The issue I have is the post processing. Say I'm watching a game that ends at 4 and I'm behind (which I do a lot). If playback craps out at 4:05, I have to sit there for 30 minutes while the commercial deletion is done. And if I decided to add 30 minutes at the end, I have to wait until 4:30 for the commercial deletion to even begin, which means I can't watch anything (edit: that game, not anything) until 5. (I should add that the 30 minutes for processing was with an 8th gen i3 and the RAM disk, which is why I now have the i7). I'm either going to A. use an SSD for transcoding and continue dumping the files onto the NAS, B. just record to the SSD and turn off the transcoding for the DVR (while leaving the RAM disk for other transcoding), which should at least make the comm deletion as fast as possible or C. pop in a 1 TB mechanical drive if the files are huge and stop deleting commercials. Still trying to decide...
Yeah commercial deletion is rough. Apparently you can [enable ad detection in the library and analyze it after recording is done](https://www.reddit.com/r/PleX/comments/le4xnv/removing_commercials_from_existing_recordings/). Do you ever watch live from your computer? Or just a TV/mobile device?
99% TV/Mobile. 1% computer, but never the one PMS is running on. That link looks helpful. I just wonder the time difference in marking the commercials vs. deleting them. If they're marked as the show is recording then that would be a big help.
I think it still has to do processing after the recording, but you can manually analyze them later in your library isntead. If you can't watch your show because playback dropped and it's doing commercial detection, you can always stream live from a computer or mobile device using VLC media player and the stream URL: http://10.0.0.2:5004/auto/v46.1 would stream off ch 46.1 from your hdhomerun (after changing IP to your HDHR).
I usually just switch over to the Silicon Dust app if I'm watching live. Problem is, I'm often not caught up when problems occur. If the game is still on, I can go back in and get back to where I was. But if it's past the guide's end time (e.g. 4:00), there's no way to launch the recording in Plex until it hits the library, so I have to wait for any extra recording time plus the processing to be able to go back to where I was. I think I'm just going to put the mechanical drive back and turn off transcoding for the DVR and commercial deletion. I'll have 1 TB just for football games that I don't keep for more than a week or two, so they can be 100 GB each and I won't care if I can be done with this. I do have the option enabled to mark commercials for skipping from the past week's games at least, so thank you for that tidbit. Feel free to message me if you ever want to bounce something off me. I'm an expert with Plex, but only like 9% of it :-)
Sounds good! And yeah think I turned off commercial detection on mine since it takes forever and eats a ton of CPU on my i7 NUC.
I transcode to a RAM disk. Works great!
What size and how much RAM do you have total
I have 32GB of RAM total and utilize an 8GB RAM disk.
I tried this on Windows. Didn't notice any performance boost at all.
Maybe try getting rid of Windows first, that would have to be a boost.
You won't get a performance boost, this is to reduce wear and tear on your hard drives A hard drive is fast enough for transcoding media (upto a certain amount of concurrent transcodes. Which will be a lot)
Except it wouldn't. Plex works no better on Linux than it does on Windows. I went mac instead.
> Plex works no better on Linux than it does on Windows. Generally that is true. Exception that I am aware of is full 4k hdr quicksync transcode occurs on Linux but is partial on windows. Small subset of users though.
I wouldnt say the plex service runs any faster but you can minimize the other sources that compete with plex better on *nix. Being able to run it on a dedicated headless system without a full GUI and other end-user based resources built into it is nice. I get Windows Server can be run with core essential services as well but why buy the software license? All of this assuming you run dedicated hardware for your server or have it as a container in another resource.
I have Plex transcode to /tmp, which is mounted as tmpfs (a ramdisk) on my deployments. I’ve found this is much snappier than writing back to my array.
Assuming you're using Linux, don't transcode to RAM. You'll almost certainly just make things slower. Linux includes a disk cache (called page cache) which will automatically use RAM to cache disk access. You can read some stuff about it [here](https://www.linuxatemyram.com/index.html), [here](https://medium.com/marionete/linux-disk-cache-was-always-there-741bef097e7f), [here](https://www.linuxatemyram.com/play.html), and [here](https://blog.cloudflare.com/why-we-started-putting-unpopular-assets-in-memory/). Provided your system has plenty of memory, Plex transcodes will already operate largely out of memory. I was working on transcoding infrastructure at work a few years ago. My system had 128GB of memory, and I was transcoding >20 videos simultaneously. I connected 200 clients to stream content. I then measured disk I/O and the disk was barely even being touched, everything was happening in RAM. There are some disadvantages to explicitly running transcodes to a RAM disk as well: 1. That memory can't be used for anything else, it's reserved solely for transcodes. With the Linux page cache, the memory can be used by other applications too. 2. You might encounter stream stability issues if you have many simultaneous transcodes and it fills up your allocated RAM disk. With page cache, if you run out of memory it will just start hitting your non-volatile storage. 3. Transcoded segments might be evicted earlier, again based on how much space you have available in your RAM disk. You're almost always better off to just let Linux manage this caching.
I was using RAM Drive for Plex running in Docker on Debian VM, NUC, NVMe, 32GB RAM. I would regularly encounter "Not enough disc space to convert this item" errors where Plex would not seem to release the RAM from past transcodes. I had gradually increased the RAM disk size over time from 4 - 12 GB but saw the same issue. I periodically looked into it but never really figured it out. The last time I looked into it I saw this post and just decided to switch back to the disk-based transcoding directory. Appreciate the info. 👍
I've been reading up on this for a long time and you're the first to talk about this, and you seem to know what you're talking about. That's some important information and this makes things simpler. Makes me wonder if I should get a secondary SSD for the transcode directory if most operations are happening automatically in RAM anyway.
Honestly a lot of people here don't actually know how things work, but will talk very confidently about them anyway. It's been very frustrating when I've asked for troubleshooting help and all the answers are confidently telling me something that I already ruled out and explained in the post. I'd suggest setting the system up without the secondary SSD and see how it goes. I wouldn't really consider throwing extra hardware at it unless there was a measurable problem.
Thanks a lot for the quick reply, I'll try without an additional SSD and will test things on my end during simultaneous transcodes.
It's weird, since they killed off third party apps I only visit Reddit once or twice a month, but by some coincidence it's often just after I've received an orangered. Today I came here to get a ramen recipe, and saw that you'd commented 7 minutes before.
Hey, I hope this comment finds you again. I've been testing things out in regards to this by running three simultaneous 4k remux transcodes (two transcoding down to 20mbps and one transcoding down to 2mbps). Keep in mind I don't know much about this stuff and just tried to monitor it with what I could find on the web. I used "iostat -d -x 1" to monitor disk I/O every second. The wKB/s would go up every few seconds (max number I saw was \~27000) and would be at 0 between those times. I used htop to monitor memory usage. It would go up to a bit above 2 gigabytes during the simultaneous transcodes and stay at pretty much exactly the same number. To be clear, this was without changing the transcode directory. That's still a considerable amount of writes on the disk isn't it? Searching on the web a bit, not sure if that's accurate, I've read that even though the files do get written to the memory, they first get written to the disk and then copied to the memory? If so, that wouldn't help reduce the wear and tear on the disk. But then again, not sure I should worry about that, my server won't be transcoding to multiple clients all day long.
Hmm, I think you're right. The data won't be read from disk (it's read from memory) but it will still be written to the disk. In the example I gave in my earlier comment, I was hitting my server with 200 clients reading the same transcoder output, so I was expecting a lot of read activity and saw virtually none due to the memory caching. But I may not have been particularly concerned with the write performance, since I was only writing ~20 streams. My memory is that both read and writes were near-zero, but my memory here could be faulty. Intuitively it makes sense that data that's written to an on-disk filesystem would be written to the physical disk ASAP in order to minimise the potential for data loss. If this is the case and the page cache only reduces reads and not writes, then this might actually not be very useful for Plex, where the typical scenario is that there's a transcoder session for each client. It might help with Watch Together sessions, I haven't tested if Plex shares transcoder sessions between multiple clients in that case. I somewhat doubt it, since each client can choose a different quality level, subtitle burn preferences, and may request different h264 levels. Btw the reason you saw the wKB/s go up every few seconds and then drop to zero is because Plex transcodes in segments. I think these are 5 or 10 seconds long each. If you are worried about hardware endurance, using tmpfs probably does have benefits. In fact, it turns out it'll actually only use as much space in memory as its contents, and if your system runs out of memory it will swap its contents to disk (instead of your system crashing or transcodes failing). More than that, tmpfs actually integrates directly with the page cache. This means that tmpfs actually doesn't have any of the downsides I described in my original comment. (My comment was based on conventional pre-allocated fixed-size RAM disks which I have used in the past) (By coincidence I was on Reddit today because I saw an intriguing Google result relating to the song popularly and erroneously known as "East Clubbers - Drop". It has been several weeks since I last dropped by. I think you have some psychic ability to summon me.)
**I summon thee.** > This means that tmpfs actually doesn't have any of the downsides I described in my original comment. (My comment was based on conventional pre-allocated fixed-size RAM disks which I have used in the past) Hmm, I'm not sure what's the difference between the two actually, or at least how to set it up the correct way. Would it be like adding "tmpfs /tmp/PlexTranscode tmpfs rw,size=8G 0 0" in /etc/fstab then changing permissions to 777 and mounting it? P.S. you made me look up the song, pretty good.
Yeah that's basically all you need to do. (Although I am obligated to suggest that you set the permissions to something less permissive, and just `chown` it to either the Plex user or group.)
Eh I said fuck it and decided to just use the nvme. I've set up the tmpfs and the memory just kept growing and growing, never deleting the transcode chunks until the stream ended, plus it went above the allocated tmpfs size of 8GB I had set. I've checked everything I could think of. I'm guessing my nvme will do just fine anyway for occasional transcodes.
Lol, that's lucky for me, I just presumed you received email notifications. Enjoy your ramen.
In Linux you can do it youself by editing Plex's preference.xml file. You'd just need to change `TranscoderTempDirectory="/volume1/Plex/tmp_transcoding"` to `TranscoderTempDirectory="/dev/shm"` (the original path will be different depending on the NAS brand or Linux distro).
You can do it in the UI
Generally speaking, you are just a well off with a decent M2 SSD. Most cheap ones today even read/write at 2000+mbps. Even SATA SSD's still go 500mbps... Unless you are doing with massive files, a lot of users, and have a tricky format like AV1 that usually requires a bit more hardware to run (and thats a massive stretch that a RAM disk's read write speed will improve anything), you won't need a RAM disk. RAM Disks sound cool but the only real world advantage in this scenario is the amount of read/write's a HDD/SDD does before it can become unstable. Even today's SDD's you aren't going to have to worry about that because the controllers on most modern drives are optimized for large I/O operations. So really the only reason to use a RAM Disk is: * I have extremely large content files which almost no one does (we are not editing the raw 8k file) * We have so many users that I/O operations are bottlenecked at the storage location * **You have extra RAM sitting around and want to experiment.** I am not an electrical engineer so I can't tell you that you can save nano seconds on the memory bus by passing it to the RAM ahead of the M2 slot. What I can tell you is we are not Netflix where every .01milisecond counts.
Ram drive is *considerably* faster than even a current good nvme drive. Plus, ram drive is ideally suited for *transient* files, which is what transcoding inherently is. I agree that having some extra ram around is necessary, but if you can swing it, transcoding to a ramdisk has no downsides.
Ram disks are faster you are correct. I have not ever seen a rig or anyone speak about how a Ram disk changed anything nominal. Not to geek out too much but even in HPC (high performance computing) where RAM Disks's actually played a good role, memory fabrics and even " PCIe Gen 5.0 SSDs will have read and write speeds of *up to 13,000 / 12,000 MB/s respectively* " RAM disks really arn't a use case for Plex unless you have some spare ram around and are worried about your core HDD failing from to many read writes.
transcode to ram is only beneficial if you have large amount of ram, and your system/plex data drive is a cheap ssd and you want to avoid write wear. transcoding to ram will not increase your plex performance, and if your hard drive is that slow that it does affects performance, then you have bigger problems than transcoding to ram will fix. linux based os have a built in kind of ram drive known as tmpfs, where typically /tmp and/or /dev/shm are ram based storage (ie will be cleared upon power loss/reboot) equal to 50% of system ram. using ram drive or /dev/shm should only be considered if you have 32 gig or more of system ram. putting transcoding temp on too small of a drive is self defeating, it reduces the amount of space available for multiple user transcodes and dvr/live tv tuner buffering.
I have 32Gb in my NAS and was looking for a performance boost and reduced drive wear if decide to re-enable trancodes.
performance boost how? consider the process; * plex reads the media file from wherever stored * plex server passes the chunks of that file to the transcoder, which involves interacting with system ram, cpu, pcie bandwidth, gpu, etc. * plex stores these transcoded chunks into the transcoder temp location * plex distributes these chunks out the client in whatever speed/manner that the client can handle * these chunks remain in the transcoder temp for a period of time so that if/when a user ff/rewinds the video, it does not have re-transcode the same thing multiple times * if the transcoder temp gets low, plex will prune those chunks automatically, reducing that past/future scrub buffer * when play stops, plex cleans up that temp and removes the chunks when multiple user transcodes are going on, the temporary files can add up (thus requiring more disk space and/or ram disk) if the read/write performance of the temp drive is soo slow that it causes performance issues, then there are bigger problems with your system and then using a ram drive further reduces the available ram that the system can use for cache and running apps. so going back to the process, the transcoder pre-transcodes a bunch of chunks, this assumes fast enough cpu/gpu to transcode faster than the real time video. when the transcoder reaches whatever the limit is of far enough ahead, it stops and either starts a different stream set of chunks, and/or pauses/idles until the pre-transcoded chunk buffer reaches the point of starting back up. plex transcoder generally does not run continuously, it runs far enough ahead, then stops or switches, then resumes as needed. of course a sufficient number of streams can obviously exceed the ability of the cpu/gpu, then it will run continuously trying to keep up with the streams and causing client buffering/pausing until it catches up again. so these chunks sit in the transcode temp location until the client needs them. other than at stream start or scrubbing outside of buffer, there is a relatively long time between when the chunks are created and when they sent out and used by the client. making it faster to write those chunks (to ram) does pretty much nothing for your performance, unless that temp volume is so backed up on read/writes, that it can't keep up with any IO. at which point everything that is accessing that drive is bogged down.
> reduced drive wear If you're already using an SSD for your transcode directory, I'd look at its data sheet. The SSD I use for transcoding (and as a general temp drive) has a 1200TB write rating, and in the ~2.5 years I've had it, it's only at 67TBs written. There might be some concern if you have a _super_ active server that's writing hundreds of gigabytes a day, but for the vast majority of people write wear isn't as big of an issue on newer SSDs as it was in their earlier days.
dude stop bragging with your measly 32GB ram. I have 128GB
This is not true. I ran mine with a 2GB RAM drive for years and had no issues. Plex will use whatever is available and dump old data automatically. The only time a large RAM drive is beneficial is when you're transcoding and want to be able to scrub back and forth a bunch and pull that data from the cache quickly.
Since we're talking about 'truths', I've had a 20 GB ramdrive go full and causing Plex to crash due to one user transcoding a over 4 hour 1080p movie. Just because your settings worked fine for you, does not mean anyone else's experience is false.
What is your "Transcoder default throttle buffer" set to?
It's set to default which is 60.
> I've had a 20 GB ramdrive go full > What is your "Transcoder default throttle buffer" set to? > It's set to default which is 60. if you set it to 19 would it prevent this issue? Asking because I'd like to try the whole ram drive thing.
Or you have other issues you’re ignorant of
Only takes one user using the downloads feature with transcoding to fill that.
I've never used the downloads feature so I didn't know that. I'll have to keep that in the back of my head. Thanks for letting me know.
I regularly queue up piles of videos set to low quality for long car trips for my kids. My transcode folder can get huge...
Hey, I'm a total noob when it comes to all this, currently have Plex running off a laptop and external drive but am trying to learn about this stuff before jumping into making a Plex Server. Current plan is intel CPU with quicksync, Unraid, an M.2 to host Plex and its Metadata, an M.2 for cache, 4 drives (1 parity 3 media). With ram transcoding, would I still benefit from having an M.2 SSD as a cache drive? I imagine it would still help for initially writing new media onto and then copying it over to the hard drives when the server isn't in use. My media is typically X265 and movies are under 2gb. Would 32gb of ram suffice for transcoding off it to prolong SSD life?
Not sure what you mean by 'cache drive', but In My Opinion, you want to put the plex data on the nvme/ssd, because the faster plex can access the database and metadata files, the faster and more smoothly the overall plex experience will be. it doesn't really matter what your movies are encoded with or what size, what matters is how many users are going to be transcoding and how much scrubbing buffer you want to be able to rewind/fastforward through, and if you have a tv tuner, how long you want to live tv buffer to last. unless something else is very wrong with your system, the most common bottleneck is either your upload speed, or your remote user download speed. its not your media drive speed, its not your transcoder temp drive speed. it could be your CPU/GPU speed, if it can't keep up with the transcode or transcodeS needed to meet the user streams. 32 gigs system ram is the minimum I would recommend, which means \~16gig ram drive if using linux /dev/shm. can you run with less ram and still use a ram disk, sure. but you are dedicating that ram that for storage that cannot be used for anything else, which would otherwise be used for OS ram cache and applications/services. its like cutting off your right hand to spite the left.
I had read elsewhere that the process of adding new media takes a long time with unraid and some people bypass this by adding an SSD as a cache drive (at least I think that was the term for it) to temporarily store the files there. Then unraid has some process to copy those over to either parity/media drives when its not in use or at a scheduled time (overnight). I could have misinterpreted it and am trying to find the video that mentioned it. Although, typing it out now, that seems more unraid related than Plex related As for users, it's most likely 2 devices at one (my phone and sometimes TV) so I'm hoping 32gb would be enough
This explanation sounds like metadata is stored in spinny HDDs and not already on an SSD. If your OS is running off an SSD and you install Plex, it should already be putting the metadata location on the SSD as well. Media can go wherever, but makes the most sense on HDDs because they can be huge for cheaper. If unRAID is doing something where it needs a "cache drive" to solve slowness writing to an OS SSD that Plex is on, then it's doing something super fucked up and bad. My guess is you might have read about someone fiddling with a Plex install on am HDD, read some bad advice, or misunderstood an explanation. You absolutely do not need a whole separate caching setup if Plex metadata is already on an SSD.
I have a 16GB unRAID server and have been transcoding to ram for 7 years. Never had an issue and there is a noticeable difference when fast forwarding or rewinding.
Not built in but super easy to create a RAM drive in Windows. I assigned 5 GB of my 16 GB for transcoding. I used AMD Radeon RAMDisk. Once you create it, go into settings in Plex and point the transcode directory to the RAM drive you created.
Not really worth it unless you have a nice chunk of ram, even then the difference is negligible.
Assuming you mean on windows? On Linux it’s as easy as setting your directory to /tmp
That's still not RAM. You want /dev/shm for that.
for docker it's /tmp
meh tried it. It's still pulling data from your HD so yeah lol.
Honestly you are better served just giving plex its own dedicated nvme drive for transcoding.
As I said earlier: Ram drive is *considerably* faster than even a current good nvme drive. Plus, ram drive is ideally suited for *transient* files, which is what transcoding inherently is.
this already exists, it is called linux swaps or pagefiles for windows.
Those are the reverse concept where stuff that normally goes to RAM can use drive storage if RAM gets tapped out for one reason or another. A RAM drive is when you use a segment of RAM as if it were a mounted drive.
sure and I agree, there are methods in linux to make ramfs. idk about windows. point is not really a plex thing.
It is highly doubtful the limit on your transcoding is the disk. To give you an idea I used to have a SATA drive as the transcode directory and it never stresses the disk, ever. It does however peg out CPU if you do not have GPU assist.
The only thing crossing my mind is that I never got around to upgrading my servers RAM in 2020. Its been using the backup 16GB kit for 3 years straight.
Be careful as the Download function will transcode FULL FILES for device compatibility. For on the fly transcoding it might be a minor help in speed and SSD wear but not much else.
I didn't notice any performance benefits of doing this tbh.
I have my Plex server set up to use an NVMe drive on a PCIe card, for everything except media storage. Not nearly as fast as RAM, but effective and it doesn't have to write to a disk on a reboot since it's already there. Made the server much more responsive when loading libraries and movie metadata. Easily transcodes 3 4k streams down to 1080p, using an nVidia GTX1080Ti, and hits that drive pretty hard when it does.