Why: Turning off file monitoring in jellyfin and see if that resolves the issue.

[make-nz]

          Does restarting the jail solve issue? Does the issue return some point after restarting jail? If the answer is "yes" to both, then try turning off file monitoring in jellyfin and see if that resolves the issue.

Originally posted by @Thefrank in #66 (comment)

@Thefrank
I got here becauseof some "Name does not resolve (repo.jellyfin.org:443)" in my log and the plugin repo being a bitof a noshow
So far it works, after turning off file monitoring!
But I do like file monitoring very much, so is there any way to fix the issue/issues and have both?

[Thefrank]

@make-nz This is a common issue https://github.com/Thefrank/jellyfin-server-freebsd?tab=readme-ov-file#known-issues

Short explanation:
Sadly, there are no workarounds for that one. Having file monitoring on with a large number of files to monitor will eventually cause that to happen.

Lightly technical explanation:
This is indirectly caused by libinotify being used to monitor files/directories for changes.
The root cause is because kqueue/kevent, which libinotify is a shim for, was not designed to be used for monitoring hundreds/thousands/+ files.

[make-nz]

@Thefrank Thank you very much!
I came here because I did some searching on "Name does not resolve (repo.jellyfin.org:443)", but I'm running the pkg from ports.
https://www.freshports.org/multimedia/jellyfin/

This part I had herad of:

Since the heart of the library is kqueue(2), the library has to keep many files open to provide proper monitoring. It is especially important when you monitor a single but large directory.
Rules are:
If application specifies only IN_CREATE, IN_DELETE, IN_MOVED_FROM,
IN_MOVED_TO, IN_DELETE_SELF or IN_MOVE_SELF events in mask argument
of inotify_add_watch(2) then libinotify opens only watched directory
itself.
Adding IN_CLOSE_WRITE and/or IN_MODIFY events to ones mentioned before leads to opening of every regular file inside a watched directory. And adding one of IN_ACCESS, IN_ATTRIB, IN_CLOSE_NOWRITE or IN_OPEN flags to event mask leads to opening of all directories as well as regular files inside a watched directory. You can run out of file descriptors, so do not forget request more with setrlimit(2) before starting monitoring.
but did not make a connection to not resolve issue.

• Are you somehow in touch with the ports maintainer, or were/are you not happy with the pkg builds?
• Are you using different libinotify arguments in your version on JF?

[Thefrank]

Are you using different libinotify arguments in your version on JF?

libinotify is used by dotNET for file monitoring on Linux and FreeBSD: https://github.com/search?q=repo%3Adotnet%2Fruntime%20inotify_add_watch&type=code and Jellyfin does not directly interact with libinotify; it uses dotNET's file monitoring.

Are you somehow in touch with the ports maintainer, or were/are you not happy with the pkg builds?

I can see why this repo can cause confusion. I have no issues with the current port or port maintainer. This repo existed before a port of Jellyfin and served as a place for people to download a binary or an easily installable pkg. I continued to make binary builds after a port was created as a way to support legacy scripts that install/updated Jellyfin via this repo. It also serves as a place for people to get support for Jellyfin on FreeBSD as there is no official support for FreeBSD by the Jellyfin team.

[make-nz]

Thanks for clearing the fog on my side.

Short explanation:
Sadly, there are no workarounds for that one. Having file monitoring on with a large number of files to monitor will eventually cause that to happen.

I'm still stunned, how you figured that a "not resolve" was caused by libinotify — but I'm glad you did and documented it here!

[mvanbaak]

Depending on your use case maybe a project like autopulse can help?
It's basically a server that accepts web hook calls from programs like radarr and bazarr (and others), and sends a scan / update request to jellyfin for just the directory that was impacted.