MichaIng
DietPi-Software | Jellyfin: Web UI setup fails
Creating a bug report/issue
- [x] I have searched the existing open and closed issues
Required Information
- DietPi version |
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=12
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
- Distro version |
echo $G_DISTRO_NAME $G_RASPBIAN
bookworm
- Kernel version |
uname -a
Linux DietPi 6.1.0-34-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.135-1 (2025-04-25) x86_64 GNU/Linux
- SBC model |
echo $G_HW_MODEL_NAMEor (EG: RPi3) Native PC (x86_64) - Power supply used | (EG: 5V 1A RAVpower) Generic Power Supply
- SD card used | (EG: SanDisk ultra) Generic NVMe
Additional Information (if applicable)
- Software title | (EG: Nextcloud) Jellyfin
- Was the software title installed freshly or updated/migrated? Yes, installed freshly.
- Can this issue be replicated on a fresh installation of DietPi? Yes.
Steps to reproduce
- Install Jellyfin the official way by using DietPi Software List.
Expected behaviour
Jellyfin should be installed properly.
Actual behaviour
Jellyfin is installed a very wrong/obsolete way.
For example, it does not even install the packages, which are shown in the documentation.
Then, it needs ancient fixes, like this one.
Extra details
Most basic DietPi installation. Only installed software from official DietPi Software List, like Jellyfin, Docker and OpenSSH.
Jellyfin is installed a very wrong/obsolete way.
Can you explain in how far it is wrong/obsolete? We install the official jellyfin meta package.
For example, it does not even install the packages, which are shown in the documentation.
The docs are outdated, the jellyfin-ffmpeg5 package is not needed anymore, even problematic as in the meantime there was jellyfin-ffmpeg6 and now jellyfin-ffmpeg7. Only the meta package needs to be installed/updated.
Then, it needs ancient fixes, like https://github.com/jellyfin/jellyfin/issues/3638#issuecomment-662457950.
Hmm, this indicates that the web interface moved from /usr/lib to /usr/share at some point, but the package maintainer script did not apply the migration to the config file. Though some examples show the config file being correct, but Jellyfin still looking at the wrong place.
... I just tested it, and indeed there is a problem/bug:
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Arguments: ["/usr/lib/jellyfin/bin/jellyfin.dll", "--webdir=/usr/share/jellyfin/web", "--ffmpeg=/usr/lib/jellyfin-ffmpeg/ffmpeg"]
...
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Program data path: /mnt/dietpi_userdata/jellyfin
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Log directory path: /var/log/jellyfin
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Config directory path: /etc/jellyfin
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Cache path: /mnt/dietpi_userdata/jellyfin/cache
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Temp directory path: /tmp/jellyfin
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Web resources path: /usr/share/jellyfin/web
Apr 28 13:37:31 VM-Bookworm jellyfin[2891]: [13:37:31] [INF] Application directory: /usr/lib/jellyfin/bin/
...
Apr 28 13:37:36 VM-Bookworm jellyfin[2891]: [13:37:36] [WRN] The WebRootPath was not found: /mnt/dietpi_userdata/jellyfin/wwwroot. Static files may be unavailable.
So the web dir is applied correctly at first to /usr/share/jellyfin/web, but later the app looks for /mnt/dietpi_userdata/jellyfin/wwwroot (wwwroot within the data dir). Yeah this matches other reports. Let's see what the guys come up with: https://github.com/jellyfin/jellyfin-packaging/issues/36#issuecomment-2834998268
EDIT: Found the bug in the meantime, a mismatch between web root in configs and internally.
The docs are outdated, the
jellyfin-ffmpeg5package is not needed anymore, even problematic as in the meantime there wasjellyfin-ffmpeg6and nowjellyfin-ffmpeg7. Only the meta package needs to be installed/updated.
When ffmpeg did not work, I ran a apt install -y ffmpeg jellyfin-ffmpeg5 at once, so yeah, maybe only ffmpeg is enough, but didn't wanna try twice, so I just installed both right away. Either way, it complains about ffmpeg not being available and crashing on first run, before installing either ffmpeg. apt install also definitely installed new packages and did not say, that those were already installed.
Hmm, this indicates that the web interface moved from
/usr/libto/usr/shareat some point, but the package maintainer script did not apply the migration to the config file. Though some examples show the config file being correct, but Jellyfin still looking at the wrong place.
This is why I said it's "wrong/obselete", because the workaround I mentioned from the Jellyfin issue is from 2020, which was one year after the Jellyfin package was added to DietPi. Hence, I assumed, the DietPi Jellyfin Installation was not improved or adjusted since 2019.
So the web dir is applied correctly at first to
/usr/share/jellyfin/web, but later the app looks for/mnt/dietpi_userdata/jellyfin/wwwroot(wwwrootwithin the data dir). Yeah this matches other reports. Let's see what the guys come up with: jellyfin/jellyfin-packaging#36 (comment)
Thanks for showing me this. I thought, this was a DietPi-specific issue.
The ffmpeg package is not required at all. I guess Jellyfin is able to work with it as well, when configured correctly, but the meta package provides its own jellyfin-ffmpeg7 which is newer FFmpeg (on Debian Bookworm) and assured to work. So better use this, I mean really only the meta package. So it can move to jellyfin-ffmpeg8 once FFmpeg 8 is released and they move over.
To fix this part for you:
sudo apt install jellyfin
Really only ever this is needed, same as we do on (re)install and as the docs state now (I adjusted them).
This is why I said it's "wrong/obselete", because the workaround I mentioned from the Jellyfin issue is from 2020
There was a whole log of issues when they moved the web dir from /usr/lib to /usr/share:
- Some people had mismatching Jellyfin package, when they did not use the meta package but installed server and web separately. For them it worked to just upgrade all packages, or move to the meta package. This was the first issue you linked.
- Some had outdated
/etc/default/jellyfinentries still pointing to/usr/lib. There was probably no config migration at first, maybe not even now, it was the issue at first for the new report at the packaging repo. However, does not apply to a fresh install, of course. - And now there is this mismatch between the applied web dir and what the server is looking for. I explained it (what I think is going on) in my new comment to that issue, after investigating it a bit. So that is a new bug.
To work around the new bug:
sudo ln -s /usr/share/jellyfin /mnt/dietpi_userdata/jellyfin/wwwroot
sudo systemctl restart jellyfin
You might need to CTRL+F5 the web UI, and point it to <IP>:8097 again. It should then switch to /web subdir, which now does exist as expected.
The
ffmpegpackage is not required at all. I guess Jellyfin is able to work with it as well, when configured correctly, but the meta package provides its ownjellyfin-ffmpeg7which is newer FFmpeg (on Debian Bookworm) and assured to work. So better use this, I mean really only the meta package. So it can move tojellyfin-ffmpeg8once FFmpeg 8 is released and they move over.To fix this part for you:
apt install jellyfin
Really only ever this is needed, same as we do on (re)install and as the docs state now (I adjusted them).
This is why I said it's "wrong/obselete", because the workaround I mentioned from the Jellyfin issue is from 2020
There was a whole log of issues when they moved the web dir from
/usr/libto/usr/share:* Some people had mismatching Jellyfin package, when they did not use the meta package but installed server and web separately. For them it worked to just upgrade all packages, or move to the meta package. This was the first issue you linked. * Some had outdated `/etc/default/jellyfin` entries still pointing to `/usr/lib`. There was probably no config migration at first, maybe not even now, it was the issue at first for the new report at the packaging repo. However, does not apply to a fresh install, of course. * And now there is this mismatch between the applied web dir and what the server is looking for. I explained it (what I think is going on) in my new comment to that issue, after investigating it a bit. So that is a new bug.
After I installed Jellyfin via DietPi software installation, which apparently only installs the jellyfin meta-package, I created the symlink for the workaround and after that, I tried to run Jellyfin, which complained about FFMPEG missing, which it crashed for. So, something's not right or does the DietPi installation not install the jellyfin meta-package? I mean, Jellyfin runs, after I manually install FFMPEG.
Please do this again:
sudo apt install jellyfin # this should install jellyfin-ffmpeg7
sudo ln -s /usr/share/jellyfin /mnt/dietpi_userdata/jellyfin/wwwroot
sudo systemctl restart jellyfin
You might need to CTRL+F5 the web UI, and point it to <IP>:8097 again. It should then switch to /web subdir, which now does exist as expected.
... ah wait, nah this does not work that great either. I need to access http://<IP>:8097/web/#/wizardstart.html in my case to actually access the setup wizard. From that point on, it however works for me, i.e. after initial setup has been done, http://<IP>:8097 works as expected. Just tested with a fresh install on DietPi.
root@host:~# apt policy jellyfin
jellyfin:
Installed: (none)
Candidate: 10.10.7+deb12
Version table:
10.10.7+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
10.10.6+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
10.9.10+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
root@host:~# apt remove jellyfin-ffmpeg5
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
jellyfin-server jellyfin-web
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
jellyfin-ffmpeg5
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 194 MB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 52248 files and directories currently installed.)
Removing jellyfin-ffmpeg5 (5.1.4-3-bookworm) ...
Processing triggers for libc-bin (2.36-9+deb12u10) ...
root@host:~# apt install -y jellyfin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
jellyfin-ffmpeg7
The following NEW packages will be installed:
jellyfin jellyfin-ffmpeg7
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 44.8 MB of archives.
After this operation, 210 MB of additional disk space will be used.
Get:1 https://fra1.mirror.jellyfin.org/files/debian bookworm/main amd64 jellyfin-ffmpeg7 amd64 7.1.1-1-bookworm [44.8 MB]
Get:2 https://repo.jellyfin.org/debian bookworm/main amd64 jellyfin all 10.10.7+deb12 [2,434 B]
Fetched 44.8 MB in 2s (20.7 MB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package jellyfin-ffmpeg7.
(Reading database ... 52132 files and directories currently installed.)
Preparing to unpack .../jellyfin-ffmpeg7_7.1.1-1-bookworm_amd64.deb ...
Unpacking jellyfin-ffmpeg7 (7.1.1-1-bookworm) ...
Selecting previously unselected package jellyfin.
Preparing to unpack .../jellyfin_10.10.7+deb12_all.deb ...
Unpacking jellyfin (10.10.7+deb12) ...
Setting up jellyfin-ffmpeg7 (7.1.1-1-bookworm) ...
Setting up jellyfin (10.10.7+deb12) ...
Processing triggers for libc-bin (2.36-9+deb12u10) ...
...
...
...
[10:58:45] [INF] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: FFmpeg: ffmpeg [10:58:45] [INF] [1] Emby.Server.Implementations.ApplicationHost: ServerId: 93e74acadd8e424aa43ac337edc2e6e4
[10:58:45] [INF] [1] Emby.Server.Implementations.ApplicationHost: Core startup complete
[10:58:45] [INF] [1] Main: Startup complete 0:00:03.9387027
[10:58:47] [INF] [16] Emby.Server.Implementations.ScheduledTasks.TaskManager: Clean Transcode Directory Completed after 0 minute(s) and 0 seconds
[10:58:47] [INF] [11] Emby.Server.Implementations.ScheduledTasks.TaskManager: Clean up collections and playlists Completed after 0 minute(s) and 0 seconds
[10:58:47] [INF] [17] Emby.Server.Implementations.ScheduledTasks.TaskManager: Update Plugins Completed after 0 minute(s) and 0 seconds
^C[11:00:04] [INF] [18] Emby.Server.Implementations.Session.SessionManager: Sending shutdown notifications
[11:00:04] [INF] [8] Jellyfin.Networking.PortForwardingHost: Stopping NAT discovery
[11:00:04] [INF] [8] Main: Running query planner optimizations in the database... This might take a while
[11:00:04] [INF] [8] Emby.Server.Implementations.ApplicationHost: Disposing CoreAppHost
[11:00:04] [INF] [8] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzArtistProvider
[11:00:04] [INF] [8] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzAlbumProvider
[11:00:04] [INF] [8] Emby.Server.Implementations.ApplicationHost: Disposing PluginManager
root@host:~# apt remove ffmpeg
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
libavc1394-0 libavdevice59 libcaca0 libcdio-cdda2 libcdio-paranoia2 libdc1394-25 libdecor-0-0 libiec61883-0 libjack-jackd2-0 libopenal-data libopenal1 libraw1394-11 libsdl2-2.0-0 libxss1
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
ffmpeg
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 2,437 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 52266 files and directories currently installed.)
Removing ffmpeg (7:5.1.6-0+deb12u1) ...
...
...
...
[11:00:16] [ERR] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: FFmpeg: Failed version check: ffmpeg
[11:00:16] [ERR] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: FFmpeg: Path set by system $PATH is invalid
[11:00:16] [FTL] [1] Main: Error while starting server
MediaBrowser.Common.FfmpegException: Failed to find valid ffmpeg
at Emby.Server.Implementations.ApplicationHost.RunStartupTasksAsync()
at Jellyfin.Server.Program.StartServer(IServerApplicationPaths appPaths, StartupOptions options, IConfiguration startupConfig)
[11:00:16] [INF] [1] Main: Running query planner optimizations in the database... This might take a while
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing CoreAppHost
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzArtistProvider
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzAlbumProvider
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing PluginManager
root@host:~# apt policy jellyfin
jellyfin:
Installed: 10.10.7+deb12
Candidate: 10.10.7+deb12
Version table:
*** 10.10.7+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status
10.10.6+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
10.9.10+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
root@host:~# owser.Common.FfmpegException: Failed to find valid ffmpeg
at Emby.Server.Implementations.ApplicationHost.RunStartupTasksAsync()
at Jellyfin.Server.Program.StartServer(IServerApplicationPaths appPaths, StartupOptions options, IConfiguration startupConfig)
[11:00:16] [INF] [1] Main: Running query planner optimizations in the database... This might take a while
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing CoreAppHost
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzArtistProvider
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzAlbumProvider
[11:00:16] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing PluginManager
root@host:~# apt policy jellyfin
jellyfin:
Installed: 10.10.7+deb12
Candidate: 10.10.7+deb12
Version table:
*** 10.10.7+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status
10.10.6+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
10.9.10+deb12 500
500 https://repo.jellyfin.org/debian bookworm/main amd64 Packages
root@host:~#
Please check your /etc/jellyfin/encoding.xml. There is should say:
<EncoderAppPathDisplay>/usr/lib/jellyfin-ffmpeg/ffmpeg</EncoderAppPathDisplay>
I guess this is adjusted when it finds /usr/bin/ffmpeg, and it seems to not automatically look for the own FFmpeg executable anymore.
This is, what it says in my configuration. Copied it right out of there.
<EncoderAppPathDisplay>/usr/lib/jellyfin-ffmpeg/ffmpeg</EncoderAppPathDisplay>
Seems, like this corresponds to what you showed.
Hmm, then it seems the (now wrong) path is stored somewhere else in a database or what. This is the only place I could find it in config files. Just to be sure, that one exists, right?
/usr/lib/jellyfin-ffmpeg/ffmpeg -version
Ah wait, there is another place:
grep 'JELLYFIN_FFMPEG_OPT=' /etc/default/jellyfin
You did restart the server in between?
systemctl restart jellyfin
root@host:~# systemctl restart jellyfin
root@host:~# jellyfin
[12:53:22] [INF] [1] Main: Jellyfin version: 10.10.7
[12:53:22] [INF] [1] Main: Environment Variables: ["[JELLYFIN_LOG_DIR, /root/.local/share/jellyfin/log]"]
[12:53:22] [INF] [1] Main: Arguments: ["/usr/lib/jellyfin/bin/jellyfin.dll"]
[12:53:22] [INF] [1] Main: Operating system: Debian GNU/Linux 12 (bookworm)
[12:53:22] [INF] [1] Main: Architecture: X64
[12:53:22] [INF] [1] Main: 64-Bit Process: True
[12:53:22] [INF] [1] Main: User Interactive: True
[12:53:22] [INF] [1] Main: Processor count: 4
[12:53:22] [INF] [1] Main: Program data path: /root/.local/share/jellyfin
[12:53:22] [INF] [1] Main: Log directory path: /root/.local/share/jellyfin/log
[12:53:22] [INF] [1] Main: Config directory path: /root/.config/jellyfin
[12:53:22] [INF] [1] Main: Cache path: /root/.cache/jellyfin
[12:53:22] [INF] [1] Main: Temp directory path: /tmp/jellyfin
[12:53:22] [INF] [1] Main: Web resources path: /usr/lib/jellyfin/bin/jellyfin-web
[12:53:22] [INF] [1] Main: Application directory: /usr/lib/jellyfin/bin/
[12:53:22] [INF] [1] Jellyfin.Server.Migrations.MigrationRunner: Marking following migrations as applied because this is a fresh install: ["CreateNetworkConfiguration", "MigrateMusicBrainzTimeout", "MigrateNetworkConfiguration", "MigrateEncodingOptions"]
[12:53:22] [INF] [1] Emby.Server.Implementations.AppBase.BaseConfigurationManager: Setting cache path: /root/.cache/jellyfin
[12:53:22] [INF] [1] Emby.Server.Implementations.ApplicationHost: Loading assemblies
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN subnets: ["127.0.0.1/8", "10.0.0.0/8", "172.12.0.0/12", "192.128.0.0/12"]
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions: []
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Used LAN subnets: ["127.0.0.1/8", "10.0.0.0/8", "172.12.0.0/12", "192.128.0.0/12"]
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered interface addresses: ["127.0.0.1", "192.128.178.39"]
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Bind Addresses ["0.0.0.0"]
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Remote IP filter is Allowlist
[12:53:22] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered subnets: []
[12:53:24] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded plugin: TMDb 10.10.7.0
[12:53:24] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded plugin: Studio Images 10.10.7.0
[12:53:24] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded plugin: OMDb 10.10.7.0
[12:53:24] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded plugin: MusicBrainz 10.10.7.0
[12:53:24] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded plugin: AudioDB 10.10.7.0
[12:53:24] [INF] [1] Jellyfin.Server.Migrations.MigrationRunner: Marking following migrations as applied because this is a fresh install: ["DisableTranscodingThrottling", "CreateLoggingConfigHeirarchy", "MigrateActivityLogDatabase", "RemoveDuplicateExtras", "MigrateUserDatabase", "MigrateDisplayPreferencesDatabase", "RemoveDownloadImagesInAdvance", "MigrateAuthenticationDatabase", "FixPlaylistOwner", "MigrateRatingLevels", "FixAudioData", "RemoveDuplicatePlaylistChildren"]
[12:53:24] [INF] [1] Main: Kestrel is listening on 0.0.0.0
[12:53:24] [ERR] [1] Jellyfin.Networking.AutoDiscoveryHost: Unable to bind to 0.0.0.0:7359
System.Net.Sockets.SocketException (98): Address already in use
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at Jellyfin.Networking.AutoDiscoveryHost.ListenForAutoDiscoveryMessage(IPAddress listenAddress, CancellationToken cancellationToken)
[12:53:25] [WRN] [1] Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware: The WebRootPath was not found: /root/wwwroot. Static files may be unavailable.
[12:53:25] [INF] [1] Emby.Server.Implementations.ApplicationHost: Running startup tasks
[12:53:25] [INF] [1] Emby.Server.Implementations.ScheduledTasks.TaskManager: Daily trigger for Generate Trickplay Images set to fire at 2025-04-29 03:00:00.000 +02:00, which is 10:06:34.9050939 from now.
[12:53:25] [INF] [1] Emby.Server.Implementations.ScheduledTasks.TaskManager: Daily trigger for Extract Chapter Images set to fire at 2025-04-29 02:00:00.000 +02:00, which is 09:06:34.9011885 from now.
[12:53:25] [ERR] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: Error validating encoder
System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'ffmpeg' with working directory '/root'. No such file or directory
at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
at MediaBrowser.MediaEncoding.Encoder.EncoderValidator.GetProcessOutput(String path, String arguments, Boolean readStdErr, String testKey)
at MediaBrowser.MediaEncoding.Encoder.EncoderValidator.ValidateVersion()
[12:53:25] [ERR] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: FFmpeg: Failed version check: ffmpeg
[12:53:25] [ERR] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: FFmpeg: Path set by system $PATH is invalid
[12:53:25] [FTL] [1] Main: Error while starting server
MediaBrowser.Common.FfmpegException: Failed to find valid ffmpeg
at Emby.Server.Implementations.ApplicationHost.RunStartupTasksAsync()
at Jellyfin.Server.Program.StartServer(IServerApplicationPaths appPaths, StartupOptions options, IConfiguration startupConfig)
[12:53:25] [INF] [1] Main: Running query planner optimizations in the database... This might take a while
[12:53:25] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing CoreAppHost
[12:53:25] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzArtistProvider
[12:53:25] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing MusicBrainzAlbumProvider
[12:53:25] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing PluginManager
root@host:~# grep 'JELLYFIN_FFMPEG_OPT=' /etc/default/jellyfin
JELLYFIN_FFMPEG_OPT="--ffmpeg=/usr/lib/jellyfin-ffmpeg/ffmpeg"
root@host:~# /usr/lib/jellyfin-ffmpeg/ffmpeg -version
ffmpeg version 7.1.1-Jellyfin Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto=auto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-opencl --enable-libdrm --enable-libxml2 --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libharfbuzz --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libsvtav1 --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-vaapi --enable-amf --enable-libvpl --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100
You cannot start jellyfin like this with this command. The service started it correctly already. Check the service logs:
journalctl -u jellyfin
Uh, checking the output with the port conflict, you tried it already like this before? Please kill all possibly accumulated Jellyfin instances, then restart the service and check its logs:
killall -w jellyfin
systemctl restart jellyfin
sleep 15
journalctl -u jellyfin
Now, when applying all the fixes from this thread, it seems to work. Kind of forgot how complicated everything is, when not using containers.
So, what needs to be updated in the DietPi Installation for Jellyfin? It needs to install the jellyfin meta-package, then apply the aforementioned symbolic links?
Whether container or systemd unit or anything else, it always needs to be started/invoked the correct way. In case of Jellyfin, it autostarts via systemd unit, same as a Docker container does, so nothing else needs to be done.
The dietpi-software install option is 100% correct, nothing needs to be adjusted. The bug you run into is because of an internal Jellyfin bug, which needs to be resolved their end. What we did here was a workaround which works ... sort of, but not well enough to apply it to our code.
The FFmpeg issue was only because you installed the jellyfin-ffmpeg5 package in between (as of outdated info in our docs, fixed already) and then the ffmpeg package. Installing the jellyfin meta package again fixed things, probably just the service restart was outstanding.
Whether container or systemd unit or anything else, it always needs to be started/invoked the correct way. In case of Jellyfin, it autostarts via systemd unit, same as a Docker container does, so nothing else needs to be done.
I checked out the Systemd file. It runs with specific arguments, taken from the environment file. Such arguments are already given to containers, without me applying them manually on the CLI.
I specifically referred to the fact, that you have to check out things in different places, like the SystemD unit file, those Jellyfin paths, etc... It's all scattered around the system. Difficult to follow intuitively, especially after the path changes. Even more so, since there might be differences between OS distributions and versions, etc. When using containers, all this wouldn't have happened. This issue wouldn't even exist, because we would use the official Jellyfin image, which is up to date and maintained and guaranteed to follow originally Java's slogan of "write once, run anywhere". ;)
The
dietpi-softwareinstall option is 100% correct, nothing needs to be adjusted. The bug you run into is because of an internal Jellyfin bug, which needs to be resolved their end. What we did here was a workaround which works ... sort of, but not well enough to apply it to our code.The FFmpeg issue was only because you installed the
jellyfin-ffmpeg5package in between (as of outdated info in our docs, fixed already) and then theffmpegpackage. Installing thejellyfinmeta package again fixed things, probably just the service restart was outstanding.
Okay, I see now. Well, thanks for your help! It is much appreciated, as always. :)
The container starts a whole OS around Jellyfin, including FFmpeg, a service manager, config files which contain these arguments and invokes the jellyfin command just the same way the systemd unit does with its one service file. In that way, the container is the same blackbox for you than the systemd unit is, both start automatically, can be controlled (via docker command resp. via systemctl command), and do the invocation correctly, based on config files you do not need to adjust at all. It really is just a question of what you are used to, but a Docker container with the whole engine around adds a lot more points of failures (which we need to deal with on a regular basis here or on our forum) and consumes a lot more RAM and disk space, of course as it starts a somewhat full OS environment.
All those things we checked was only needed because of the internal but, while each and every config file in fact did contain the correct/intended values. You probably don't know the mess it creates when a Docker container fails as of internal or environment issues, with its multiple layers down to the way it actually stores the image and variable data, in volumes, in the overlayfs etc. Of course usually it works well, same as usually an APT packaged software setup works well, in both cases it is the responsibility of the respective maintainers. For developers it is sometimes easier to do this with containers, as they do not need to worry about different OS environments anymore, at least until the used base image needs to be updated and has undergone some major changes (like Debian Bullseye => Trixie or such). In our case we however know it is Debian, which is pretty stable, and Jellyfin does provide the (official and always up-to-date) distro version-specific APT packages, and an own official script which does the whole installation/setup (which I tested as well, which does the same as dietpi-software and currently fails the same way). Same can happen with a faulty Docker images, and it regularly does, but more importantly Docker itself can fail for various reasons as well, especially when using ARM and RISC-V SBCs, anything that does not use somewhat standardized kernel builds.
So that impression that Docker/containers would be somewhat easier, is not really true when looking at one known Linux distro to run software on. I can say this from our own support experience, and from bugs I followed or reported and by times fixed myself in 3rd party Docker images as well as Docker install script and Docker engine, and even containerd. And I do not even want to start talking about Kubernetes, snaps and others 😅.
Let me open the issue again, to have an anchor here keeping track of the upstream issue. If this is not fixed until our next Release, we'd need to do something about it.
yap I remember the day where Docker software themselves introduced a bug on their engine causing containers to fail. Some people lost their entire home lab just because of a single software bug. Docker is a great thing, but it also has one or two pitfalls.
One thing I still cannot wrap my head around is why there is no sane internal update method, and watchtower as 3rd party solution causes its very own issues with the changed tags and accumulated old image remains. Compared to apt upgrade, for users new to this, keeping Docker images up-to-date really is much too complicated 😄. And no way to get somehow informed about updated images either, while package managers can do checks and even upgrades all automatically with internally managed methods.
On our own server, I just needed to manually "fix" again some problematic logging behavior of the Discourse (forum) container:
- Every 20 seconds it creates a log entry about some checkpoint start/completed stuff, which appeared newly after a recent container update, spamming the system log massively, which we want to have persistent as of the severity of the server. It looks like this:
Apr 28 17:55:18 dietpi.com 6b97a58223b4[2757]: 2025-04-28 15:55:18.306 UTC [69] LOG: checkpoint starting: time Apr 28 17:55:35 dietpi.com 6b97a58223b4[2757]: 2025-04-28 15:55:35.288 UTC [69] LOG: checkpoint complete: wrote 170 buffers (0.5%); 0 WAL file(s) added, 0 removed, 0 recycled; write=16.972 s, sync=0.005 s, total=16.982 s; sync files=56, longest=0.001 s, average=0.001 s; distance=949 kB, estimate=6873 kB - First I though it would be coming from the Docker engine, as it has a new checkpoint feature, which is however experimental and should be disabled: https://docs.docker.com/reference/cli/docker/checkpoint/
- It took a while before I found out that it is coming from PostgreSQL within the container, as of PostgreSQL 15. Usually, users would be screwed then, without knowing how to access the container, which is not really intended either, and changes overwritten with every container update. Of course one can report to container maintainers, same as we did now to Jellyfin packaging maintainers, really same things when problems appear.
- Luckily, Discourse provides own scripts to access the container-internal console, to be able to edit the PostgreSQL config file and disable checkpoint logs there. And with the container YAML for their own build/update container and scripts they provide, it is possible to apply changes to internal files as part of the container update. But that is only as Discourse provides and maintains all the scripts for this, wrapped around the rudimentary Docker CLI features.
- In this case, as Discourse is VERY complex, with database server, caching server, proxy/web server, Ruby/unicorn actual Discourse server, with dedicated background handlers etc etc. So this is an example which cannot be served with APT packages, with all the setup needed to make all those parts work together. So an example where a container perfectly makes sense. But the whole set of scripts + a completely dedicated container which exists only to create and setup the actual Discourse container, is VERY complex as well, not trivial to understand and learn how to work with. So the one way or the other, developers/maintainers as well as admins/users do have to deal with this complexity, and the issues it implies. In this case, the container helps, but it still has a lot of host-side configs and scripts and stuff to get used to, and where things can be done wrong/go wrong.