Jump to content

Real time monitoring not detecting new files on new server setup


Go to solution Solved by Lessaj,

Recommended Posts

Posted (edited)

Hi

I am in the process of migrating from AMD -> Intel to take advantage of Quicksync for transcoding and hw tone mapping. 

On the new Intel server (emby-two) real time monitoring is not working on any the library directories.

Both machines are running Fedora Server and Emby is running in a Podman container with the same command: 

sudo podman run -d --label "io.containers.autoupdate=registry" --name=emby -p 8101:8096 --device /dev/dri:/dev/dri --volume emby:/config:Z --mount type=bind,source=/unraid/movies,destination=/movies,ro=true --mount type=bind,source=/unraid/tv,destination=/tvshows,ro=true --mount type=bind,source=/unraid/backups,destination=/backups,ro=false -e PUID=1000 -e PGID=1000 -e GIDLIST=39,105 -e TZ=Etc/UTC lscr.io/linuxserver/emby:latest

/unraid is an unraid nfs share that is mounted on startup.

Real Time Monitoring is checked on all libraries on both servers.

Both servers & unraid are connected to the same switch and are on the same local network.

I have created an example by restarting both servers at the same time, waiting a few minutes then adding a new file to the /tvshows directory.

In the emby-one log file it detects the new file: 

2024-08-25 13:24:33.232 Debug LibraryMonitor: Change detected to /tvshows/Outlander (2014) [tvdbid-270408]

emby-two log file never detects the new file even though it says its watching that directory

Any ideas what I need to change to get this working? I have tried restarting everything and also tried deleting and re-adding the libraries on emby-two

emby-two_20240825_rtm_outlander_fail.txt emby-one_20240825_rtm_outlander_success.txt

Edited by zemby
network
Posted

emby-one is running Fedora 39

emby-two is running Fedora 40

Posted

Hi, is it a path that is supported by INotify? Because Emby Server is built with the dotnet runtime, and the dotnet runtime uses INotify internally for file monitoring.

  • Thanks 1
Posted

Yes I thought so since my current setup works fine, both are mounting the nfs share to alocal /unraid mount point.

The current AMD server (emby-one) uses BTRFS for the local storage vs new Intel Server (emby-two) using XFS for local storage. The emby container would be running on there.

Could that be the issue if XFS doesnt support inotify in the same way as btrfs?

 

Posted

I think I've figured it out.

The new files to be detected are being written by a another container that also runs on on emby-one.

The containers have the same /unraid mount point passed through as /movies & /tvshows bind mounts to Podman.

So since the files are being written on emby-one (not the remote nfs host Unraid), the other containers on emby-one are aware of file changes as presumably they share the same inode? Which allows inotify to work. 

I tested manually creating test files on /unraid/movies on emby-two and it was picked up by the real time monitoring.

 

  • Thanks 1
  • Solution
Posted (edited)

I don't really have any experience with containers but NFS does not support inotify, which actually works down at the linux kernel level so I think because your containers need to interact with the linux kernel of their host it's able to be made aware of the changes within the confines of your emby-one server, but since it doesn't interact with the kernel of a remote server that's also mounting the NFS share it's not able to be made aware of the inotify events.

Edited by Lessaj
  • Thanks 1
Posted
9 hours ago, Lessaj said:

I don't really have any experience with containers but NFS does not support inotify, which actually works down at the linux kernel level so I think because your containers need to interact with the linux kernel of their host it's able to be made aware of the changes within the confines of your emby-one server, but since it doesn't interact with the kernel of a remote server that's also mounting the NFS share it's not able to be made aware of the inotify events.

Yep that seems to be the case, thanks!

I will either have to enable more regular library refreshes or move the writing container to the new emby-two also.

Posted
15 minutes ago, zemby said:

Yep that seems to be the case, thanks!

I will either have to enable more regular library refreshes or move the writing container to the new emby-two also.

That's part of the whole point of containers right? Easy to move them. :)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...