I have an x86 Mikrotik router running 7.20.6, with the container system enabled. The system log is occasionally showing the following error, which would typically involve making a change to the host server, but one cannot simply make changes like this in Mikrotik RouterOS.
jellyfin: System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.
Is there a way to increase the number of open file descriptors, like you would do in a typical Linux system via modifying /etc/sysctl.conf by adding fs.inotify.max_user_instances=xxx where xxx is a number higher than 128?
Maybe ask instead why a media server needs more than 128 files open at once.
Jellyfin is shockingly unoptimized, which is why 10.11 is locking up and taking days to run an index following an ill-advised database layer redesign.
I did a SQL trace recently to help debug this, and I got screenfuls of SQL merely on clicking the context menu for a single movie, despite the fact that this menu's contents are static!
I am not telling you to use something other than Jellyfin, but I would at least encourage you to run it on the biggest machine you can, because that is apparently how its designers are running it, else they would have seen these problems for themselves before face-planting in public like this.
Couple that with my advice to not run containers on CHR, and you have what I do recommend: run Jellyfin in parallel to CHR on the VM host.
Thanks for the reply.
As far as I can tell, JellyFin is not opening more than 128 files, it is attempting to create event notifications for directories to see when files are changing, hence the message about inotify. I don’t have any problems with it “locking up” or “taking days to run an index.” Also, I am a professional database administrator in my day job, and I don’t particularly care which underlying DBMS they are using - JellyFin works for me and it works practically perfectly. SQLite is perfectly capable and is being used in the exact scenario it was designed for. Could the database access layer be optimized? I’m sure it could be, but then practically no one knows how to design a good database these days, and as far as I can tell that is wholely unrelated to this issue.
FYI, I’m not running CHR on this particular server since Mikrotik RouterOS is on a beefy baremetal Dell PowerEdge server with a large amount of RAM and far more processing power than it needs. I have no intention of changing that 
. I am just curious if RouterOS has the ability to tweak operating system parameters in some way I am unaware of. I don’t think it does, but like I said, I am curious.
JellyFin is not opening more than 128 files, it is attempting to create event notifications for directories to see when files are changing,
And if you look at the man page for inotify, you see that it takes a file descriptor.
But fine, set this quibbling fact aside and reframe the question: why does it need to watch more than 128 directories? Answer, it doesn't, if you turn off the setting that makes it rescan on every filesystem change.
SQLite is perfectly capable and is being used in the exact scenario it was designed for.
Yes, which is why 10.10 worked perfectly fine, before they wrecked it by switching over to EFCore and adding an unnecessary locking layer, presumably to get around the fact that they're trying to access it in multithreaded fashion.
I've written a SQLite-based media server myself, and the stock locking works just fine.