Directory Watcher Crashing

[HouseOfCards 95]

I've never had this issue before, but lately metadata downloads are failing which require a server restart to correct.  If you need the full logs I can attach them, but this is the error I get when it happens.
 

2025-12-12 17:53:06.535 Error LibraryMonitor: Error in Directory watcher for: /mnt/LTS-Movies
*** Error Report ***
Version: 4.9.1.90
Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
Operating system: Linux version 6.12.54-Unraid (root@Develop) (gcc (GCC) 15.2.0, GNU ld version 2.45-slack151) #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025
OS/Process: x64/x64
Framework: .NET 8.0.11
Runtime: system/System.Private.CoreLib.dll
Processor count: 12
Data path: /config
Application path: /system
System.IO.IOException: System.IO.IOException: Stale file handle : '/mnt/LTS-Movies/Mark Of The Devil (1970)'
Source:
TargetSite:
No Stack Trace Available

 

[Luke 42077]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[HouseOfCards 95]

Here you go...  It's been happening at random lately, this server version was the first time I've experienced it.  It's also the first time I've added media in a couple versions though, so I'm not positive if it started this version specifically, or a couple small releases ago.  Thanks.

 

embyserver.txt

[Luke 42077]

I've never seen that stale file handle error come out of the file system watcher before. Normally when it has an error we just shut it down in order to keep it from flooding the log. Maybe this one can just be ignored.

[HouseOfCards 95]

1 hour ago, Luke said:

I've never seen that stale file handle error come out of the file system watcher before. Normally when it has an error we just shut it down in order to keep it from flooding the log. Maybe this one can just be ignored.

Maybe.  After this last file was added, after an abnormally long time, it did seem to recover and update the metadata on the latest file...  So maybe when it crashes it just takes a bit to recover?  Whatever.  I can let you know if it gets really annoying, or stops updating altogether after I give it some time.  Maybe just because I'm watching for the movie to appear made me notice.  If I give it 15 or so minutes, the last one eventually showed up.

I just wanted to report because I thought it stopped downloading metadata altogether.  I'll let you know if anything else strange happens.  Don't worry about it for now.

[Luke 42077]

https://stackoverflow.com/questions/20105260/what-does-stale-file-handle-in-linux-mean

Just some reading in case it might help you determine what activity may have caused it.

[HouseOfCards 95]

13 hours ago, Luke said:

https://stackoverflow.com/questions/20105260/what-does-stale-file-handle-in-linux-mean

Just some reading in case it might help you determine what activity may have caused it.

In case this comes up with anyone else...

Because it's far cheaper to buy a 10 TB hard drive than it is to store 10 TB in an online backup, I use Syncthing to sync my movies and television to another computer for backup.  I looked into this and saw that Syncthing was holding onto the ".part" files that Linux creates when transferring a large file.  Essentially, you start copying a 5 GB video file to the server and it creates something like "Movie Name.mkv.part" as it's transferring.  When it's done, it removes the ".part" and leaves "Movie Name.mkv" in it's place.  

This never used to happen, so perhaps it's a bug with the latest Syncthing, but Syncthing tries to start syncing the file with the ".part" and throws an error that the file changed before the transfer was complete.  It seems to hold onto the reference to "Movie Name.mkv.part" even though it eventually gets deleted.  I had a bunch of these errors all of a sudden, so I'm not sure if the file is being properly locked while it's transferring, or Syncthing changed something, or what...

What I've done is tell Syncthing to exclude "*.part" files from syncing and cleared up those old errors.  If the problem keeps happening I'll update the post, but this seems logical as the cause for that stale file handle problem.  If anyone else reports something, check into whether they use Syncthing.

Thanks!

[HjanecksD03 2]

That metadata error is a pain! Have you tried disabling 'Real-time monitoring' for just that specific library to see if it stabilizes? Sometimes a single corrupted file or a deep nested folder can trip up the watcher. It might be worth a shot while waiting for the devs to look at the logs.