MLQ: Followup

[Jamie McCracken]

Milosz Derezynski wrote:
> 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).

Im quite happy to add this as metadata to tracker and even get tracker 
to hide stuff based on it (using hal) but it still needs to be part of 
the uri for a music file (otherwise we wont be able to uniquely identify 
the files)



-- 
Mr Jamie McCracken
http://jamiemcc.livejournal.com/