On Thu, 2005-10-20 at 10:28 +0100, Bastien Nocera wrote: > FAM doesn't know about this, neiter does gnome-vfs. The way it's > implemented in Nautilus is that we don't try to read the file if it's > been modified less than .5 sec ago (on top of my head). > > It would be easy enough for Rhythmbox to check whether the modified file > has been modified less than X amount of time ago and push the file back > at the bottom of the queue if it has, so that we can re-check it > slightly later. That's basically what the latest version of the patch does, although in a slightly different way. When it notices a file has been created or modified it inerts (uri, time) into a hashtable, replacing any existing entry for that uri. There is a timeout that gets called every X seconds and iterates over the hashtable, and checks whether the value (which is the last-modified time) is more than Y seconds ago - if so it removes it from the hashtable and queue the metadata load event. I set X and Y both to 5 seconds (for no particular reason), which means that it will do the load about 5-10 seconds after it was last modified. Simply checking the last-modified time when we get a metadata-load event, and re-queueing if it the file has been modified recently is probably a much nicer way of doing it - although it might suck up cpu processing and queueing the same event. Cheers, James "Doc" Livingston -- In God we Trust. All others must submit an X.509 certificate.
Attachment:
signature.asc
Description: This is a digitally signed message part