Allow More Than 2 Transcodes for Downloads

Feature Suggestions
1

Transcodes for Downloads are unaffected by the “Maximum simultaneous video transcode” setting, having a hardcoded setting of ‘2’ as confirmed here.

This means that downloads are severely throttled on more-capable systems. On my server, GPU utilization is at 39% and CPU around 40% for 2x simultaneous downloads. So, to download a season of a TV show to a mobile device takes more than twice the time that it might if more resources were made available.

Two additional settings are requested:

  1. A separate, configurable “maximum simultaneous transcode” setting for ‘static transcodes’
  2. A mechanism to ‘nice’ the ‘static transcode’ processes…or at least make them nice -n 19

This limit may also be on non-linux PMS platforms.

2

Plex does not set a transcoding limit of 2. This limitation is from your Nvidia GPU as all Geforce, RTX, GTX, etc. GPUs have a hard limit of 2. If you want more than 2 with Nvidia hardware you will either need an enterprise class card or altered BIOS which are available on the web if you look (not recommended as you could brick your card). If you are running Intel, switching to the iGPU would also remove that limit and in some cases work just as well as a dedicated GPU.

3

The limit is not the GPU card itself in this case.

PMS has set the limit of 2 offline transcodes per user.

Clarification and, as necessary, enhancement has been requested.

2 Likes
4

Just to clarify this part of the request: Without using ‘nice’ on ffmpeg process for the static transcodes, it is likely to cause performance issues with other aspects of the system under high loads. Using ‘nice -n 19’ should already be the default to prevent the existing 2x transcode from overwhelming underpowered systems but they currently run at standard priority.

I will make a separate request since this aspect should be trivial to implement.

5

The request I created was for a user-facing control

“nice 7” (current setting) prevents the accidental misconfiguration from making the machine inaccessible until corrected as well as placing processes below default nice behavior.

If the machine is so heavily loaded or underpowered that nice is prevents transcoding
then perhaps the root problem (lackluster CPU/GPU) should be re-evaluated.

Abusing this request to queue 20+ requests at nice -19 is not how it should be used.
(and there are those who will try to use it that way)

6

I’m not sure I understand. For system processes that are hungry, setting nice -n19 only implies that the processor will dedicate time to those tasks as available. I don’t see where there is any use case for abuse. The ‘nice’ level is entirely arbitrary as long as it is more ‘nice’ than the main system processes. If the main Plex process has a nice level of ‘0’ as most processes do, then nice -n 7 is effectively the same as nice -n 19.

Agreed that if someone’s machine is underpowered they should re-evaluate…was just using that as an example. The same situation applies for the Most Powerful System-in-the-World™. Since the static transcodes want to happen as fast as possible, they will consume all system resources to do it. Whether the system is meek or powerful, 100% of its capacity is 100% of its capacity. It would just happen more often for the weaker system…

Limited to a maximum of 2 threads, it simply won’t have much of an impact on any system where the number of available threads is greater than two…which should be around 100% of systems running Plex. But this also has the unfortunate effect of underutilization. Hence my request.

However, if the static transcodes cap is lifted or set to user configurable, it is then easily possible to crush your own machine by simply setting the “max transcodes” allowed to be more than your available number of threads. So for a 4-core, 2-thread-per-core system, doing 9 simultaneous transcodes is guaranteed to peg-out your box.

Does this matter? It depends. If the prirority of the tasks that are hungry for resources is lower than that of your important tasks (e.g. streaming transcodes) it will greatly reduce the impact on those processes. So doing nice -n <whatever> would be beneficial here. It also should have zero negative impact. The static transcode tasks will still work at 100% utilization of the resources available…they will just politely try to not interfere with any process with a higher priority.

You indicated that a nice level of ‘7’ was the default. I’m not seeing that. For Example:

    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%▽MEM%   TIME+  Command                                                                                                                                                                                                                                                  
