MLQ: Followup

[Milosz Derezynski]

What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that
i've introduced a concept of keeping track of tracks across mount point
changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume
Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI
of this file is still present on the system, and if so, gathers the new
mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library
only anyway since only there we can reliably store the HAL volume/device UDI
and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will
correct the URI on-the-fly as long as the volume is mounted at all on the
system (and has an UDI to begin with; problem cases here are network
volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather
sure that no matter where you really move the music, BMP will always be able
to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker,
this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI
per file to the metadata).

-- Milosz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20060622/223dbf4b/attachment.htm