Server Version#: Version 4.59.2 - plexmediaserver-1.24.1.4931-1a38e63c6.x86_64
Player Version#: N/A
I transcode my video files in background to 1.5Mps/480P for external access. In order to provide as much clarity as possible, I have the transcoding parameters set as follows:
Transcoder quality: Make my CPU hurt
Background transcoding x264 preset: Very slow
Whenever the Server restarts, these values are reset to “Automatic” and “Very fast”. This causes the current set of files being transcoded to be in a questionable state, and requires that I delete them and re-transcode.
Server restarts are triggered by software upgrade, out-of-memory conditions (there’s a memory leak in the server) and, of course, server reboots. While software upgrades only happen between transcoding sessions, the out-of-memory condition can happen at any time - usually after a week or two of running.
Before anyone asks, yes, I did Save after I changed the settings.
While this should be fixed properly maybe there’s a hacky way around it. If that preference is written into a config file… you could change the owner to prevent it from being overwritten with the default values you don’t want.
If the preference only ever exists in RAM then you’re probably out of luck.
you could change the owner to prevent it from being overwritten with the default values you don’t want
That MIGHT work. Where are the config files documented? Also, how will this resolve the problem of the file not being read when the service is started?
There’s a Preferences.xml file in the main app data directory… but if those settings are even kept in there, or how they are read and written, I dunno. It’s definitely a long shot.
There’s a Preferences.xml file in the main app data directory.
I found the file (“/home/plexmediaserver/Library/Application Support/Plex Media Server/Preferences.xml”). This is the most recently saved set of settings and appears to have the information I provided.
In the same directory, there are also 1700 “older” versions of it, all at zero length. Strangely enough, they’re all dated July 26, 2020. I deleted the zero-length files. Let’s see if that helps anything.
I also found a version in “/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Preferences.xml” with the same size, content, owner, group, mode and modification date as the copy in /home.
Since you report the setting you make in the GUI doesn’t stick around after a reboot I guess there are a couple of potential problems.
Option one, when you change the setting it does not actually get written to the prefs file, so it is lost when you restart the server. If that is the case, adding it to the prefs file might fix it.
Option two, the setting is in the prefs file but it is ignored. If that is the case you are probably hosed.
I just tried changing this setting my my Ubuntu server, adding TranscoderH264OptionsOverride="slow" to my prefs file and restarting the server. After server restart, the directive was still in the file. (Some software will re-write the config file on start… had to check.)
Unfortunately in the Transcoder GUI settings, it still showed “Very fast” but it is possible that this is a display bug, or maybe “slow” isn’t working but another value would.
You could try adding that directive to the prefs file and seeing if it produced a different result even if the GUI says it didn’t change… maybe try a couple of different settings, too. I don’t have a lot of hope though.
This is what I’m seeing as well. When there are transcodes queued, those processed after the restart are done much faster, clearly indicating that the system is displaying the value being used.
Back to my OP, this is a bug, and my best guess is that this parameter, probably with a significant number of other parameters, isn’t being read at start time, or it might be being overwritten by default values after being read.
Just did this. Also /home/plexmediaserver and (just for completeness) my media directories. I don’t expect to see any change for this issue, as the owner/group/mode of the file containing the setting was correct.
