jellyfin / jellyfin-metapackages

Metapackages for Debian and Docker

Jellyfin Metapackages

This repository contains the various Jellyfin metapackage definitions. With the build split for the 10.6.0 release, the main server and web client are built separately, in order to ensure that both of them are unique and there is no built-time cross dependencies between the two repositories. This simplifies building for releases, as well as enables per-PR "unstable" builds as opposed to timed "daily" builds.

Debian

This is a simple equivs-build definition which will build a Debian metapackage for the jellyfin-server and jellyfin-web .deb files. By design, there is no restrictions on the version of the dependency packages; this ensure that this metapackage will always install the latest version of these two packages and simplifies the management of this file, especially for the per-PR "unstable" builds.

The version indicator in this file is the invalid placeholder X.Y.Z. This must be replaced with a real version at build time, e.g. with sed -i 's/X.Y.Z/10.6.0/g' jellyfin.debian.

The package is built with the following command: equivs-build jellyfin.debian.

Docker

This is a simple set of Docker images that combine the jellyfin-server and jellyfin-web Docker images into one final jellyfin image for distribution. They are built in response to the main CI when the per-repository builds are completed.

Changes to the Docker dependencies at runtime should go here; only build-specific changes should go in the main repositories.

There is no version indicator in these Dockerfiles; this is only relevant in the naming when run from CI.

The Dockerfiles are built with the following commands. This will be done through CI, either on our build server or Azure:

Stable

docker build -t jellyfin:{version}-{arch} --build-arg TARGET_RELEASE=stable -f Dockerfile.{arch} .
docker manifest create --amend jellyfin:{version} \
    jellyfin:{version}-amd64 \
    jellyfin:{version}-arm64 \
    jellyfin:{version}-armhf
docker manifest push --purge jellyfin:{version}
docker manifest create --amend jellyfin:latest \
    jellyfin:{version}-amd64 \
    jellyfin:{version}-arm64 \
    jellyfin:{version}-armhf
docker manifest push --purge jellyfin:latest

Unstable

docker build -t jellyfin:{build_id}-{arch} --build-arg TARGET_RELEASE=unstable -f Dockerfile.{arch} .
docker manifest create --amend jellyfin:unstable-{build_id} \
    jellyfin:{version}-amd64 \
    jellyfin:{version}-arm64 \
    jellyfin:{version}-armhf
docker manifest push --purge jellyfin:unstable-{version}
docker manifest create --amend jellyfin:unstable \
    jellyfin:{version}-amd64 \
    jellyfin:{version}-arm64 \
    jellyfin:{version}-armhf
docker manifest push --purge jellyfin:unstable

jellyfin-metapackages's Issues

Missing NVIDIA_DRIVER_CAPABILITIES in final jellyfin/jellyfin image

Congrats for the 10.6.0 release! 🎉 I upgraded from 10.5.5 on Kubernetes almost flawlessly,except for one bit!

While the old jellyfin/jellyfin:10.5.5 image defines NVIDIA_DRIVER_CAPABILITIES in the environment, the new jellyfin/jellyfin:10.6.0 does not, despite https://github.com/jellyfin/jellyfin-metapackages/blob/4997416c7db38233c174a31f4cb3a8f3000f3dd9/Dockerfile.amd64#L4

This prevents nvidia-container-runtime (which in my case, via k8s-device-plugin) to properly set up, ultimately preventing Nvidia GPU transcodes like so:

Stream mapping:
  Stream #0:0 -> #0:0 (hevc (hevc_cuvid) -> h264 (h264_nvenc))
  Stream #0:1 -> #0:1 (copy)
...
Cannot load libnvcuvid.so.1
[h264_cuvid @ 0xdeadbeef] Failed loading nvcuvid.

Easy workaround for now is to simply define the environment variable at container run, e.g. under Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jellyfin
  ...
spec:
  ...
  template:
    spec:
      containers:
      - image: jellyfin/jellyfin:10.6.0
        # work around missing capabilities for GPU transcoding
        env:
        - name: NVIDIA_DRIVER_CAPABILITIES
          value: "compute,video,utility"
        ...

though I suppose the relevant lines from the old jellyfin/Dockerfile could be moved here to jellyfin-metapackages/Dockerfile.*, right? If so, I can probably whip up a quick PR...

publish container image on ghcr.io

Now that dockerhub is imposing strict rate-limitting and curbing the availability of container images, it'd be best to also publish container images in other publicly accessible registry servers (i.e. ghcr.io)

The setup is quite simple and straightforward:

https://docs.github.com/en/packages/guides/migrating-to-github-container-registry-for-docker-images

Unreliable packaging of the combined release

Hello,

Following this issue: jellyfin/jellyfin#5594, it would seem the combined Linux stable release does not get packaged reliably.

In the latest jellyfin releases, since 10.7.1, the combined release get packaged with the musl (jellyfin-server_10.7.2_linux-amd64-musl.tar.gz) build of the server.

