I have modified my plex transcode directory to use ram insted of slow sd card
it has led to a considerable performace gain
as pi is too slow to transcode video it has great performace for audio
Note:You should not use it if you have little available ram
everything is ram gets wiped on reboot anyways so it is a great place to transcode
mount your ram by
tmpfs /tmp tmpfs defaults,noatime,rw 0 0
Indeed, default transcode dir is on disk because for video transcoding it can easily eat some GiB. But this is exactly as well a reason why it should never be on a SDcard. Got my attention on this topic a few weeks ago and aim to find a good generic solution. Best for now IMO is to move the transcode dir to /mnt/dietpi_userdata/… so that it can be easily (which is always recommended!) moved to an external drive. 99% of cases this will be faster (even regular HDD) and will not kill your SDcard.
Then we could add some little code/tool (or add to dietpi-drive_manager) that allows to easily mount a tmpfs there (in case on lets say 2 GiB+ devices) and indeed as WarHawk suggested make use of zram. I’d use a dedicated tmpfs/zram mount btw so that it does not break regular /tmp usage, which is intended for much smaller files.
Would be great if you guys could print some sizes your transcode dir gets, so we get an overview how much RAM would be required. I see the video leaves /tmp on default size (this would be 512 MiB), but I’ve seen much larger transcode dirs. Does this depend on other PMS settings?
Please help by reporting bugs, pull-requests or feature requests!
For those interested in testing this out quickly, there is a step by step guide for getting this working on two Ubuntu machines. You can find the guide > here> .
Additionally, for proposed features and some current limitations, check out > this page.
How Does it Work?
There have been quite a few projects attempting to load balance a Plex server, most of which involve proxying HTTP requests between multiple Plex Media Server (PMS) installations. This project takes a different, and arguably easier approach that simply involves running the Plex New Transcoder on a remote host. In this setup there is only ever one PMS installation (the master node), but there can be any number of transcode hosts (slave nodes). Since transcoding is typically the most processor intensive aspect of PMS, it makes sense to be able to distribute this workload among all available computing resources.
The way this works is by replacing the default Plex New Transcoder binary on the master PMS with a wrapper. This wrapper allows us to intercept the transcode request on the master node and send it to a transcode slave node. The transcode slave invokes the true Plex New Transcoder binary, does the (trans|en)coding and saves the video segments to a network mounted shared filesystem on the master. The master then sends these segments to the client and the video is played back just like normal.
I follow the video and made provided changes. how i am able to confirm that the /tmp folder mounted on ram location.
like in linux commands LSBLK or BLKID, those show us the mounted drives with linux machine through fstab. when i give lsblk or blkid commands they show me the partition mounted Sda1, sda2 etc. but not this RAM partition. so i just want to confirm transcoding will conducted on RAM. is there any other command show me that system working according to our requirement like show /TMP folder on RAM (not on disk).
i gave your given command & it shows me /TMP folder. also just for information. in my machine there is 4GB ram & system itself allot maximum size for this to 2GB. so i think everything according to my wishes. thanks
No, /dev/dri contains the DRM interfaces, and is not a place for volatile files. Either something below /tmp or /run or a dedicated tmpfs should be used. In case of /run, the size needs to be increased as it is only 512 MiB.
Indeed a zram swap space can help if it prevents the need to use a swap file. But it slows down RAM usage as well when used. So as long as the physical memory is sufficient, I’d skip zram. If it’s getting close, I can show how to switch to a zram swap space with our tools.
The 1 btw means auto-sized here, in which case the zram space will be 50% of the physical memory in size. This means max 50% of the physical memory can be consumed for the swap space. Due to compression, practically it will only consume ~25% of the physical RAM (highly depending on the type of the swapped data), increasing your overall available memory space (compared to no swap space) to around 1.25x.