RTM (inotify) doesn't seem to be working on Diskstation 7.1

[Manp82 2]

So, i'm running Emby server on my DS414 on the latest 7.1 update available and everything seems to be working amazingly for the most part.

The issue is basically that real time monitoring on my library folders doesn't seem to be working.

I'm running the latest non beta version of emby server 4.10.1.0 but the same behaviour with real time monitoring was happening on the previous 4.9.5.0.

everything seems to be set up the right way:

- RTM enabled on my libraries

- i have the script running on startup setting increased inotify values:

/sbin/sysctl -w fs.inotify.max_user_watches=1048576
/sbin/sysctl -w fs.inotify.max_user_instances=4096

and checking the values from ssh returns what was set:

root@DiskStation:~# cat /proc/sys/fs/inotify/max_user_instances
4096
root@DiskStation:~# cat /proc/sys/fs/inotify/max_user_watches
1048576

- google suggested running this commad to check which processes are actually using inotify and it doesn't seem that emby is actually using it:

admin@DiskStation:~$ sudo find /proc/*/fd -lname 'anon_inode:inotify' 2>/dev/null | cut -d/ -f3 | xargs -I '{}' ps -p '{}' -o pid,comm                          PID COMMAND
    1 systemd
  PID COMMAND
10947 Plex Media Serv
  PID COMMAND
13053 synoindexscand
  PID COMMAND
15712 session_watcher
  PID COMMAND
 1850 dbus-daemon
  PID COMMAND
 1861 dbus-daemon
  PID COMMAND
 1988 syslog-ng
  PID COMMAND
 2114 systemd-udevd
  PID COMMAND
 2177 agetty
  PID COMMAND
 2786 synobackupd
  PID COMMAND
 2926 synoscheduled
  PID COMMAND
 6164 avahi-daemon
  PID COMMAND
 6888 synocrond
  PID COMMAND
 8137 crond

- logs suggest Emby is watching my media folders:

2026-10-07 16:36:41.396 Info LibraryMonitor: Watching directory with new FileSystemWatcher for /volume1/video/film for item 4
2026-10-07 16:36:48.539 Info LibraryMonitor: Watching directory with new FileSystemWatcher for /volume1/video/serie tv for item 6007

- the emby user have read/write permission on the folders and i'm pretty sure they're set correctly since it can write metadata and .jpg files to every movie folder just fine.

- Plex is able to update its library with no issue as sson as a new file is added.

- with a manual or scheduled library scan Emby picks up the new files with no issues.

 

yet Emby doesn't want to pick new files when added either automatically by radarr or manually by me.

log attached was taken on a fresh start of the emby server after a reboot of the host nas and after coping a new .mkv file to one of the monitored folders.

any help would be greatly appreciated.

 

embyserver.txt

Edited October 7 by Manp82

[Tremas 213]

Perhaps nevermind... you did mention you had a script running. 

Edited October 7 by Tremas

[Manp82 2]

Yes, that’s the first thing i checked even tho i have no inotify related errors in the logs.

i had that script running on startup for god knows how long, I don’t even remember why i added it but it was already there when i noticed RTM wasn’t working.

thanks for your reply.

[Luke 43532]

Are those volumes on the nas?

[Manp82 2]

3 hours ago, Luke said:

Are those volumes on the nas?

Yes, volume1 is the main nas volume running on the 4 internal drives, everything is on there. 

 

Edited October 8 by Manp82

[Luke 43532]

OK can you please provide a specific example of your issue?

[Manp82 2]

1 hour ago, Luke said:

OK can you please provide a specific example of your issue?

so...

- i downloaded Big Buck Bunny (big_buck_bunny_720p_surround.avi.zip) from the official site using download station  to /volume1/downloads, unpacked the zip file inside the download folder and moved it to /volume1/video/film/bd/Big Buck Bunny (2008)/ which is inside the monitored folder /volume1/video/film/.

what i expect is Emby should pick up the file and add it to the library as soon as i move it to a monitored folder. instead nothing happens and the logs say nothing until a manual library scan happens (either manual or scheduled).

 

- i also tried downloading the file The_General_512kb.mp4 from here https://archive.org/details/The_General_Buster_Keaton (it's a public domain movie) from download station directly to the monitored folder /volume1/video/film/bd/The General (1927) and again Emby doesn't import the movie inside the library until the scheduled library scan happens.

 

- i also tried adding the file directly to the root of the monitored folder and various other combinations like:

/volume1/film/big_buck_bunny_720p_surround.avi
/volume1/film/Big Buck Bunny/big_buck_bunny_720p_surround.avi
/volume1/film/Big Buck Bunny (2008)/big_buck_bunny_720p_surround.avi
/volume1/film/bd/Big Buck Bunny (2008)/big_buck_bunny_720p_surround.avi

but same deal. Emby never picked the file up and never added it to the library. i'm yet to do a manual library scan.

 

- in the attached log you can probably see i have a scheduled library scan every 45 minutes.

The_General_512kb.mp4 was picked up by a scheduled library scan that happened aroud 10 minutes after the file was completely downloaded.

after this i moved scheduled library scans to every 12 hours before doing any of the tests on big_buck_bunny_720p_surround.avi so the scheduled scan wouldn't get in the way.

 

embyserver.txt

[Manp82 2]

i also tried coping the file to the monitored folder via smb instead of moving files around inside the nas filesystem but same again, Emby doesn't pick up the file via real time monitoring.

doing a manual library scan later the file gets added to the library just fine.

[Manp82 2]

tried updating to 4.11.0.6 beta and i get exactly the same behaviour.

[Luke 43532]

Can you temporariily enable debug logging, restart the server and then perform a new test? Thanks.

[Manp82 2]

42 minutes ago, Luke said:

Can you temporariily enable debug logging, restart the server and then perform a new test? Thanks.

- enabled debug mode and restarted the Emby server

- downloaded this movie and added to /volume1/video/film/rip/Our Hospitality (1923)/OurHospitality_512kb.mp4 via smb.

- downloaded this movie with Download Station to the folder /volume1/video/film/rip/Dracula (1931)/Dracula.1931.mp4

- tried renaming "Dracula.1931.mp4" to "Dracula (1931).mp4" to see if maybe RTM worked on file name change instead of file creation.

both movies are public domain but both have an entry on TMDB so they should get all the metadata downloaded.

as you can probably tell by the log none was added to the library. the log was downloaded approximately ten minutes after the second movie finished downloading.

 

btw, thanks for your help.

 

embyserver.txt

Edited October 8 by Manp82

[Luke 43532]

OK, assuming you did that during the time of this log, then the realtime monitor is never firing.

Under the hood, Emby uses the dotnet runtime, and the dotnet runtime uses INotify for this function.

So what you might want to do is install INotify separately and see if it is reacting to your file system events.

[Manp82 2]

1 minute ago, Luke said:

OK, assuming you did that during the time of this log, then the realtime monitor is never firing.

Under the hood, Emby uses the dotnet runtime, and the dotnet runtime uses INotify for this function.

So what you might want to do is install INotify separately and see if it is reacting to your file system events.

yes, the log covers all the tests i explained in my last post.

i'm pretty sure inotify works in some capacity because Plex Server running on the same nas is able to immediatly pick up any new file added to its watched folders.

i'd have to check how to install inotify on the nas and test it, right now i'd have no idea.

 

thanks again.

[Luke 43532]

We don't know that Plex is built with INotify. It may use something else. if you google search "how to install inotify on synology and monitor changes"

the AI overview provided a pretty detailed list of steps to do this. can you try that and let us know the result?

[Manp82 2]

1 hour ago, Luke said:

We don't know that Plex is built with INotify. It may use something else. if you google search "how to install inotify on synology and monitor changes"

the AI overview provided a pretty detailed list of steps to do this. can you try that and let us know the result?

so, i've installed inotify-tools and played around a bit with inotifywait

inotifywait -m --inotify --format "%w" "/volume1/video/film/"
inotifywait -m --inotify --format "%w" "/volume1/video/film/bd/"
inotifywait -m --inotify --format "%w" "/volume1/video/film/rips/"

all work and generate an event when something is added.

but as soon as i add the -r parameter to enable recursive to watch the subdirectory content i get this error:

inotifywait -m -r --inotify --format "%w%f" "/volume1/video/film/bd"
Setting up watches.  Beware: since -r was given, this may take a while!
Couldn't watch /volume1/video/film/bd: Value too large for defined data type

which doesn't seem to have anything to do with max_user_watches or max_user_instances as i tried increasing the values again and it makes no difference.

i messed aroud trying to watch other paths with the -r oprion (which i assume Emby uses to monitor the content of the library path subdirectories) but i can only enable it on empty or almost empty folders. as soon as there's a bunch of subdirectories i get the "Value too large for defined data type" error.

which apparently means:

 

Quote

This error usually happens on Synology or Linux NAS systems when a 32-bit application tries to access or list files from a 64-bit filesystem (or Samba share) where file IDs / inode numbers exceed 2^{31}-1.

don't know if any of this makes sense.

Edited October 8 by Manp82

[Luke 43532]

Oh wait I missed something - you're on a DS414, so your server is not even running under the dotnet runtime. For your NAS we have to use the older mono runtime. It also uses INotify (I believe). 

Thank you for doing all of this digging. Unfortunately as we are dependent on the mono runtime to provide this function for us, I'm not sure we can actually resolve this for you.

[Manp82 2]

5 minutes ago, Luke said:

Oh wait I missed something - you're on a DS414, so your server is not even running under the dotnet runtime. For your NAS we have to use the older mono runtime. It also uses INotify (I believe). 

Thank you for doing all of this digging. Unfortunately as we are dependent on the mono runtime to provide this function for us, I'm not sure we can actually resolve this for you.

Ah yes it’s an old dog but somehow it still runs pretty much all the services i need so I don’t quite feel like upgrading yet.

no worries, i guess i can live with scheduled scans.

[Luke 43532]

I'm not sure why Plex isn't running into the issue. From a quick google it does look like they use INotify. Maybe they dug into Inotify source code and found that it was an easy issue to fix and so they patched it themselves and are running their own custom version. Or it could also be that even though they use INotify generally, maybe they use more than one tool for this and on 32-bit linux they're using something else.

[Manp82 2]

5 hours ago, Luke said:

I'm not sure why Plex isn't running into the issue. From a quick google it does look like they use INotify. Maybe they dug into Inotify source code and found that it was an easy issue to fix and so they patched it themselves and are running their own custom version. Or it could also be that even though they use INotify generally, maybe they use more than one tool for this and on 32-bit linux they're using something else.

I feel like this needs more debug logging at the moment the folder watching is deployed to properly debug.

Or maybe mono is logging something somewhere but i have no idea where to look.

 

thanks again 

[Manp82 2]

as far as i can tell Emby is simply not using inotify

find /proc/*/fd -lname anon_inode:inotify | cut -d/ -f3 | xargs -I '{}' -- ps --no-headers -o '%p %U %c' -p '{}' | uniq -c | sort -nr

