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: 
> http://blog.beep-media-player.org/?postid=2 (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
http://www.advogato.org/person/jamiemcc/