mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-02-28 11:20:28 +03:00
Jellyfin ignoring --ffmpeg CLI option #2248
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @spacekookie on GitHub (Nov 9, 2020).
Describe the bug
I'm running jellyfin on a NixOS system, meaning that my paths don't work the same way as on other Linux systems. For that reason, there is a wrapper script that makes sure to pass the correct
ffmpegpath to jellyfin via the--ffmpegoption.I have recently run into issues because this path is not persisted in the jellyfin configuration (
/var/lib/jellyfin/config/encoding.xml), or even used.It looks like the first time jellyfin started it persisted a path to this config, and has not updated it since. This is now causing issues while transcoding on my system.
System (please complete the following information):
To Reproduce
--ffmpegflagExpected behavior
For one, I am surprised that the path provided via the
--ffmpegflag is persisted into the configuration at all. But even if it is, I feel like the--ffmpegCLI flag should take precedence over the existing configuration.Logs
Here are the logs from startup: https://paste.rs/V9Q
@stale[bot] commented on GitHub (Mar 20, 2021):
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.
@alarsyo commented on GitHub (Apr 4, 2021):
This issue still affects me!
@joshuaboniface commented on GitHub (Apr 4, 2021):
Copying this in from the PR for posterity:
Based on some discussion and code analysis, we think we know what's happening here.
The
--ffmpegoption is specified at startup which populates the "default".When the "Transcoding" configuration is loaded in the WebUI, we populate the "default" value of the CLI flag into the UI.
If those settings are then saved, the configuration value populated by
--ffmpegis then saved into the configuration file (system.xml).The
system.xmlconfig then overrides the--ffmpegoption on next startup (by design as mentioned), and thus future changes to--ffmpegare not respected.Thus ultimately, I think this is a bug in the handling of the configuration UI. If we load in the "default" CLI flag, it shouldn't be populated as if it was entered by the user. How to actually fix that I'm not certain.
As a short-term fix, you can manually edit
config.xmlto remove the set value and then reload, which will allow the--ffmpegoption to be respected again. But, on any future save of the "Transcoding" page, it would return, so we'll have to address that. Ultimately though based on this, I don't think the underlying issue has anything to do with the config parsing here, just the saving of the network page. We're still discussing alternative solutions to that issue though.@joshuaboniface commented on GitHub (Apr 4, 2021):
In my opinion, the ideal fix consists of three parts:
We add a way to show the currently-configured FFmpeg (whether it's the default via
--ffmpeg, found on the$PATH, or manually configured in the UI) somewhere in the admin dashboard. I think putting it in the Paths sections of the main dashboard, or as a read-only area on the Transcoding page above or below the input box, are good options for this, the latter being my ideal preference. It could also, ideally, show "where" this is from, but that might be harder.We adjust the name of the configuration field to "Override FFmpeg path" to make it clear what it's for: overriding the "default" specified by the package maintainer or found on the operating system $PATH.
We then never populate the configuration field from the default. If this configuration field is empty, the XML config option for an FFMpeg path will be removed (or, not set, if it doesn't exist yet). This will preserve all the intended behaviour -
--ffmpegwill be respected unless the admin overrides it explicitly, across reboots, while allowing the admin to set and reset an override path to ffmpeg.@joshuaboniface commented on GitHub (Apr 6, 2021):
From some further discussions, it seems like setting the value to be a
.display(I forget the exact name) instead of an actual value is a viable and good solution here. That would pretty much solve the problem without introducing any changes that might affect the intended behaviour. Awaiting a PR to that effect.@alarsyo commented on GitHub (Apr 6, 2021):
I'll see what I can do :)
@AkechiShiro commented on GitHub (Apr 30, 2021):
I've recently hit this issue as well just saying.
@stale[bot] commented on GitHub (Sep 22, 2021):
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.