Christoffer's use case could be solved with Smart Playlists, but I've got another one:  I've got access to both my and my brother's audio collection (and my father's etc.).  Mine is generally cleaner tagged and most the time I prefer my own music (who doesn't), so it would be very useful if it was possible to put those in different collections (and have several Smart Playlists based on those).

Hi Malte. The use case I stated in my post wasn't really the actual one, something went wrong when I tried to write the simplest use example. :) The situation I have is basically the same as yours. I hope that your clarification will make the developers reconsider. Thanks.

This would be nice. I travel between locations often with access to very different, and very large repositories of music.  Right now I have to let the Collection remove the nonexistent entires and add the current music every time I fire it up in a new place.

It'd be nice to have multiple Collections, with each associated with different folders (or mount points). Then I could select which Collection I want to use at the moment, and the rest of the Collections would stay intact so that when I next want to use them they do not have to fully repopulate themselves.

Perhaps this can be combined with Bug 103642 and Bug 89314. Allowing a general 'label' to be attached to a song (album/directory/tree) could allow the playlist or collection to be filtered, and easy access provided to previous filters.

In this case the label might be the name of who owns the music or a name for where it is located. Doing it this way would satisfy both ideas and be far more flexible in the long run. I imagine for this however there would have to be some automatic labelling of new songs added to certain directories.

That and you could combine the votes :)

The label idea is nice, but I don't think it really solves this problem, and I think they should stay separate.  Here's why:

If I move to a new place and have different music available, I may have all that music under a specific label...however, this would not prevent the collection from being updated to purge my now non-present music and add the new music. Also, the label then becomes somewhat meaningless, as I could make a label for each location, but what if I want to refine it further?

It'd be better to have fully separate Collections, with the ability to mark one as the current Collection. Then, you could make labels that tie into these Collections.  So you could make one that, say, contains the Jazz music from your Home Collection.

(Sorry for the long comment)
As far as I can tell, there seems to be two related but separate wishes here:

1. To be able to distinguish between songs belonging to different people, perhaps based on file location
2. To prevent the collection update from removing entries in temporarily unavailable directories

WISH #2

Jeff is completely right is saying that it does not help wish #2. Sorry, I didn't notice this in my first reply.

WISH #1

I don't imagine it would be too hard to add a filter to the available songs based on what labels are defined, not unlike a smart playlist.

Note also that a single song or album might be owned by two people, which would demand the many to many relationship that labels, but not directories define (Well, directories could have symbolic links, but this is probably easier).

I would only add that it might complicate things for the average user to organise things in both "collections" based on file locations or "collections" (labels) based on abstract ideas. Unifying these two concepts might make things a little simpler.

WORDS

I would have to say that I prefer the word "collection", because both concepts try to identify a collection of songs (Christoffer's songs, Dad's songs, Jazz, songs at home, at work, at girlfriend's house). The word "label" hardly describes what it actually is.

RESPONSE

In response to comment #5, I don't see how "labels" cannot be refined further. You could no doubt automatically allocate labels based on which directories they were found in the auto update, or do it manually of course. Let me know if I've misunderstood this.

I just wanted to add a wish for a multiple collections feature. It's already there, so modified what I already wrote and add it here... got a bit lengthy though..

The backround logic:
My first thought was to have several collections based on directories. Simply because I would/could organize my files that way. However my second thought resulted in something like the already described labels. As that would be much more flexible and as in reality there is no simple one to one relationship between collections(labels) and directories(directory here meaning some kind of top level dir with possibly other dirs below). In fact there can be any combination. These are:

Case 1) Multiple collections in one dir: I want to group my own songs into different categories. However I don't need to and don't want to move them around. I'm fine with them staying where they are. Or my girlfried, she has all her music thrown in that one big folder. She is never going to sort that random heap of files into directories;) She might however move them around in the collection tree. 

Case 2) Multiple dirs for one collection: For instance I have two dirs, one where I put all the ripped copies of CDs I own in and another one with files I got from friends or so. But thats just an organizational distinction (e.g. I don't need to back up the copies from my CDs) and has nothing to do with the music. This is actually what you can do at the moment, just that there can only be one collection.

Case 3) One label for one collection: You take you laptop somewhere, mount some network drive with the music. 

For cases 1 and 2) the solution is to simply throw everything into one collection and let the user move it around as he/she likes. However that's not going to work for case 3) You certainly don't want to sort hundreds or thousand of songs or albums manually. But that can be solved at GUI level so that amarok does that for you, see below.

