Re: Common music database?

Milosz Derezynski wrote:
Oh yeah the reason i asked for HAL inclusion (although this should be also discussed on xdg list i take it, but TBH the xdg list is just dead and alot of xdf people are present here just as well) is that BMP uses the HAL device and volume UDI to make only *those* files accesible and visible to the user that currently _are_ accessible.

I.e. you start BMP, add 2000 files from your usb harddisk, unplug the usb harddisk, and they are hidden in the library cause they're just not accessible; the mount point of this harddisk doesn't matter and it can change, all that's important is the HAL UDI

(If someone goes about to argue HAL doesn't have UDIs for everything yet: right. If someone goes about to argue that a HAL UDI is "unreliable": Not really. It's for one more reliable than a mountpoint, given that the device and volume UDI stay the same, and if they change (i.e. you get a new volume UDI for the same device UDI) you can with sane reason assume it's a new volume, i.e. it got formatted or it's another partition of some harddisk).

The paradigm here is "We're not talking about missing files yet, but first about a missing device": BMP will also not prune files from the library (when asked to prune it) whose device/volume is currently not plugged, as it's not reasonable to say that "they aren't there anymore". They can be very well "there", just on a device that's not present. That's the same as you can't tell if Daisy has got her hair colored red if she's currently not at the party. Heh.

Well a little more information is on our Codeblog: (Note that this has been rewritten to use HAL instead of sysfs directly)

Jamie: Please add this to Tracker! Maybe not make files invisible completely when the device and volume aren't there, but give them a boolean type flag that indicates that for every file, so that this is a wholly optional issue.

(One could go as far as adding a "last seen" date for that device/volume pair, so apps, or even Tracker itself, can say, e.g. after 90 days "Are you sure you want to keep this metadata still around? The files seem to be gone for a rather long time")

Im not sure that Tracker would be good for that.

Tracker only watches directory roots that you tell it to (or it watches only your home directory if you dont tell it) so its unlikely that it would be used for watching removable drives (indeed if FAM was being used on a non-inotify system it would be especially problematic as FAM would pin down the device)

Tracker will let you add metadata to a file even if that file has not been indexed by tracker or is not watched, however, the drawback is that tracker would end up spitting out non-existant files in searches.

A central DB like Tracker is only really good for persistent data on your hard drive. For removables, it makes sense to have a separate DB or text file that stores the metadata on the local drive (given that EA's probably wont be available on removable drives?). The problem with this is that such data may not be up to date so the only safe way is to manually stat all the files in a removable device and then correlate them against the metadata in the local DB/file (EA's would be a lot better here!).

I will experiment with the HAL stuff to see if Tracker can be made more suitable for this but cant promise anything at this time. Even if I can do it, I would still need to stat all files to make sure they tally with the DB whenever the device is mounted (as above) as we obviously cant tell if its been modified elsewhere without doing that.

Mr Jamie McCracken

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]