When monitoring directories for changes using inotify the inotify thread seems to have a problem with subdirectories not accessible by the MT user - like with Linux/ext3 the "lost+found" directory.
A possibility to exclude directories based on e.g. a pattern would be nice as inotify is much more ressource-effective than the timed-scan approach (which works fine in this case).
As there are many subdirectories besides the "lost+found" it would be a pain to add all of them to the config.xml file.
Nevertheless MT is the best choice for me as it runs on Linux and works (almost) flawlessly with my PS3 - so thanks to the devs for this nifty tool. :)
such "exclude" lists are indeed not implemented, usually it's not a problem because people tend to store their media in some dedicated directories, where all subdirs only contain media and nothing else, so a recursive setting works just fine.
I do not think that we will add something like this anytime soon, but if you really want it you should submit a feature request to the tracker.
Btw, you know that you can set scan settings via the UI as well?
Thanks for the feedback :>
I see you point about the exclude lists. I would have been a convenient way to work around organisational imperfections. :)
As I have only some static directory locations I add the locations in the config.xml instead of using the UI to add each directory separately - which is what you referring to I guess.
But the (my) basic problem is, that the inotitfy thread will abort if it encounters a directory which can not be watched - e.g. like the 'lost+found' dirs.
A possibility to work around this (besides the exclude lists) would be to alter the function AutoscanInotify::threadProc() to continue (and skip) directories which can not be watched.
Currently only the following line is found in the log in such a case:
2008-10-11 00:26:16 ERROR: Inotify thread caught exception: no permission
Instead one could log the directory not being able to watched to the log file and continue adding watches to the others.
I will file this on the tracker.
Yes, I understand your problem but this is actually a bug which we are aware of, I just do not remember if it is already fixed or not, actually I think that it is still open but we have it on our list for 0.12.