Backup/fallback OR separate transcode directories for sync/live

Feature Suggestions
,
1

For the past two years, I’ve been using linux ramdisk (/dev/shm) as the transcoder temp directory on a synology with 16gb ram which gives an incredible performance boost. In linux, half of total ram is allowed to be used as tempfs volume /dev/shm. Generally plex is very good about space management and 2-8GB will suffice for multiple transcode sessions. However a couple of situations require more space and blow the temp dir causing plex to crash or be unable to continue to transcode:

  1. Sync and download which appears to output a file to output.mkv completely before sync to the client.

  2. Recording live tv from a tuner such as a silicondust. This appears to save the entire show to transcode temp and flush to disk when recording is finished.

Some possible solutions could allow for the high performance of ram transcoding while not blowing up on the above mentioned operations:

  1. The ability to allocate a chuck of ram in plex options to be earmarked for transcoding operations before the default/specified transcode directory is used.

  2. The ability to specify two transcode directories, a primary and backup, where plex attempts to use the primary directory but falls back to the second directory when primary fills up.

  3. (most likely easiest to implement) The option to specify different transcode directories normal playback, sync, and dvr operations.

I also encourage anyone who is skeptical of the benefits of ram transcoding to try it, by pointing transcode at /dev/shm (ESPECIALLY for systems without SSDs) and restarting plex. For windows, ramdisk software would be needed. It appears that a typical transcode session involves three disk operations: transcoder reading original format, transcoder flushing transcoded media to disk, and pms reading transcoded media to stream to the user. For Plex servers with mechanical only drives, ram transcoding greatly reduces the delay in starting a transcoded media playback session and seeking (jumping 10 or 30 seconds).

2

What sort of boost are you seeing. The transcoder itself would be the bottleneck, not writing to the transcoder folder, so I’d be surprised if you actually see any noticeable difference.

3

Back when I was running all mechanical drives I definitely noticed a shorter delay in choosing media and having playback start after changing transcode to /dev/shm, also when multiple transcode sessions were running I was seeing tons of disk IO. I did add some SSD drives for the plex database, but didn’t want to use up disk endurance with transcoding since they are budget drives, so I kept that on /dev/shm.

I’ll try to do some testing later and capture some metrics.

4

+1

I made a post about issues recording DVR to ramdisk here - Is there a way to dictate settings for 'Convert Video While Recording' for DVR? Current settings are too high for me

Would really like to have config surfaced so that we can customize it.