Yeah. I can confirm this. The database query that processes smart playlists can't actually handle multiply-labelled tracks...

I can also confirm this.

Just tried the final 1.4.5 and stumbled on this bug.

Does this bug only exist with SQLite? So a workaround would be to use MySQL, if it's not easy to fix.

I think this bug should be fixed soon, as it makes using labels rather useless.

This bug also applies to the collection filter.

I've looked at the amarok database layout, and I don't see any simple solutions.  However, keep in mind that I have very limited sql skills, and I have only looked at the database, not how amarok actually interacts with it.  In fact, maybe everyone should just ignore this whole paragraph.

Just a side note: is it possible to correct the title of this bug? It should be "label" instead of "lable"
Normally I won't care about typos that much, but here I think it's important so one can find this bug easier.

#5: Yes.

I can confirm that this issue applies to a MySQL setup also.

just to add my 2 cents on the importance of this bug...
The "label" feature was the reason that I decided for the first time ever to go through the work of compiling source code in order to use/upgrade a program!  I was really excited to get this feature.  So, it is really disappointing that this does not work.  I would agree that this bug makes this new feature pretty much useless for me.

Oh how excited I was when I found this feature last night after recently switching from Rhythmbox (Amarok is so much more flexible).  Now this morning I find this bug and discover it doesn't work.  

For what it's worth, the same functionality can be had by using the comment field, and it works properly.  Though some of the nice interface features, like seeing the list of existing labels to choose from.  This has the added benefit of being able to edit the labels inline.  

If the problem is as difficult to solve as its made out, perhaps it could be reduced to another text field, like comment, until a more elegant solution can be had.

Confirmed for both MySQL and sqlite on Ubuntu Edgy.  I hope it's fixed soon... maybe I'll finally try to patch an open source app and fix this myself!

In order to solve this bug cleanly, it'll require a reworking of how QueryBuilder works.  Specifically, QueryBuilder will need to be able to support joining on a single table multiple times, i.e. "SELECT * FROM tags LEFT JOIN labels AS labels_1 ON labels_1.[...] = tags.[...] LEFT JOIN labels AS labels_2 ON labels_2.[...] = tags.[...]".

This is functionality that will need to be added to QueryBuilder at some point no matter what, but it's something one of the higher ups should decide on how to implement it.

I'm gonna say this'll definitely be fixed, but it'll probably be a while.

*** Bug 145925 has been marked as a duplicate of this bug. ***

To solve the SQL part is really easy. 
This SQL-Statement is one of many possible solutions:
 
  "select distinct t.* from tags as t        /* or what is needed to return */
       inner join tags_labels as tl          /* relations from tag to label */
            on t.url = tl.url and t.deviceid = tl.deviceid
       inner join labels as l                /* convert labelname to labelid */
            on tl.labelid = l.id
  where l.name in ('jazz','soft','any else..')"   

Can be quite simpler if Amarok already knows the labelid's

*** Bug 147298 has been marked as a duplicate of this bug. ***

Bug 147298 describes something a little different and in fact I verified that it works differently on SQLite and MySQL. Maybe rewriting the query builder will fix both bugs, though

I'm especially keen to see a solution to the total uselessness of label "does not contain" as described in Bug 145925.  It's still a problem for Ubuntu's Amarok 1.4.7.

Unfortunately this problem is not easy to solve. The sql code is easily fixed, but getting that into the logic which parses the smart playlists is just about impossible. Obviously there were a few shortcomings in the design of this code, but hopefully the rewrite for Amarok 2 will solve these problems.

I'd suggest removing the option for 'label does not contain X' until it's fixed.  As it is, I don't see how it's possibly useful.  Having such a severe bug in software is sort of amateurish.  I don't mean to insult the amarok developers -- it's a fantastic piece of software and I appreciate the efforts of everyone who's worked on it.  However, this function is completely broken and, IMO, software features should at least mostly work or be left out.

As Seb said we can not fix this in Amarok 1.4.x.
Closing as wontfix therefore.
Please check this again in Amarok 2 once it is released and open another bugreport if needed.

Thank you for your report.

Can anyone explain to me how hard is it do do a stupid LEFT JOIN or perhaps adding a "or label NULL" to the query when doing label-based queries?

@Rudd-O

Our queries are automatically built and were not designed well enough to handle these cases. Trust me, I have looked into this problem many times and it is not a trivial solution. 

Amarok 2 totally resovles this issue.

I don't know how QueryBuilder exactly works, but with a query like this:
SELECT url,labels FROM
(
SELECT url, group_concat(labels.name) as labels
FROM tags_labels
LEFT OUTER JOIN labels WHERE tags_labels.labelid = labels.id
GROUP BY url
)
WHERE labels LIKE '%mainstream%'
AND labels LIKE '%dance%'

The subquery will always be the same and can passed as a constant for a tablename. So the query just looks like the form:

SELECT url,labels FROM table
WHERE labels LIKE '%mainstream%'
AND labels LIKE '%dance%'

Is QueryBuilder able to handle this?