Re: MLQ: Followup

["James \"Doc\" Livingston" <doclivingston gmail com>]

On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote:
> 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:
 <snip details>
> 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.

I'm a bit confused about how "HAL UDI + partial path" is related to the
MLQ idea. To me they seem fairly orthogonal.


However using HAL UDIs is a good idea. Most apps currently use the URI
as it's unique identifier and the method of finding the actual file, we
could decide that the common db would use a <HAL UDI, partial path> as
the unique id/location method.


> Downsides/doesn't-works:
> - There is no volume UDI available 

If this is a permanent thing, e.g. a non-HAL system or a http://
resource, then we could say that a null UDI and the full uri would be
used instead.

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


> - You make a regular 'move' (mv), and not just a remount

That is different again, and is probably best solved with audio
fingerprinting, and/or embedding unique metadata in the file.


Cheers.

James "Doc" Livingston
-- 
If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on
speed. -- Chris "Saundo" Saunderson in asr.