GNOME Bugzilla – Bug 100552
Multiple libraries would be nice
Last modified: 2011-07-26 19:46:30 UTC
Having more than one, non-overlapping, library would be nice. I could have one libary monitor my general music collection, and another monitor my inbox. This can't really be done with the collections interface. The ability to segregate libraries.
Your "inbox"? What is that? I am having trouble thinking of when you'd want multiple libraries versus just having a playlist.
I aquire new music, often downloaded from artists sites, etc. When I get new music, I'm not sure I want to add it to my permanent collection. I give it a listen first. I call the music that's queued up for review my 'inbox'. With rbox's current interface to use it to review new music I would have to add the music to the general library, somehow figure out which music is the new music and the old music (perhapse by manually creating a playlist), listen to the new music and then delete the stuff I don't like. So currently I launch xmms to listen to new music, and rythmbox to listen to my library of good music. What I'd like to be able to do is have rbox 'watch' my inbox directory and represent it as a separate library. New music automagically shows up in the 'inbox' library when new files appear in it, the demarkation between old (good) and new (who knows) music is clear. This could also be accomplished with another database column like "new" or "probationary", but that seems less elegant. Allowing dynamic playlists that watch directories for new music files would also solve this problem. Actually I think the 'watching' of one or more directories per library for new music files would be new feature as well, no?
*** Bug 133082 has been marked as a duplicate of this bug. ***
*** Bug 139256 has been marked as a duplicate of this bug. ***
I have a laptop that I use at home and at work. My whole music collection is on my desktop PC at home, on a NFS share, but I also have other songs on my laptop. There is also a huge collection at work coming from my co-workers, on a samba share. I need multiple libraries, and I also need to keep them safe even when remote shares are not available.
If an extra library is added the old could be titled Albums and the new could be titled Singles. This might even make Bug 154671 obsolete?
Actually, what you're asking for is already possible (at least in 0.9). Just create an automatic playlist, where "path" contains "~/Inbox", and one where "path" doesn't contain "~/Inbox". Consequently, any file located in ~/Inbox will be in one playlist, and the other files will be in the other playlist. Does it cover your needs ?
I have just checked out the latest source from CVS, and it doesn't quite furfill the needs. The problem is that when using the playlist trick, one can't search and select artist.
I think the biggest problem will be defining exactly what you mean by "multiple libraries" and figuring out how they will work. There are a couple of things that will definitely need to be considered: * if you can have multiple libraries, you should be able to have an arbitrary number of them * being able to have multiple libraries shouldn't get in the way of people who only want one * playlists, daap-sharing and other things will need to be changed to deal with multiple libraries I think that adding browsers and a search field to playlists (bug 118862) would be much simpler than trying to support multiple libraries.
Would a solution be, if the context menu from the Source widget have a "New Library" along with "New Playlist" and "New Automatic Playlist" ? Personally would I be satisfied with just one extra library for singles, because I have a interest in Bug 154671 aswell. I have now played a bit around with the cvs source, and I think I could submit a patch that keeps the original widget layout when going into playlist mode. Bug 118862 But what is the best solution? * One extra library is enough (e.g. called Singles)? * Add "New Library" via context menu? * Keeping original view in playlist mode (Bug 118862) and use Julien's playlist trick? * Shall the solution to this bug satisfy Bug 154671, so it can be closed afterwards? I won't mind trying to write a patch for the preferred solution.
I don't think adding a single extra library would work too well, because a) some people might not want it, b) some people might want more than two and c) giving it a fix name might not be best. The other two options, adding multiple libraries and doing the playlist enchancements, are basically the same thing. I don't think there is much difference in functionality between the two options. I think that the latter (modifying playlists) would be easier because the changes will be more localised. Adding multiple libraries would require touching much of the code, to modify it to handle multiple libraries.
Okay, so adding more libraries should be done by "New Library" from the context menu. I would prefere the New Library solution, but I am clearly not skilled enough to code that, so I will try submit a patch for Bug 118862 and use the Julien playlist trick.
Martin, it seems you decided support for more than 1 library is necessary to solve a problem of yours, however I'm not sure what that problem is. Your needs are exactly the same as those of the original reporter of that bug?
Yes, our needs are the same, but we would use the function differently. The reporter would use an extra library for his new albums, where I would use an extra library for singles, where singles are songs I haven't got the entire albums for. So as James explains in this email http://mail.gnome.org/archives/rhythmbox-devel/2005-October/msg00006.html a fixed name would be bad, as people would use an extra library very differently. When I think about it, I could imagine that some would use it for their iTunes purchased songs and the main library would be their CD collection.
The reason to have a different library is if you don't have always have access to the same files. E.g,; your have a collection of regularly-listened-to track on your local computer's hardisk, and another set on a remote server. There are many duplicate files between the two sets. Sometimes the sever is available, and sometimes not. (Maybe the local machine is a laptop, and is not always networked). I find myself in this position, and I'd love a "Local Library" and a "Server Library", if this is posible. I aggree that it's not sensible to limit to two libraries in the general case, though. I suppose playlists would have to be associated with one library or another.
the new versus existing and single vs album problems could and should be solved by "tagging" (fspot-style) files, since the same would go for various other songs, think of christmas carols that you don't want to hear in june, hardrock you might not like straight before going to bed, live music among the studio albums, intros. intermezzos and prologues (skip on shuffle, but play normally) etc, etc These are all things you'd like to have in the collection, but might or might not want to see or play depending on mood, time of year, time of day or various other reasons. Cases where a playlist just doesn't cut it. The having 2 libraries issue is very valid however.
Created attachment 58681 [details] [review] patch for "child library sources" This is a patch I posted to the ML about two months ago, which allows you to kind of have multiple libraries. It will probably need updating to current versions, and some more work done on it. Discussion was in the thread at http://mail.gnome.org/archives/rhythmbox-devel/2005-December/msg00012.html. The gconf key /apps/rhythmbox/library_locations already allows multiple values, but the UI only sets one. With this patch, if you have multiple values set (with gconf-editor) there will be "child libraries" created under the mail Library source.
Created attachment 63850 [details] [review] updated patch Updated to cvs, and a few minor improvements: * child sources use the Library icon too * not displayed if the user only has one library location set
I've committed this to cvs, with a few minor fixes. If you have multiple library locations set (only via gconf at the moment) you can view the "extra library sources" by using the expander on the library. The possible remaining bit is some UI for setting multiple library locations. Most suggestions for UI tend to make it harder (or more confusion) to just have a single library location, which most people will use.
How do the child libraries interact with playlists (both auto and static)? In the use cases above where you might have a "scratch" library for preview, it would desirable to have your automatic playlists *not* draw from the "scratch" area. Ideally it should be possible to create auto and static playlists that only draw from the main or one (or more) of the secondary libraries.
Why not have a "Filesystem" source, like in Listen, that allows you to open a folder and play sound files in that folder without adding them to your library? You could put files in your queue, edit tags, get lyrics, etc, all without putting the files in your library.
*** Bug 523565 has been marked as a duplicate of this bug. ***
*** Bug 567929 has been marked as a duplicate of this bug. ***
This is being worked on under bug 523162 now. *** This bug has been marked as a duplicate of 523162 ***
If I open rhythm box without my external hard drive plugged in (where all my music is) then it looses all the songs that were there and then takes ages re-importing them again once I plug the external hard drive in again. It also completely and utterly loses all my playlists. Luckily I mostly just use shuffle, because otherwise loosely the playlists would be really REALLY f*!king annoying, not just mildly f*!king annoying!
Josef, stop pasting the same comment into any vaguely related bug you can find. It's not helping.
Yeah, I was a bit annoyed (could you tell?), apologies for any uncouthness (but surely it does help a tiny bit to know how annoyed users can get? :P ) What would help? Is there an actually related bug? Or would it be best to post a new one. The most similar bug I found in my annoyance was on a redhat bug tracker from 2006 which would suggest this is a long-standing problem.