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. _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
