One of the problems with Jellyfin is that older Live TV data is not deleted from the database even if all the guide sources and the TV tuner are removed from the configuration. The only way to ensure that the old metadata is gone, is by first stopping jellyfin:

systemctl stop jellyfin

and then editing the database manually to remove all Live TV data:

echo "DELETE FROM TypedBaseItems WHERE TYPE LIKE 'MediaBrowser.Controller.LiveTv.%;'" | sqlite3 /var/lib/jellyfin/data/library.db

After that, jellyfin can be restarted again, and all the Live TV channels and metadata should be gone:

systemctl start jellyfin

Due to containerization, applications running within an enclosed space will not notice the overall resource consumption such that freeing memory and expunging it might never take place. For that reason, Jellyfin seems to accumulate a lot of RAM within a Docker container that would otherwise be normal for its operation. Reported consumption can reach up to 3GiB even though most of that can be freed. The problem seems to affect glibc-linked programs under Docker and the solution is to set an environment variable named MALLOC_TRIM_THRESHOLD_ (last underscore is not a typo) to its lowest default value which is bytes.

A library can be rescanned by using the Jellyfin API and sending an HTTP POST request. Here is an example request using curl:

curl \
  -v \
  -X POST \
  -H "X-MediaBrowser-Token: JELLYFIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"Updates": [{"Path":"JELLYFIN_LIBRARY_PATH","UpdateType":"scan"}]}' \
  "https://jellyfin.tld/library/media/updated"

where:

• JELLYFIN_TOKEN is a token that can be generated from Jellyfin by accessing the menu Jellyfin -> Dashboard -> API Keys,
• JELLYFIN_LIBRARY_PATH represents either the path to a new file that was added or the full path of the whole library as configured with Jellyfin; this allows for partial scans by just scanning individual files or subpaths

Note that for checking whether the command went through, an HTTP status code of 204 represents success (rather than 200 OK).

Media servers like Plex and Jellyfin typically offer an option to specify a set of addresses or networks that should be considered to belong to the internal LAN in order to be able to speed up processes related to security. For example, there exist options to allow password-less login to media servers like Plex and Jellyfin iff. the connection is made from the internal LAN network.

However, when running under Docker, the IP addresses that Jellyfin will use is by the Docker specification a LAN address. Reading the comment underneath the "LAN networks" section, Jellyfin states that iff. the field is left blank, then all RFC1918 addresses (LAN addresses) are considered local. In turn, given that Docker containers internally all have RFC1918 addresses, that means that under Docker any and all connections to the Jellyfin container will be considered local, even if the connection is NAT-ed from the Internet.

This issue can be resolved by filling out the "LAN networks" field with, say, the loopback address such that only the loopback address will be considered local and given that the loopback address is not part of the addresses that RFC1918 lists, then all connections to Docker will be considered external connections.

One of the problems when setting up Jellyfin, or any other media PVR solution for that matter is that it is never clear which hardware codecs are supported. For example, even older nvidia cards only really have partial support or hardware-backing for various codecs. one way to find out is to check the ffmpeg version that is bundled with Jellyfin in order to query the codecs that are supported. For instance, issuing:

ffmpeg -hide_banner -decoders | grep rkmpp

yields the list:

 V..... av1_rkmpp            Rockchip MPP (Media Process Platform) AV1 decoder (codec av1)
 V..... h263_rkmpp           Rockchip MPP (Media Process Platform) H263 decoder (codec h263)
 V..... h264_rkmpp           Rockchip MPP (Media Process Platform) H264 decoder (codec h264)
 V..... hevc_rkmpp           Rockchip MPP (Media Process Platform) HEVC decoder (codec hevc)
 V..... mjpeg_rkmpp          Rockchip MPP (Media Process Platform) MJPEG decoder (codec mjpeg)
 V..... mpeg1_rkmpp          Rockchip MPP (Media Process Platform) MPEG1VIDEO decoder (codec mpeg1video)
 V..... mpeg2_rkmpp          Rockchip MPP (Media Process Platform) MPEG2VIDEO decoder (codec mpeg2video)
 V..... mpeg4_rkmpp          Rockchip MPP (Media Process Platform) MPEG4 decoder (codec mpeg4)
 V..... vp8_rkmpp            Rockchip MPP (Media Process Platform) VP8 decoder (codec vp8)
 V..... vp9_rkmpp            Rockchip MPP (Media Process Platform) VP9 decoder (codec vp9)

that would indicate that most of the codecs that are displayed in the Jellyfin settings are actually hard-ware backed when using the Jellyfin Rockchip MPP acceleration such that the illustrated settings in the following image seems appropriate.

The same would apply to actually encoding. By issuing:

ffmpeg -hide_banner -encoders | grep rkmpp

that would then display:

 V..... h264_rkmpp           Rockchip MPP (Media Process Platform) H264 encoder (codec h264)
 V..... hevc_rkmpp           Rockchip MPP (Media Process Platform) HEVC encoder (codec hevc)
 V..... mjpeg_rkmpp          Rockchip MPP (Media Process Platform) MJPEG encoder (codec mjpeg)

such that the settings illustrated in the following image can be made.

Note that compared to an older Nvidia machine, Rockchip-based boards seem to have support for a wider-range of hardware codecs such that they seem more appropriate than purchasing an older Nvidia.

In a blog-post Jellyfin claims that the project had issues with parallel scans of the library and the solution was to implement various "database-locking modes" in order to work around the issue. For example, there are user issues reported across the Internet with Jellyfin's database handling where people report that scanning stops unexpectedly or that library scans tend to take more time than expected.

The blog-post talks about solutions to this issue and also claims that "I found many reports all over the internet facing the same error but nobody was able to provide a conclusive explanation whats really happening here.", however in reality SQLite database are by definition not concurrent safe, or straight-up from the manual, "SQLite can be safely used by multiple threads provided that no single database connection nor any object derived from database connection" which in much less words that there is no built-in multi-threading support that would guarantee the linearity of transactions.

In spite of the confusion, Jellyfin implements three ways of accessing the database:

• "no locks",
• "pessimistic locking", and
• "optimistic locking

Looking at the page and reading what Jellyfin does internally while correlating with the official statement from within the documentation it seems that the most conforming method would be "pessimistic locking".

To make the change, the configuration directory has to be accessed and the database.xml file altered in order to set:

  <LockingBehavior>Pessimistic</LockingBehavior>

which, at the very least, should lead to a behaviour that should be more compliant with the official documentation.