The user interface:
I don't like the idea of a drop down list for selecting collections. That would make song management much less intuitive. Or an example from personal experience: At our next party, from those running the party, I would put everyones music into an own collection, because we listen to pretty different kinds of music. On the party people can modify the playlist as they like. Now I guess the average Windows-only-if-at-all party guest, who has never seen amarok, will never ever get the clue to use the dropdown list to get the music from another person.

So instead add a new level at the top of the collection tree, being the name of the collection. Maybe it should already be there by default, called something like "My Collection", to hint the user: there can be more. Then a button or RMB entry "Add Collection". That would open a dialog asking for a name. And optionally for a directory (Case 3). But that would only help sorting all the songs in there into the new collection, and new ones appearing later to be added there. Other than that it would be treated like any other dir and you can move songs to different collections. Then there could also be a checkbox to make that collection kinda persistent (comment #5). 

Hmm, on further thought that persistence should be bound _only_ to directories, not collections! Because if you take an album from the "network collection" and put it into a different one, you'll expect it to be still there when you reconnect to that network. Or you might add such a temporarily available dir to an existing collection and expect the songs to be kept if the dir disappears. In general amarok should mark non accessable songs from those temporary dirs if the dir(or rather it's content) disappears, and reshow and update them if the dir reappears. But I'm leaving the topic...

*** This bug has been confirmed by popular vote. ***

support for multiple collections would be really handy later on if support for daap services was added and you were able to browse other peoples collections itunes style.

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

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

My ideas on this concept: 

Collection Multiples:

There are multiple reasons for this, myself, I want to keep my organised "Full Albums" seperate from my "other garbage", being either incomplete, or unorganisable. I would much like it to be possible to "hide" different collections.

So in my opinion, a checkbox list of collections would be nice, and the only thing the user has to do is point to where the collection is stored.

This could possibly be in the collection tree ie:
   <*> Main Collection 
           |-- etc
   <*> Removable Collection
          |-- etc
and have the check box to select if the collection is loaded/mounted/whatever

or, 
   <*> Main Collection 
   <*> Removable Collection
   ------------------------------------------
    |--   items here

and ticking the boxes toggles what is visible in the tree.

Removable Collections: 

Would be pleasant if each collection could have its own ( sqlite ) database in the collections root, so when a collection was moved from one machine to another, it would be possible transparently.

Here's a case that i have been thinking about a lot:

We have a server with lots of music which is accessible by nfs... It would be really nice to be able to have the collection for this data on the server itself, in a postgresql or mysql db... I still want to be able to include music from my local hd or other servers though!!

Maybe it would even be possible to have some type of mount-point-mapping, so that the mount-point for the server does not have to be the same on all clients!! :-)

With the standalone collection-scanner the server could keep the collection in sync and the clients wouldnt have to worry about anything!!

When I started commenting on this I was a user.  Now, as a developer, I can give you some information:

There are some wheels startig to turn in favor of modularizing the collection, to support various types of data stores.  Which ones I can't say right now, but we've had a lot of neat ideas ourselves, and we will certainly look to the user community for ideas.  Many (most?) devs agree that this is a necessary step going forward, but it's not easy and will not be quick, so I can't make any guarantees as to when it will happen.  A dev was going to do it as a Summer of Code project, and sadly just missed the cutoff...which doesn't mean it won't get done, but it means as he will not be funded to do it, it'll have to be on his own time as normal.

Keep in mind that we have amaroK 2.0 to look forward to as well, along with the huge task of porting amaroK to QT4/KDE4 as those platforms mature and become the standard.  Any new code we right now has to end up being ported anyways, so a project like this may wait...but it may not.

Essentially, what I can tell you is that I can't tell you much...except that this is increasingly a concern that the devs are taking seriously, and as we go forward, if we don't begin work on this kind of framework immediately, it will be in our thoughts as we refactor code and prepare for 2.0.

Hope this provides some useful information.  I'll write a RFC for you if you like.  :-)

aaand, are the wheels still turning? ;)

So what's the current state here?

Its in the TODO list in the 'longterm' items as far as I know, but thats the only progress I've seen on it.

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

Another use case:

* A very large single collection contains a lot of cruft. I have labelled a lot of files 'crap' and want to move these out into another Collection. I suppose this could be done with a label search of NOT crap, but I want to manage these as an independent collection. E.g. I do not want to waste Gb backing up crap music, just the good stuff.

Wow, so many votes.

Anyways, an update for everyone that wants to see this happen...

Amarok 2.0 development has begun, which involves major rewrites to pretty much every piece of code we have -- including the collection.  Right now the collection is being designed to be able to be a, err, collection of various, err, collections.  Highly modular.  So for instance, music from a SQL source (like the current collection living in the DB) will be one source; music from a portable media device may be another source; music from a web service (like Ampache) may be a third.

