As far as I can see, file modifications (retagging) aren't treated while in inotify mode - at least it doesn't work with my setup.
Is there any reason, why the IN_MODIFY flag isn't used, when treating inotify events?
After modifying only three lines in autscan_inotify.cc adding this flag, modified files are removed from and added again to the database correctly.
Are there any drawbacks?
There is another strange behaviour: When there are lots of file system modifications, sometimes the autoscan mode is erased from directories and there isn't any autoscan any more - you have to redefine the autoscan mode again interactively. I don't know exactly under what circumstances that happens.
as far as I remember we don't check for IN_MODIFY, because we thought that an IN_CLOSE_WRITE would be triggered anyway. Could you tell us what exactly you did to retag your files? Perhaps you could also install "inotify-tools" and use "inotifywait -m <dir>" to capture the inotify events you receive while retagging your files and post the output here.
To the "strange behavoir": This sounds like a bug :) - It would be great if you find a way to reproduce it. Prehaps you could also use "inotifywait" to capture the inotify events.
inotifywait tells me that CLOSE_WRITE events are triggered (I use a script that calls id3v2 for retagging), so there is no need to catch MODIFY events.
Right now, when I restarted the unmodified mediatomb it also caught the retagging events and worked like expected.
But I tested it before and at least after a while, I had to move directories around to achieve modified entries in the database.
Is it possible that watches are lost? - the hash table still doesn't use primes - in my case it's size is 5*2^16.
What does the system do, when there aren't enough user watches? - though I don't think it's the case here.)
I think, I increased the number of max user watches - could I have done something wrong there?
The "strange behaviour" does occur extremely seldom. It also occurred (more often), when I used sqlite, (may be because there was a lot more computing going on and therefore task lists were longer).
Ok, it happened again today - retagging didn't trigger database updates.
The following behaviour is reproducible with my setup:
My directory structure is extremely simple:
CDs is the directory for all my CDs, (with properties: inotify, full scan level, recursive)
'Beethoven - Choral Fantasy - Zubin Mehta'
is a subdirectory, which contains the mp3 files.
If I do a retagging, everyting works fine.
Now, if I rename (/bin/mv) this directory to
'Beethoven - Choral Fantasy - Mehta'
the database is updated, but when I try to retag files in this directory, nothing
happens any more.
Furthermore, after restarting mediatomb the database is updated only partially for these files,
but retagging works again for the renamed directory.
Log in to post a comment.