Jason Tackaberry wrote: > On Fri, 2006-04-14 at 15:35 +0200, Dirk Meyer wrote: >> checks to prevent it. But maybe we should think about signals from >> inotifier: what do we need and what is not (I guess CREATE is not >> needed because of MODIFY). > > In my first implementation of inotify (when I used ioctls) I had it eat > the MODIFY event after a CREATE. I guess I could do this again, but it > really shouldn't hurt anything if beacon is doing things properly. That > is, it shouldn't add stuff unless it gets a CREATE event.
Right > I looked at the code you just added and your new code just made a lot of > things O(n). I don't know the beacon code very well, so maybe this > suggestion doesn't apply, but maybe you could maintain a dict keyed on > filename and just check that to see if there are any dupes, rather than > iterating through the whole thing. What do you mean? Yes, in the inotify I look at all items I have in the to-watch queue and this is O(n). I know this is not very nice, but I don't expect this list to be very long. O do you mean the extra check in parse? In parse I queuy the db again which should be O(1) before doing the parsing. This adds some extra time but parsing is always slow (up to 100ms based on the filetype), an extra check here wouldn't be a big problem. Or do you mean something else? So right now beacon is more or less finished. I only have media support and not file based items on my todo list. The rom drive stuff should be very easy and the item stuff (e.g. titles of a DVD) should also be easy to to. And there is some additional metadata stuff to do, like creating thumbnails for each item. The only difficult thing I can think of is when an item changes it's type, e.g. goes from audio to video or a dir goes from dir to DVD (you create VIDEO_TS). I'm not sure how I can do that. Dischi -- FATAL ERROR! SYSTEM HALTED! - Press any key to do nothing...
pgpcnbpF2nmwX.pgp
Description: PGP signature