A lot is still up in the air, AFAIK, as far as to what exactly will be possible in the end (which might depend on how many and how fast plugins for this system can be developed).  I'm not sure for instance that you could have multiple SQL collections, and I'm also unsure that you could move music between them.  But do rest assured that multiple music sources is something that's being given heavy thought in the redesign.

Another use case: transfer from one collection to another

Suppose you have a laptop with limited space and some other computer with the bulk of your music files. When you connect to the remote share you can access both collections. Now I wish for a button that allows me to make sure that I can play this particular album once I disconnect from the share, so something like "transfer to local collection"

I'm closing this bug because it's coming in Amarok 2.0.  Open a new bug then, if it's not everything you ever wanted.  :-)

I want this feature too. Please take a look at the winamp smart views and collection browser. It's really powerfull and yet simple. I miss this functionality a lot.
The idea is: you create a "view" with a query that specifies what tracks it will display. Queries are built using special dialog (much like search dialog and message filter dialog in thunderbird) and can filter by filename, tags, play count etc. You can enter query expression yourself (it reminds SQL, but is really simplified). View also specifies how it will look like. "Simple" view lists all filtered tracks. "Simple album" shows two panels: the upper shows albums, the lower - tracks, selecting the album makes the lower panel show only tracks from that album. My favorite "Two" view shows 3 panels: artists, albums and tracks, so this view has 3 level grouping. You can find a song very quickly even if you don't remember the exact album and title. It takes 3 clicks usually.
I prefer to make views for all general genres in collection which are in separate directories. Theese views are called as genres and show only tracks from specified dirs. My collection is huge, but it's still easy to navigate using this method.
TIA.

(In reply to comment #23)
> I want this feature too. Please take a look at the winamp smart views and
> collection browser. It's really powerfull and yet simple. I miss this
> functionality a lot.
> The idea is: you create a "view" with a query that specifies what tracks it
> will display. Queries are built using special dialog (much like search dialog
> and message filter dialog in thunderbird) and can filter by filename, tags,
> play count etc. You can enter query expression yourself (it reminds SQL, but is
> really simplified). View also specifies how it will look like. "Simple" view
> lists all filtered tracks. "Simple album" shows two panels: the upper shows
> albums, the lower - tracks, selecting the album makes the lower panel show only
> tracks from that album. My favorite "Two" view shows 3 panels: artists, albums
> and tracks, so this view has 3 level grouping. You can find a song very quickly
> even if you don't remember the exact album and title. It takes 3 clicks
> usually.
> I prefer to make views for all general genres in collection which are in
> separate directories. Theese views are called as genres and show only tracks
> from specified dirs. My collection is huge, but it's still easy to navigate
> using this method.
> TIA.
> 

Most of what you just said is covered by the smart views technology, and the instantly toggalable view structure controls.  Most of the problem seems to revolve around amarok 1.x being capable of monitoring multiple directories, but it isn't able to handle the directories vanishing periodically, and when the multiple directories are available, it blindly interleaves thier content in the interface as if they were one large collection. 
Many of the comments appear to want to be able to categorise not /just/ on the metadata on the MP3's, but also be able to, in the interface, be able to distinguish between physically different groups, without having to sit down for hours and manaully tag mp3s to get the desired result. 
It would appear Amarok2 has already made inroads on this, and the collection list appears to have proviso for more collection sets, just it is currently inobvious how one creates multiple collections, or whether or not it will be extensible with a 3D party collection script ( that'd be sweet srsly ) 

(In reply to comment #24)

I installed KDE4.1 and some alpha (can't remember exactly) of amarok recently. I know that it's only alpha, but the collection view has degraded since 1.4.*. So I decided to request a feature, then found this one and just added my 5 cents. Just to be sure that I've done all I could before bitching on "bad" amarok :)
It's the best player on linux anyway.
P.S.: people, use EasyTag ;)

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

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

Alright, I didn't find this thread the first time around, so I reported it separately. Here is my $0.02:

I am an avid classical music listener, but I also like to listen to plenty of mainstream music as well. I also have a large collection of Christmas music. This causes problems, as one library never seems to work for me. When I'm listening to Classical music, for instance, I am interested in different fields (Composer becomes much more relevant, but I don't care so much about Album). Plus, it's just annoying to have them all mixed together. I have a large collection of classical and a large collection of mainstream music, and I really just want them separated.

Closing correctly as Amarok 1.x is unmaintained since quite some time anyway.