extragear/multimedia/amarok/src

Maximilian Kossick maximilian.kossick at googlemail.com
Sat Aug 2 15:26:21 CEST 2008


On Sat, Aug 2, 2008 at 3:13 PM, Daniel Winter <dw at danielwinter.de> wrote:
> On Saturday 02 August 2008 15:07:50 Mark Kretschmann wrote:
>> On Sat, Aug 2, 2008 at 2:56 PM, Daniel Winter <dw at danielwinter.de> wrote:
>> > On Saturday 02 August 2008 09:37:14 Jeff Mitchell wrote:
>> >> SVN commit 840907 by mitchell:
>> >>
>> >> Fix some crashes, add some more stuff
>> >
>> > Sorry, but that commit scares me.
>>
>> I'm also a bit concerned about it. I've already found two regressions:
>>
>> * Current playlist saving was borked (we tried to save the uidUrl).
>
> Don't do that. Saving the uidUrl in the playlist is correct. (at least in the
> way i planed it for the nepomuk collection, and i think it should work in a
> similar way for the sql collection).
>

Daniel is right. current.xspf's purpose is restoring Amarok's internal
state after a restart. Using the internal uidUrl for current.xspf (or
any other internal playlist). We do have to distinguish between
internal playlists (even if they are stored as files), which use
uidUrl (and will work even after moving files around if everything
works correctly) and external playlists ofr use in other applications,
which must contain the actual url of the track.

Regarding Jeff's commit: what's the use case for those changes to
QueryMaker? If you have a uidUrl already, simply call
CollectionManager::trackForUrl and it will give you the right track if
available? And I do not see any reasons for querying for a list of
uidUrls.

Max


More information about the Amarok-devel mailing list