Forcing unique results in dynamic playlists

[Justin Brown]

I just bought a spindle of CDs, and I'm trying to create several disks of my
top rated music for my 6-disk changer in my car. My idea was to use dynamic
playlists with certain criteria such as:
>3 stars
0% of several albums that I will burn separately

The problem is that I don't have much music rated >3 stars, and
consequently, I get a lot of duplicates in the generated playlist. This
makes it very tedious to clean up the playlist, so that I don't burn
duplicates.
My understanding is that Amarok uses an embedded MySQL database (by
default), so it should seem like adding "distinct" to the MySQL query could
eliminate this problem; however, I can't seem to find a way to do this.
The only downside that I could see for eliminating duplicates is a
performance impact, especially since the playlist adds additional elements
as the playlist proceeds (i.e. when one item is removed from the playlist,
another is added). This could actually get very bad if the same track that
matches the criteria but is already on the playlist keeps getting selected
(and then rejected since it is a duplicate); the query could certainly
overcome this by doing a NewTrackQuery(user specified criteria) -
CurrentPlaylist. Sorry about the lack of official function calls -- I'm not
familiar with the Amarok codebase.

I run into this problem quite a bit when I want to listen to my very highly
rated music: lots of duplicates.

My initial idea if Amarok does not support this would be to switch to an
external MySQL database, so I could run my own queries and create some
playlists that I can burn. Is there any way that I could query the internal
database, so I don't have to switch my library and run a full-blown MySQL
instance on my laptop?

Does this "distinct" feature exits? If not, would the developers consider
adding it?

Thanks,
Justin Brown
justin.brown1.1 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20100309/09317dbd/attachment.html>