0

I'm creating a simple App in which the user can record and play Television Shows with Seasons and Episodes based on a pre-existing system of folders already present on the user computer. I would like to monitor if there are any changes to the actual files/folders so I want to store an instance of FileSystemWatcher in every season to listen for any changes that might occur in the corresponding folder. Depending on how many Seasons on each of the Shows, this can reach up to 1000s events listening in the same time. Are there are any performance/instability issues I should be aware?

One of the answers here suggests that cranking up the number of listeners up to the 10,000s is definitely a problem, but since I'm not expecting that many records I might go with this answer here saying that the performance hit of events in general is not that huge. Is there some kind of rule of thumb as to how many listeners should be active in the same time? Any piece of advice is most appreciated.

oneManArmin
  • 606
  • 6
  • 24
  • Can you reduce the number by using FileSystemWatcher.IncludeSubdirectories? – ajg Aug 02 '17 at 15:38
  • The second link regarding _"performance hit of events"_ has nothing to do with the OS let alone FSW –  Aug 02 '17 at 23:50

1 Answers1

1

OP

so I want to store an instance of FileSystemWatcher in every season to listen for any changes that might occur in the corresponding folder

You could do that but why have multiple when you can have just one:

You can watch for changes in files and subdirectories of the specified directory - MSDN

e.g.

myMonitor.IncludeSubdirectories = true;

OP

Are there are any performance/instability issues I should be aware?

Possibly, but if you use just one it reduces the possiblity without reducing functionality.

Anyway, the problem isn't so much the number of listeners (well it is but the other page goes into that) rather that the FSW can't guarentee it will not miss events during high-volume disk activity:

MSDN:

The Windows operating system notifies your component of file changes in a buffer created by the FileSystemWatcher. If there are many changes in a short time, the buffer can overflow. This causes the component to lose track of changes in the directory, and it will only provide blanket notification. Increasing the size of the buffer with the InternalBufferSize property is expensive, as it comes from non-paged memory that cannot be swapped out to disk, so keep the buffer as small yet large enough to not miss any file change events. To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties so you can filter out unwanted change notifications. Tell me more

  • Well, my problem is that these folders for the seasons can be anywhere, they are not connected, so they all have different paths. – oneManArmin Aug 02 '17 at 18:15
  • @rTECH What part of _"...pre-existing **folder hierarchy** already present..."_ did I get wrong? –  Aug 02 '17 at 19:07
  • Sorry, it was misleading indeed! What I was referring to is the system of folders on the users' computer, for example on their hard drive. I edit my question accordingly, thank you for pointing this out. – oneManArmin Aug 02 '17 at 19:30
  • @rTECH Well at worst you would have one FSW per folder listening for events. The more watchers coupled with more disk activity, the more likely you will miss events due to buffer overflow. NTFS is not like OSX's Journal and how say Time Machine operates –  Aug 02 '17 at 23:54