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