After looking into collect-server.azure.sh, it seems the script is not well equipped to deal with multiple builds for Linux.

Especially aournd #L215:

    our_archive="$( find ${filedir}/${releasedir}/${version} -type f -name "jellyfin-${servertype}*.${filetype}" | head -1 )"
    if [[ -z ${is_unstable} ]]; then
        partner_archive="$( find ${filedir}/${partnerreleasedir} -type f -name "*${version}*.${filetype}" -printf "%T@ %Tc %p\n" | sort -rn | head -1 | awk '{ print $NF }' )"
    else
        partner_archive="$( find ${filedir}/${partnerreleasedir} -type f -name "*.${filetype}" -printf "%T@ %Tc %p\n" | sort -rn | head -1 | awk '{ print $NF }' )"
    fi

where the build that gets into the combined package get chosen.
The code either takes "the first" (name) or "the last" (date) in a list of files like this:

jellyfin-server_10.7.2_linux-amd64-musl.tar.gz     11-Apr-2021 20:59
jellyfin-server_10.7.2_linux-amd64.tar.gz          11-Apr-2021 21:06
jellyfin-server_10.7.2_linux-arm64.tar.gz          11-Apr-2021 20:59
jellyfin-server_10.7.2_linux-armhf.tar.gz          11-Apr-2021 20:59

but depending on names, build time/order, and what triggered the build, this could completely change from one release to the other.

So to fix this, I think the script needs to:

• Identify and pass around an ${arch} that allow us to select a precise build
• Either:
  • build a combined release for each ${arch}
  • or define a target ${arch} for the combined release
    • Which ${arch} will be default ? (amd64 like before seems to be a good candidate)
    • From where will this information get pulled ?

add healthcheck to the docker image

It would be cool to actually be able to tell from docker if things are running.

In the dockerfile you'd just need a small extension like that:

HEALTHCHECK --interval=5m --timeout=3s CMD curl -f http://localhost/ || exit 1

That way docker is able to tell if the container is healthy due to the exit code of the command.

Quick and dirty: add curl
Better solution: actually have something like jellifin --healthcheck implemented

((reference: https://docs.docker.com/engine/reference/builder/#healthcheck))

Missing cuda libraries in the container, preventing transcode with NVIDIA GPU

It seems that the 10.8.13 container is missing cuda libraries which results in transcodes failing.

That libcuda.so.1 does indeed seem to be missing.

Example ffmpeg log:

/usr/lib/jellyfin-ffmpeg/ffmpeg -analyzeduration 5e+08 -init_hw_device cuda=cu:0 -filter_hw_device cu -hwaccel cuda -hwaccel_output_format cuda -hwaccel_flags +unsafe_output -threads 1 -autorotate 0 -canvas_size 1920x1080 -i file:"<snip>" -autoscale 0 -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:0 -codec:v:0 h264_nvenc -preset p1 -b:v 29246104 -maxrate 29246104 -bufsize 58492208 -profile:v:0 high -g:v:0 72 -keyint_min:v:0 72 -filter_complex "[0:2]scale=s=1920x1080:flags=fast_bilinear,format=yuva420p,hwupload=derive_device=cuda[sub];[0:0]setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_cuda=format=yuv420p[main];[main][sub]overlay_cuda=eof_action=endall:shortest=1:repeatlast=0" -start_at_zero -codec:a:0 libfdk_aac -ac 2 -ab 384000 -af "volume=2" -copyts -avoid_negative_ts disabled -max_muxing_queue_size 2048 -f hls -max_delay 5000000 -hls_time 3 -hls_segment_type mpegts -start_number 0 -hls_segment_filename "/config/transcodes/321a15db383d521e419c1550a108f73c%d.ts" -hls_playlist_type vod -hls_list_size 0 -y "/config/transcodes/321a15db383d521e419c1550a108f73c.m3u8"


ffmpeg version 6.0-Jellyfin Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04)
  configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-ptx-compression --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-libdrm --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libsvtav1 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-opencl --enable-vaapi --enable-amf --enable-libvpl --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
[AVHWDeviceContext @ 0x55ab6f810040] Cannot load libcuda.so.1
[AVHWDeviceContext @ 0x55ab6f810040] Could not dynamically load CUDA
Device creation failed: -1.
Failed to set value 'cuda=cu:0' for option 'init_hw_device': Operation not permitted
Error parsing global options: Operation not permitted

Vulnerabilities in the las docker image

Trivy informs about a lot of Critical and high vulnerabilities in the last image.

Do you have plans to fix this.

Docker image size for AMD64

I have been using the LinuxServer Docker image for several years and recently I moved to the official Docker image.
I noticed there is a significant size difference between both images for AMD64. I don't care if the image is big if all dependencies/packages are required. The thing is, or you are including more packages than required or they are missing something important (bug).

https://hub.docker.com/r/jellyfin/jellyfin

https://hub.docker.com/r/linuxserver/jellyfin

His Dockerfiles are here => https://github.com/linuxserver/docker-jellyfin