2523953 plex        20   0 8948M  203M  170M S  46.3  0.6  0:15.53 /usr/lib/plexmediaserver/Plex Transcoder -codec:#0x01 h264 -hwaccel:#0x01 nvdec -hwaccel_fallback_threshold:#0x01 10 -threads:#0x01 1 -hwaccel_output_format:#0x01 cuda -hwaccel_device:#0x01 cuda -codec:#0x02 aac -analyzeduration 20000000 -probesize 
1497719 plex        20   0 4934M  257M 40616 S   9.8  0.8 29:23.52 /usr/lib/plexmediaserver/Plex Media Server

This is my system doing a static transcode, the process is at that top. As you can see in column #4, the ‘nice’ level is ‘0’

Just for extra clarification…the higher the “nice” level, the more the priority of the task is lowered. Meaning nice -n 19 being the “nicest”.

Anywhichway, thank you for helping with clarification and moving this forward. It is supremely appreciated.

7

@ChuckPa - I made a separate Feature Suggestion for the nicing of static transcodes. It is much more important to me to be able to do more than 2 static transcodes than what priority they run at.

Link: Use Nice -n 19 for All Static Download Transcode Processes

8

I’m familiar with how ‘nice’ works. I’ve been developing internals and drivers for both Unix and then Linux since the early 1980’s

My reason for nice 7 is because I presumed you would want the transcode+download activities to be able to fairly compete against Scheduled Tasks
and Media Analysis / Credit detection / Intro detection all of which run at nice 7

(actual example: Friend is transferring all his data from a NAS vendor to a home-built. All that Credit and Intro detection has been running now for 6 days… 380TB of storage :wink: )

1 Like
9

Ah…it was not clear that you were talking about the request that you submitted. I thought you were talking about the current state.

I had not considered these other possibly process hungry operations and did not know that they already ran with nice -n 7. For my purposes then, I’d prefer if static transcodes were either at nice -n 6 or configurable, with a default of nice -n 7. Even better: configurable by user with a default of nice -n 7. I want MY downloads to happen when I want them. Everyone else can be patient. :wink:

@ChuckPa Also: Sorry to step on your greybeard-nerd-cred. Sometimes you have skipped over relevent bits of my posts and it has been hard to tell if you were just overstretched (which we know you are: 1,000,000 posts/day) or because didn’t have depth in those areas. Clearly, you do.

Thank you for all you do.

11

@ChuckPa - I look forward to hearing what you find out. Even if I don’t agree, it would be nice to know why there are only 2x downloads allowed.

I cannot come up with any reason why it should have a hardcoded limit. It defies logic. If server admins are deemed intelligent enough to manage the settings for streaming transcodes, they should equally be trusted with allocating resources for static transcodes, especially if given a bit of knowledge alongside. Updating the docs and saying that X, Y, and Z run with nice levels a, b, and c, by default and here are some knobs 1, 2, and 3 that you can fiddle with…

How could that be a bad thing?

Preacher → Choir, I know. But I want to capture my thoughts here publicly so others may chime in if they see this thread. Or just to lend a touch of weight from a longtime PlexPass member.

12

@ChuckPa Just checking in…did this get anywhere?

13

We’re just now getting the wind back in the sails after the big event earlier this year.

Rolling back on a point from earlier.

  1. Yes, admins should be smart enough to handle tweaking a few knobs
  2. Surprising & disturbing how some can’t correctly handle the few knobs which already exist.

I will bring this up with engineering and get status.
(Our ticket system changed since February. I need to go looking)

1 Like
14

It sure would be nice. I will cross my fingers for good news.

Here I am, getting ready to travel cross-country and downloading the latest season of my show at 27% util of my GPU and ~7% CPU, sigh. Will it get done? Sure. But wouldn’t it be nice if I could get it done 3-5x faster? Yes, please.

15

@ChuckPa Just checking in to see what the state of the union is. Any news?

16

I don’t see any activity on it but I also do not have visibility into the schedule :frowning:

I will ask at next engineering meeting.

As for now, that state of the :onion: is still :skunk: lol

1 Like
17

@ChuckPa I see that true background downloading (downloading while locked) is planned for the “new experience” (yay!) …any updates on this?

18

@McWanke: Now that background downloads has finally been knocked out, any chance this issue can get some love while people are still working on downloads?

Right now, as I type this, I am downloading a full season of a program and barely any resources are being used on my server because only 2x programs are processed at a time…It would really be nice to have a admin-adjustable setting here.