You are here: Home » Topic » Question to mt-daapd developper (inotify request)

Question to mt-daapd developper (inotify request)

This topic contains 8 replies, has 5 voices, and was last updated by  rpedde 9 years, 11 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #749

    jiceher
    Participant

    Did you plan to used inotify in place of actual scan procedure ?
    It should be fine to enable an mean to automatically scan mp3_dir when some events occur (add/del/move/rename).
    more informations at :

    http://www-128.ibm.com/developerworks/linux/library/l-inotify.html#download
    and
    http://inotify-tools.sourceforge.net/
    http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils/

    Thanks

    #7159

    jiceher
    Participant

    Modo please move this topic in the appropriate section (request) and sorry to have posted in the wrong section ;o(

    #7160

    fizze
    Participant

    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.

    #7161

    rpedde
    Participant

    @jiceher wrote:

    Did you plan to used inotify in place of actual scan procedure ?
    It should be fine to enable an mean to automatically scan mp3_dir when some events occur (add/del/move/rename).
    more informations at :

    http://www-128.ibm.com/developerworks/linux/library/l-inotify.html#download
    and
    http://inotify-tools.sourceforge.net/
    http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils/

    Thanks

    As soon as there is a decent abstraction library for the 10 or 12 versions of inotify/dnotify/dqueue/fam etc interfaces, yeah… I probably will.

    — Ron

    #7162

    quitte
    Participant

    isn’t dbus that abstraction layer?

    #7163

    mas
    Participant

    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???

    #7164

    rpedde
    Participant

    @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.

    #7165

    quitte
    Participant

    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 😳

    #7166

    rpedde
    Participant

    @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.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.