You are not logged in.

#1 2021-09-05 13:47:49

rbh
Moderator
From: Sweden/Vasterbotten/Rusfors
Registered: 2016-08-11
Posts: 1,190

Jellyfin

(In a thread from "Completely Off Topic Chat"

twoion wrote:

Before, I just used a SMB share to expose my library to different kinds of end devices on the LAN but the Jellyfin experience with search, library interface, app convenience etc is just superior.

That has been my strategy too, not satisfied with it, but has not taken timeto investigate better options. Has now installed Jellyfin and realey likes it.

If you try it you definitely should use the container image instead of bare metal, this way it really becomes a matter of passing it a config and cache directory to use, here's my preliminary script:

#/usr/bin/env bash
podman run                             \
  --rm                                 \
  --name jellyfin-server               \
  -p 8096:8096 \
  -p 8920:8920 \
  -p 1900:1900/udp \
  -p 7359:7359/udp \
  -v /mnt/t/jellyfin/config:/config:rw \
  -v /mnt/t/jellyfin/cache:/cache:rw   \
  -v /mnt/t/video:/media:ro            \
  jellyfin/jellyfin

Can you explain the differences and benefits?
If I want to try your solution, I just install package podman on the server and run your script on the server, substituting  "/mnt/t/jellyfin/" with what? /var/lib/jellyfin?
Have you created a continer at /mnt/t/jellyfin/?

I've never worked with containers.Have installed podman from debian repo and feels a little lost...

The first thre lines is it to start a container, "make it empty" (--rm) and start jellefin-server?

Should I then in systemd disable jellyfin.service?


// Regards rbh

Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu

Offline

#2 2021-09-05 16:30:34

twoion
一期一会
Registered: 2015-08-10
Posts: 3,322

Re: Jellyfin

For multimedia applications / everything that has to do with the graphics stack, in my experience, you want to run the latest software stack there is. In the case of jellyfin, this means that the container image packages the latest ffmpeg confirmed working (unlike Debian) with possibly more (non-free) codec support (Debian likes to play with compile time options) which is important for transcoding/remuxing and in upstream quality (Debian likes to patch its packages to death, completely arbitrary at times). Though if jellyfin works alright for you as packaged by Debian, there is no real categorical reason to deviate from it. If you have the appropriate hardware, jellyfin can also make use of hardware acceleration for e.g. transcoding video directly on the GPU, which I guess will also be easier to get working when not running with an additional layer of isolation.

For using the container, you can just follow the upstream documentation of jellyfin: https://jellyfin.org/docs/general/admin … lling.html wherein the difference between podman and docker is that both are container management tools (like firejail & systemd-run) but podman is slated to replace docker --- it supports daemonless, rootless containers, unlike docker's containerd. Plugging podman here is just my personal preference. The CLI commands of docker and podman are largely equivalent, reflecting an attempt to make podman work as a drop-in replacement as well as possible.

If I want to try your solution, I just install package podman on the server and run your script on the server, substituting  "/mnt/t/jellyfin/" with what? /var/lib/jellyfin?
Have you created a continer at /mnt/t/jellyfin/?

"containers" on Linux are really just about "unsharing" resources. The process (jellyfin) running inside the "container" won't be able to see any files from the surrounding system, being left with just what the "container image" provides it with to see. The usage of the --volume argument to podman-run here really just means that we instruct the container manager to make an instance of the container named jellyfin/jellyfin, and make the given paths from the surrounding file system (our "host") visible at the given locations inside the container. In this case, accoding to how the jellyfin container is set up (see again https://jellyfin.org/docs/general/admin … lling.html ), jellyfin expects the directories /config and /cache to be writable, because there it keeps its configuration, user data and such, we make the bind mount "rw". But I don't want jellyfin to be able to modify my media library at all, so I add the path at which on the "host" system I have my video stuff to the container namespace at the location /media, would mark the mount read-only (ro).

The idea behind this is that you can change the container image of jellyfin (for example, upgrade to the next version of jellyfin (or the jellyfin container, to be more specific)) without losing the "state" (the configuration, the cache).

The primary reason I have set it up like this (state separated from stateless container) is to be able to upgrade jellyfin without caring about much else besides just pulling an updated container image.

BTW you can actually achieve much of the same with just systemd. Hit systemctl edit jellyfin.service, then in [Service], you can add any number of ProtectSystem=, ProtectHome=, ReadOnlyPaths= etc options to achieve just the same isolation which using podman enables without having to use container images.

Offline

Board footer

Powered by FluxBB