reports:

find: `/proc/28452/fd/5': No such file or directory
find: `/proc/self/fd/5': No such file or directory
      1  9888 sc-tran+ transmission-da
      1  8290 root     crond
      1  6804 root     synocrond
      1  6134 root     avahi-daemon
      1  3040 root     synoscheduled
      1  2744 root     synobackupd
      1 23368 PlexMed+ Plex Media Serv
      1  2171 root     agetty
      1  2116 root     systemd-udevd
      1     1 root     systemd
      1  1989 system   syslog-ng
      1  1855 root     dbus-daemon
      1  1850 root     dbus-daemon
      1 15664 root     session_watcher
      1 13398 root     synoindexscand

as of why, i have no idea neither i can find a log that tells me why is failing to do so.

Plex Seems to be able to watch the same folders using inotify as shown above and transmission uses it to monitor its folder where files are dropped to download.

i have no idea.

 

[Luke 43532]

Quote

2026-10-08 22:34:56.124 Info LibraryMonitor: Watching directory with new FileSystemWatcher for /volume1/video/demo for item 16559

if you are getting this far then it is definitely wiring them up.

[Luke 43532]

It is possibly an issue in the mono runtime, which unfortunately is not being updated anymore. Due to the fact that the mono runtime is not being updated anymore, that probably also means we are shipping a very old version of Inotify as well.

[Manp82 2]

22 minutes ago, Luke said:

It is possibly an issue in the mono runtime, which unfortunately is not being updated anymore. Due to the fact that the mono runtime is not being updated anymore, that probably also means we are shipping a very old version of Inotify as well.

That’s the most likely scenario. It seems it’s going to stay like that.

thanks again for your help, at least now i know it wasn’t a mistake on my part.