Question to mt-daapd developper (inotify request)

Well, while inotify would be overkill (imho) (and not being supported on must nslu2 flavours), a simple

for $file in *.[mp3][ogg][flac];do foo;

-esque script would do. where foo does an sqlite insert in the mt-daapd style. trigger that every 5 minutes, and have a dir structure like this:

incoming/

new music/

put the new stuff in incoming/, the script iterates every say, 5 minutes through that directory, copies the files to new music/ and then adds it from that path. voila.

isn’t dbus that abstraction layer?

@mas wrote:

And I thought dbus was some sort of inter process communication system.

As such it would be something distinctly different than a file change notifier…

But the idea of using such a thing sounds interesting in principle. What do you mean with an abstraction layer? Wouldnt simply linking against e.g. libfam (quite common) and using its functions do the job already???

Sure, but I’d have to write one for every different one. Fam doesn’t work because of well-known polling limits, and a requirement to hang a notification on every directory and subdirectory in the search tree.

Fam is great for monitoring a single directory when viewing it in an explorer window, but sucks for monitoring a whole tree.

So you are back to writing one for dnotify, one for dqueue, etc. Don’t really want to maintain all those. Also, none of these would work on embedded devices (although that’s not a deal killer).

At most, I’d probably write an ipc mechanism for other programs to ask the server to re-scan a file. Then the file watcher could run from outside the server.

@quitte wrote:

I’d really love to see support for some file alteration monitor. Firefly is serving more than 60000 files in a network with multiple users here. All users have permission to add files and modify the tags of existing files. With so many changes happening all the time I don’t want to put the extra load of rescanning on the harddisks.
As I cannot solve this problem myself I did the next best thing and searched the web.

I couldn’t find anything about dqueue, so I cannot comment about that.

It seems that dbus actually has some support for watching directories, but not even nautilus uses that. Instead it uses gamin, a drop-in replacement for fam.
The APIs of gamin and fam are the same. fam has dnotify support. gamin has inotify support. Also afaik both can do file system monitoring without any help of the kernel.

As far as I can tell adding fam support should cover all of the filesystem change implementations.

Edit: hmm I read this thread before but forgot about the Problems with fam you mentioned 😳

I might look at them again, as it was a while ago that I looked last and decided it wasn’t usable for workloads like the ones you are describing — 60000 files. It may be that gamin + new kernels might actually work now for huge file sets. It will be a post 1.2 thing, though.