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.

Okay, thought about this a lot more.

I believe the best way to deal with this in Tracker is to treat those files as virtual (VFS style). SO maybe you could define a URI for it that includes the HAL device, volume UDI and relative path of the media file (HAL://UDI/media.ogg) and then attach metadata against that uri.

It makes no sense to store the full path including mount point as that will obviously change and you need the full path in order to identify the file and get/set metadata anyway so a HAL uri would make much more sense here.

As I said before, Tracker treats virtual files as simply a string ID with which you can attach metadata to but it will not automatically extract metadata from it so you will need to manually populate Tracker with any metadata you need (including File.* stuff like mime type as well as any Audio.* stuff) and this goes for both Gnome-VFS, KIO-slaves as well as any arbitrary uris like HAL.

The media apps might *optionally* have to do a stat() dance on removable devices and VFS mounts to check everything is there in those cases and inform Tracker to delete any files/metadata that no longer exist.

I will also adjust search functionality so you can specify whether to include virtual files in the search results.

Hopefully this will be a more satisfactory solution?


Mr Jamie McCracken

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