Jump to content

Amarok/Archives/Amarok 1.4/User Guide/KeywordFiltering

From KDE Community Wiki

Introduction

This is partially taken from Amarok's handbook (Thanks to illisius for pointing out that handbook contains this information) and partially compiled from poking around.

You probably have noticed that you can filter playlist and, more importantly, collection browser by providing search terms.

Advanced syntax is also available.

Note: Starting with revision 620553 (after Amarok 1.4.4), there's a search string builder dialog, which can be accessed by clicking on a button at the right side of filter field. This somewhat obsoletes manual search string writing and looks like this :

Filter editor in Amarok 1.4.5

Basic things

By default, when you enter terms separated by spaces, it will search for items containing all of them. For example:

one two three

will search for anything that contains one, two, and three. However, you can put OR between terms to search for items that contain either, like this:

one OR two OR three

That way, it will search for items that contain either one, or two, or three (or a combination of them). "OR" is case sensitive. You can also use quotes to search for terms with spaces in them:

"Mike Oldfield"

That will search for items that contain "Mike Oldfield", but not, for example, ones that contain "Mike J. Oldfield".

Differences between playlist and collection browser

  • In playlist, it searches in all the columns of the playlist that are currently visible. However, you can use column:term to specify the column to search in:
title:amarok

(this can also be a column that isn't visible). This way, it will only search for items that have the word amarok in the title, and not, for example, in the album name.

  • In the collection browser, there's a default that illisius didn't remember.
  • Keywords are case insensitive in playlist filter and case sensitive in collection browser (that is, they must be all lowercase, or they are not recognised).
  • Empty keyword (year:) in collection browser would match nothing, in playlist it would match either empty field or everything (seems to result in empty for numeric values and all for textual).
  • Playlist has lastplayed:, collection browser does not - but no information so far how to use that one.

Let's call the terms that specify scope 'keyword' instead of 'columns' for the collection browser. So, specifying a keyword, followed by a colon and search term, would limit scope of the following term to the keyword.

album:stepped

When specifying a keyword, you can also search for items less than or greater than a term, for example:

score:>50

which will search for items with a score greater than 50.

year:>2005
playcount:<2
size:>80m

Last one, for example, returns only one song in my collection. If you have extensive Mike Oldfield collection, you might know which track that is.

To specify a term you don't want the items to match, you can put a minus (-) sign before them: -thing, to search for anything that doesn't contain thing. This includes keyword statements :

-album:a

will give you all albums that do not contain "a".

You can combine the above at will, for example:

"Mike Oldfield" OR score:>50 -comment:bad

That will search for anything that either contains "Mike Oldfield" or has a score greater than 50, but excludes items where the comment contains "bad".

artist:skatalites playcount:1 score>70

would find all played tracks whose artist contains "skatalites" and score is bigger than 70.

You can group tags by using quotes after keywords (it's the same as usually, just mentioned here in case it is not obvious) :

artist:"the skatalites" playcount:1

Keyword list

(thanks to andrewt512 for pointing out the correct file)

  • album
  • artist
  • bitrate (exact)
  • comment
  • composer
  • directory
  • disc/discnumber (exact)
  • filename (includes path. Note: The behaviour of this keyword changed in 1.4.2, see below)
  • mountpoint (the mountpoint of the device the file is on, since 1.4.2)
  • filetype (mp3, ogg, flac - etc; matches file extensions)
  • genre
  • length (in seconds, exact)
  • label
  • lyrics
  • playcount (exact)
  • rating (exact)
  • samplerate (exact)
  • score (exact)
  • size/filesize (in bytes, exact; accepts modifyers k & m - for kilo & mega, respectively)
  • title
  • track (tracknumber, exact)
  • year (exact)

Exact triggers only upon the exact string. This is true for all numeric values. For example, year:200 would not trigger on all years that contain 200, it would find only the exact value "200".

The behaviour of the filename keyword was changed in 1.4.2 due to Dynamic Collection. In previous versions, the search term was compared to the file's whole path. Now it is only compared to the file's path relative to the device mount point. For example, if you have a file /home/user/music/track1.ogg, and the file is physically located on a device mounted at /home/user , searching for filename:user will not return the file anymore. Only searching for filename:music/track1.ogg (or substrings of "music/track1.ogg") will list the file.

Examples

artist:varukers OR artist:"sex pistols" OR artist:"sham 69" playcount:>0 year:<1999 -size:<50m

Some caveats & possible improvements

  • There is no "equal or larger/smaller" operator. OR keyword can be used to emulate one.
  • playcount:<1 or -playcount:1 doesn't return tracks that are not played, but year:<1 returns all tracks without year set. Should be the opposite. Gotta check other numerical values.
  • firstplayed: & lastplayed: in collection browser would be nice.
  • Typos can be harder to spot in the collection browser, because invalid parameter is treated the same as no parameter at all and ignored.

For example,

aaaaaaaaaaaaa:aa

would be the same as "aa"

  • Having an explicit 'exact' would be nice. For example, there's a band named "A" - pretty hard to filter out by "artist:a"; also explicit "not-exact", to search for all years containing "200" (this seems to be less useful, see the last point about regexps).
  • There's "filename", which matches relative URL to the file and "directory", but nothing for the actual filename only.
  • Of course, for the Real Geeks That Love Music some additional regexp features might be interesting - for example ^ to note start of the string (could be used to find all tracks starting with a particular letter or phrase), or [a-z], or "ska.*{5}es". Can be done with direct database queries, but that is quite complicated.