Hi, I did a bit of work to improve support for directories (mount points) which sometimes are there and sometimes aren't (for example usb/fw hard drives, or nfs/smb mounts on a laptop). This is much simpler than what you describe, but was easier to implement too :) I agree that it doesn't handle the case where you have several removable devices that you mount in the same dir. I added a <mountpoint> attribute to each file in the RhythmDB, and when refreshing the library, Rhythmbox now checks if the mount point the entry was in is still available. If the mount point is not mounted, it hides the entry (doesn't display it in the library) instead of removing it from rhythmdb.xml. This should solve most problems with removable medias I think. The show/hidden state for entries is only determined at startup so you need to restart rhythmbox when you mount a mount point with files known to rhythmbox. Doing it while rhythmbox is running is planned and shouldn't be too hard. The code is available from arch in teuf@gnome.org--2003/rhythmbox--removable--0.7 if people want to test it. It requires GNOME 2.6 (gtk 2.4 and gnome-vfs 2.6). It should transparently add the required <mountpoint> tags to an existing rhythmdb.xml. If it doesn't, you may need to readd your whole library. I haven't heavily tested it, so there probably are bugs ;) If you test it, mail me if you find issues, and mail me too if it works properly for you. Thanks, Christophe Le dim 21/03/2004 à 02:28, John McCutchan a écrit : > Right now in rhythmbox the handling of removable media is a pain. > If a userhas a USB/FW drive that is not connected when rhythmbox starts > up, rhythmbox assumes that those files have been deleted, and removes > them from the database. Another problem is say you have one mount point > for all of your USB/FW drives, depending on which one is plugged in when > RB is loaded, files may be removed from the database. > > I have given this some thought and have come up with this solution: > > For each file in the database, we need a new attribute representing > its physical location, that is unique to the physical device but not > unique to its order of being plugged in. I suggest we use the device's > serial number along with the partition number, so the physical location > attribute would be "SERIAL#_PARTITION#" (For devices with out partitions > PARTITION# can just be blank). When rhythmbox scans its database > we can now take more intelligent actions: > > if file is not present and file path has the same physical > location attribute, then the file has been deleted or moved, and > rhythmbox should remove the file from the database. > > if the file is not present, and the file path has a different physical > location attribute, then the device is not present, > and rhythmbox should tag the file as being temporarily unavailable. > > Other considerations: > > a device is removed: rhythmbox gets this event, scans the database for > all entries with the physical location attribute, and tags them as > temporarily unavailable. > > a device is inserted: rhythmbox gets this event, scans the database for > temporarily unavailable entries with a matching physical location > attribute, and makes them available. > > how to let the user know that a file is unavailable: A new source is > added > that shows unavailable files. With this the user could also remove > files from the database, in the case that the physical device will never > be returning. > > How can this be implemented in a portable way? > > Hal can be used to get the device's serial number and partition number. > Hal can also be used to notify rhythmbox when a device is inserted > or removed. > > What about things file-systems like NFS? > the physical location attribute could be the NFS address or some other > unique identifier. > > What do people think about this approach? > > John > > _______________________________________________ > rhythmbox-devel mailing list > rhythmbox-devel@gnome.org > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel > >
Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=