GNOME Bugzilla – Bug 582968
There should be a way to configure the play queue so that items don't get deleted once they are played.
Last modified: 2011-01-07 20:44:13 UTC
As a user I don't want the play queue items to get automatically removed from the play queue once they are played. This behavior should be configurable and the user should be the final decision maker as to whether he wants the items removed from the play queue automatically or not.
Created attachment 134897 [details] [review] Proposed patch for this bug. Needs review. Adding the proposed patch for this bug. This patch fixes the issue. However this needs to be reviewed once before committing. Request the maintainers to review the patch.
I really don't like the idea of adding preferences like this. I'd prefer that we found a way to make the play queue support more use cases naturally. How are you using the play queue that makes this useful?
Jonathan, To answer your questions: >I'd prefer that we found a way to make the play queue support more use cases naturally Can you please explain by what you mean by naturally? Are you proposing that we change the behavior of the play queue to not remove entries from within the code, without any UI control for it within the preferences dialog? >How are you using the play queue that makes this useful? While enqueing. Actually I realized this problem when I wrote that plugin to enqueue audio files into the play queue(bug 582880). I found that even after I enqueue my files, they get popped off from the play queue once they are played. So, I wanted to change that behavior. After all, when I have spent like 10-15 mins cherry picking my audio and enqueuing them into the play queue, I want them to be retained. Maybe that will allow me to later save it as a playlist. So maybe a bigger re-architecturing of the play queue behavior is needed which may include: 1. User should be able to save play queue as a playlist. Not sure if current version of rhythmbox supports it already. 2. Repeat/Shuffle should also work with the play queue. I am not sure if this works today since the entries get popped off as soon as they finish playing. 3. Everything possible with normal playlists in general, should be possible with the play queue too. Please let me know your comments about my proposal. regards, Seemanta
Is there a reason you're not just using a playlist for this? It sounds like a playlist is exactly what you want.
> Is there a reason you're not just using a playlist for this? It sounds like a playlist is exactly what you want. Imagine that the user has several playlists. Then do we show all of them in the Nautilus context sensitive menu? But it would make more sense to just add the audio files into the play queue and then let the user decide its fate later on. Let me check the behavior of other music players on Linux and get back to you. But my bet is, all music players support in some way an 'unnamed' playlist from where entries don't get knocked off. Even in xmms, if you drag an item into the 'unnamed' playlist, it stays there and does not get deleted after it is played. I frankly think knocking off entries from the play queue is an usability issue. The entries should be retained in my IMHO. Was there any specific reason for going with this behavior? regards, Seemanta
The intended use of the play queue is to interrupt playback from the library or a playlist (or anything else) and then return to it. Leaving the entries in the queue seems pretty incompatible with that. Everyone so far who has asked for this modification has been wanting to use the play queue like a normal playlist, so I'm more interested in addressing the reasons they're not just using playlists. In the case of your nautilus extension, I think it would be appropriate to display all the playlists there.
>The intended use of the play queue is to interrupt playback from the library or >a playlist (or anything else) and then return to it. Leaving the entries in >the queue seems pretty incompatible with that. Err...we could always make sure that after the play queue has finished running, we switch back to whatever it was playing before rather than loop from the beginning as it would happen with play lists. Why to *remove* the entries: that is my fundamental doubt. And what are we achieving by removing them? Anyway after the play queue has depleted itself of all entries, we are switching back to the older source, right? Think from the end user perspective, all the entries that were meticulously created are lost. The least we can do is to provide the user with an *option* to control this behavior. And that's what this patch does. It does not enforce anything but gives control to the user to decide what behavior she wants from the play queue. regards, Seemanta
By removing entries from the play queue, we get them out of the way for next time the user wants to add something. If you're meticulously creating a selection of tracks, you should be using a playlist. That is exactly what they're for. If you're wondering why I'm opposed to adding simple preferences like this: http://ometer.com/free-software-ui.html
it happens that this play queue is more flexible than playlists. We pick a bunch of songs to play and then we decide if theyre keepers or not. Sometimes we know what songs we want to keep before, but we may just not. Creating a playlist and then delete songs do the trick, but its just seems not to be a "natural" way to do it. I dont understand how come someone can be against something like this, just cause "you should be doing it like we do". Just my opinion.. *I think this bug has something to do with this request -- http://markmail.org/message/65mbrdpteomwueap (queue behavior after finishing queue) is that being currently discussed somewhere else or is it just plain dead? thnx
The activity you're performing there is 'making a playlist'. If playlists aren't the most natural way to do that, then there's something wrong. If we add this preference to cover it up, we'll never find out what it is, so we'll never fix it.
yeah,, its "making a playlist".. *sigh* .. its not a matter of bad functionality,, just "users prefs". You know what.. nevermind (happy now? ¬¬)
No, not in the least. If you're not going to try to understand why I think adding this preference is the wrong solution, there's no point discussing this.
ditto..
hey.. guess what.. Listen player 0.6+ has the behaviour we have been talkin about--- maybe u could take a look at it so u can see what we meant.. thank you (sorry bout my attitude before)
Hello Jonathan, I've decided to register to this thread because I think this is a major flaw on rhytmbox, otherwise a very clean player... It's pretty simple: I don't want to be creating a new playlist everyday, according to all my moods. My mood keeps changing, and I simply want to have a temporary playlist where i can drop my songs. And it's very intuitive to drop it in a "currently playing" "playing queue", whatever you want to call it. And I don't want it to be persistent, i just want it for the night, or is simply a song i want to hear on an endless loop on a particular day. What's the point of not having this functionality? So, use cases: - My girlfriend is about to come. I have been putting together a couple of songs just for tonight, and there's no point in keeping them around, because they will be stating a point. If I decide it's good enough, then I'll drag and drop all this songs in a new playlist. - I just heard this new song by Beta Band, Dry the Rain. It's catchy, and I want to hear it over and over all day long. Will I have to create a playlist for this?? - I have a "Go Wild" playlist, and a "Be Wild" playlist. Each set half an hour. the party is meant to last for another 2 hours. I want to put them looping, and just because we love those songs. How do I do it? wait for one list to finish, both list to finish, and keep getting back to the computer for playing? I don't see why it's so hard to see that this "currently playing list", a temporary drag and drop for songs it's a basic feature of any player... cheers, hope this gets fixed in a next release, or I'll just have to drop back to xmms, when I like the clean display of rhythmbox :(
and btw, what's the use case for shuffling the Playing Queue then? :)
These are all use cases for regular playlists, as far as I can tell. I don't see where the play queue comes into it at all, except that it's slightly more convenient to add things to the queue than to a playlist. I also can't really see how this feature request would help with most of them. What I'm trying to get at here is that while playlists exist, and they already do most of what people are asking for here, there's some perceived barrier that prevents you from using them, and *that's* what the problem is, not that the play queue can't be configured to act just like a playlist.
Here we go again.. (In reply to comment #17) > These are all use cases for regular playlists, as far as I can tell. Exactly.. YOU can tell.. WE are telling different, now THAT should tell you something as well. > I don't see where the play queue comes into it at all, except that it's slightly more convenient to add things to the queue than to a playlist. Its not "slightly" its WAY more convenient. Daniel mentioned a key aspect in the above comment: MOOD. You cant expect users to create a different playlist every time we add or remove songs. I think I pointed that before, and I also said the major problem from my vantage point is the creation-naming process. Adding removing songs can be an impulse/occasional action, so with playlists alone, we'll end up at the end of the month, for example, with a hundred playlists, each one *a little* bit different than the next (one song or album extra or short) so, how can we keep track of what playlist have which songs? It will eventually be kinda absurd. I believe, by your reticence to analyze this *feature*, that you're the kind of user who just meticulously create several playlists and never change them, just create new ones. But then again I ask, eventually how can u tell which ones have which selection? Theres where I suggested the "playlist#1-minus-some-songs.m3u" naming pattern, which, If you take the time to think about, its just obviously ridiculous. > I also can't really > see how this feature request would help with most of them. You are not thinking outside your own using cases. > What I'm trying to get at here is that while playlists exist, and they already > do most of what people are asking for here, there's some perceived barrier that prevents you from using them, and *that's* what the problem is, not that the play queue can't be configured to act just like a playlist. Its not a "perceived barrier". The barrier is there. These comments are the prove of it. Playlists have they purpouse, and as you keep saying, they indeed serve it well. But we are asking for something different, which is what you refuse to consider. btw, i couldnt do much with the source code.. i couldnt even get rhythmbox to compile at the time.. And since this a "wontfix" then I guess we should just forget about it. Rhythmbox is an stable, solid player, we just believe it can be even better. But you probably have that "its just fine the way it is, if u dun like it then use something else" thinking.. thnx
(In reply to comment #18) > > These are all use cases for regular playlists, as far as I can tell. > Exactly.. YOU can tell.. WE are telling different, now THAT should tell you > something as well. I'm trying to understand the underlying problem that leads you to ask for this feature, which I am opposed to implementing, in the hopes that we can arrive at a solution where you get what you want without breaking anything else. > > I don't see where the play queue comes into it at all, except that it's slightly more convenient to add things to the queue than to a playlist. > > Its not "slightly" its WAY more convenient. The play queue is a larger drop target, and it appears in the top level of popup menus, whereas playlists appear in a sublevel. It's a significant difference if you're adding hundreds of tracks one-by-one, but otherwise it's not all that important. > Daniel mentioned a key aspect in > the above comment: MOOD. You cant expect users to create a different playlist > every time we add or remove songs. Why not? It's pretty easy to create playlists. Right click->new playlist->type name. It's also pretty easy to delete them. What's the problem? I think I pointed that before, and I also > said the major problem from my vantage point is the creation-naming process. > Adding removing songs can be an impulse/occasional action, so with playlists > alone, we'll end up at the end of the month, for example, with a hundred > playlists, each one *a little* bit different than the next (one song or album > extra or short) so, how can we keep track of what playlist have which songs? If you use the play queue for this, you'll obviously have to clear it out each time you want to make a new playlist. This isn't any easier than deleting a playlist. It > will eventually be kinda absurd. I believe, by your reticence to analyze this > *feature*, that you're the kind of user who just meticulously create several > playlists and never change them, just create new ones. But then again I ask, > eventually how can u tell which ones have which selection? Theres where I > suggested the "playlist#1-minus-some-songs.m3u" naming pattern, which, If you > take the time to think about, its just obviously ridiculous. What's with the .m3u extension? Are you talking about external playlist files, rather than playlists within rhythmbox? If so, I can understand why you think playlists are hard to use and take too much time, but the solution there is for you to learn how to use rhythmbox, not for me to redesign it to suit you. > > I also can't really > > see how this feature request would help with most of them. > > You are not thinking outside your own using cases. You don't know what I'm thinking. > > What I'm trying to get at here is that while playlists exist, and they already > > do most of what people are asking for here, there's some perceived barrier that prevents you from using them, and *that's* what the problem is, not that the play queue can't be configured to act just like a playlist. > > Its not a "perceived barrier". The barrier is there. OK, then explain it to me. For all of the use cases Daniel mentioned above, I'd use a playlist rather than the play queue. You claim you wouldn't, and I don't understand why not. > These comments are the > prove of it. Playlists have they purpouse, and as you keep saying, they indeed > serve it well. But we are asking for something different, which is what you > refuse to consider. It honestly sounds to me like you're asking for the ability to create playlists, which as far as I can tell already exists. > And since this a "wontfix" then I guess we should just forget about it. > Rhythmbox is an stable, solid player, we just believe it can be even better. > But you probably have that "its just fine the way it is, if u dun like it then > use something else" thinking.. That's not at all what I'm saying. All I'm seeing in this feature request is "please allow me to use the play queue like a playlist", and I don't see how "just use a playlist" is an unreasonable response to that.
(In reply to comment #19) > (In reply to comment #18) > > > These are all use cases for regular playlists, as far as I can tell. > > Exactly.. YOU can tell.. WE are telling different, now THAT should tell you > > something as well. > > I'm trying to understand the underlying problem that leads you to ask for this > feature, which I am opposed to implementing, in the hopes that we can arrive at > a solution where you get what you want without breaking anything else. Thats what we try to explain. The problem is not in the player itself, just there are some cases we feel playlists are not the way to go. > > > > I don't see where the play queue comes into it at all, except that it's slightly more convenient to add things to the queue than to a playlist. > > > > Its not "slightly" its WAY more convenient. > > The play queue is a larger drop target, and it appears in the top level of > popup menus, whereas playlists appear in a sublevel. It's a significant > difference if you're adding hundreds of tracks one-by-one, but otherwise it's > not all that important. > Well that might just be the case. But you're overlooking the main issue (for me at least) and I reiterate: if I create and save playlists every time I modify the queue list, then i will end up with too many variations of the same playlist and that will represent *the* problem, which is not in the player itself of course. > > Daniel mentioned a key aspect in > > the above comment: MOOD. You cant expect users to create a different playlist > > every time we add or remove songs. > > Why not? It's pretty easy to create playlists. Right click->new > playlist->type name. It's also pretty easy to delete them. What's the > problem? > This I said before too: to what should I rename it? playlist#1_plus_these_tracks_minus_these_other_tracks"? the problem is in correctly identifying which tracks are in each playlists, because if I save it, then its because I want to know that so I can play that list when the time is right. Then of course deleting one list its just easy. But the problem is what I stated above: too many variations of the same playlist are annoying and eventually will get very hard to keep track of. I in fact keep about 4-5 main playlists saved. Those are perfect, have a specific music selection and theres no trouble there. it works as intended. But, again, if I keep modifying/saving playlists I will lose track of them, cause eventually i wont be sure what tracks exactly are in each list saved. > I think I pointed that before, and I also > > said the major problem from my vantage point is the creation-naming process. > > Adding removing songs can be an impulse/occasional action, so with playlists > > alone, we'll end up at the end of the month, for example, with a hundred > > playlists, each one *a little* bit different than the next (one song or album > > extra or short) so, how can we keep track of what playlist have which songs? > > If you use the play queue for this, you'll obviously have to clear it out each > time you want to make a new playlist. This isn't any easier than deleting a > playlist. its easier cause u don't have to save/name it, which is what I consider the main problem. > It > > will eventually be kinda absurd. I believe, by your reticence to analyze this > > *feature*, that you're the kind of user who just meticulously create several > > playlists and never change them, just create new ones. But then again I ask, > > eventually how can u tell which ones have which selection? Theres where I > > suggested the "playlist#1-minus-some-songs.m3u" naming pattern, which, If you > > take the time to think about, its just obviously ridiculous. > > What's with the .m3u extension? Are you talking about external playlist files, > rather than playlists within rhythmbox? If so, I can understand why you think > playlists are hard to use and take too much time, but the solution there is for > you to learn how to use rhythmbox, not for me to redesign it to suit you. > Mmm sure you're right, i meant the ones within rhythmbox, but the case its just the same: too many variations, too many playlists to keep track of them. > > > I also can't really > > > see how this feature request would help with most of them. > > > > You are not thinking outside your own using cases. > > You don't know what I'm thinking. Well, thats probably true.. > > > What I'm trying to get at here is that while playlists exist, and they already > > > do most of what people are asking for here, there's some perceived barrier that prevents you from using them, and *that's* what the problem is, not that the play queue can't be configured to act just like a playlist. > > > > Its not a "perceived barrier". The barrier is there. > > OK, then explain it to me. For all of the use cases Daniel mentioned above, > I'd use a playlist rather than the play queue. You claim you wouldn't, and I > don't understand why not. its not that the playlists can't do the job. its that the playlists will grow too long and will eventually defeat their purpose (gather and organizing selected music tracks) since we won't be able to easily identify which tracks are in which playlist, at least not without naming the playlists in a very awkward fashion. > > These comments are the > > prove of it. Playlists have they purpouse, and as you keep saying, they indeed > > serve it well. But we are asking for something different, which is what you > > refuse to consider. > > It honestly sounds to me like you're asking for the ability to create > playlists, which as far as I can tell already exists. No, playlists are meant to be fixed selections of tracks. We are talkin about spontaneously created lists, which we would like to keep for some time, but at the same time be free to add/remove tracks. Doing this with regular playlists will end up with a zillion playlists. > > And since this a "wontfix" then I guess we should just forget about it. > > Rhythmbox is an stable, solid player, we just believe it can be even better. > > But you probably have that "its just fine the way it is, if u dun like it then > > use something else" thinking.. > > That's not at all what I'm saying. All I'm seeing in this feature request is > "please allow me to use the play queue like a playlist", and I don't see how > "just use a playlist" is an unreasonable response to that. Well you're not saying it but the "wontfix" status speaks it up. And thats ok. Take a look at Listen Player and you will see what we mean, and you may even understand why its not the same as playlists. thnx
> No, playlists are meant to be fixed selections of tracks. We are talkin about > spontaneously created lists, which we would like to keep for some time, but at > the same time be free to add/remove tracks. Doing this with regular playlists > will end up with a zillion playlists. How does making the play queue act like a playlist help? If you try to do this with the play queue, you have to clear the queue out every time, which is equivalent to deleting a playlist. I really don't see how this feature would make anything easier for you, aside from relieving you of having to name playlists. Telling me to try another piece of software isn't going to help. The things that are problems to you (naming temporary playlists, apparently) are not problems to me, so I'm probably not going to understand it that way.
Again, playlists are static, fixed, its not flexible this way for some cases. I only pointed you to Listen player because it has the desired behavior. But you are right: it is MY problem, not the software itself. Thank you again for your time, I'll stop making silly requests now. thnx
(In reply to comment #22) > Again, playlists are static, fixed, its not flexible this way for some cases. Where did you get this idea? A play queue that retains entries that have been played is *exactly the same* as a playlist. This is the point I've been trying to make since about comment 6. If the user interface is somehow giving you the idea that you're not supposed to modify playlists, then that's something we should try to fix.
mmm I see it as a "de facto" playlist, cause you don't have to save it and thats the only difference. As I already said, the software itself doesn't work the wrong way or anything. I know what playlists are and how to use them. I do use them. Just for some cases i simply don't want to save a playlist, but still keep the tracks. This might not be a *starndard* way of using it, but since there are some of us looking for this capability, then it should be there. Thats why its called "user preferences". Again: there is nothing wrong with the software. thnx
*** Bug 604856 has been marked as a duplicate of this bug. ***
I've just been reading this thread and would like to jump in now, both because I just requested the same thing, (a play queue which doesn't drop songs as they are played), and because I feel I can offer some insight as to why it is desirable to have a 'persistent' play queue. When I create a playlist, (one that I plan to keep and re-use many times), it's an iterative and dynamic process. I add a song or two to the 'Play Queue', and while they're playing I search through my collection for what I might like to have next in the list. I add songs, and play around with their order to determine what works for me. Often, (and I mean -very- often), I will move the position slider to near the end of a song, and let it play into the beginning of the next song, just to hear the transition so I can decide whether I like it or not. In Rhythmbox I'm simply out of luck at that point, because the song I just 'finished' playing, (even though I was in no sense 'finished' with it), is no longer in the queue. Sure, I could find that song again among the tens of thousands in my collection, then add that song back in, and save the queue to the playlist after EVERY SINGLE ITERATION, then reload the playlist EVERY SINGLE TIME A SONG FINISHES PLAYING so I can be sure of being able to re-order all of the songs at will. But frankly, besides being inorganic and non-intuitive, it's just WAY too much trouble to be even remotely viable. Playlist creation and editing is not a standalone process. The queue is not the playlist, but the only realistic way of creating a playlist is to save the queue contents, and if the queue keeps dropping songs then I effectively have no playlist creation capability. So as Rhythmbox currently stands, it does not support creating and editing playlists. This makes it a real standout among virtually all the other players out there, but I'm not sure this is a way in which you want Rhythmbox to stand out. (In reply to comment #23) > (In reply to comment #22) > > Again, playlists are static, fixed, its not flexible this way for some cases. > > Where did you get this idea? A play queue that retains entries that have been > played is *exactly the same* as a playlist. This is the point I've been trying > to make since about comment 6. If the user interface is somehow giving you the > idea that you're not supposed to modify playlists, then that's something we > should try to fix.
As with every other person arguing for this change, there's some reason you aren't just using playlists to create your playlists, but I can't see any attempt at explaining that here. Maybe you could focus more on that and less on the all-caps hyperbole and other nonsense.
LOL u know.. I really cant understand how much more thorough can one be explaining situations in which we are not using the playlists for.. perhaps you should consider putting yourself in place of your users for once..
If you're not going to even attempt to provide the information I'm after, don't bother commenting.
Forgive me, but thats the point: I really don't understand whats this info you want us to provide,, since we tried our best to explain why we are requesting this. I do mean it when I tell u to try to be your users for once.
(In reply to comment #27) > As with every other person arguing for this change, there's some reason you > aren't just using playlists to create your playlists, but I can't see any > attempt at explaining that here. Maybe you could focus more on that and less > on the all-caps hyperbole and other nonsense. I think the really long reply I just posted to this got lost somehow, so here's a short version. (And thanks for holding out against the onslaught; I wouldn't have understood clearly the reasons for my own dissatisfaction if you hadn't pressed the point). If I'm using the 'official' playlist editor, I can't look at my music collection and the playlist I'm building simultaneously. The inability to look at a playlist as it currently exists while choosing songs to add, is vital to the process of building a playlist. Additionally, if I could use the Play Queue to build playlists, then adding a song would just be a click and a drag away. And, while I'm dragging a song I can put it anywhere in the playlist. To use the 'official' playlist editor to add a song, I have to scroll up to 'Music' and click on it, right click on the song I want to add, select the playlist I'm working on, then scroll back down to my playlist name and click on it to view the playlist, and then move the song I just added to the desired position in the playlist. That's A LOT, (excuse my 'all-caps hyperbole), of extra mousing around, compared with 'a click and a drag'. And it's not trivial even for a half-dozen songs, let alone 30 or 40. So add this extreme inconvenience and tediousness, to the fact that I can't even view the playlist while I'm choosing songs to add to it, and the whole thing just isn't workable. The Play Queue, (if it behaved as several of us are asking for it to behave), would be a really simple, clean, intuitive, obvious, and visible mechanism for creating and editing playlists. Furthermore, it's a process that a lot of us are used to, because we've used it extensively in other music players. I hope this clarifies things for you; it sure does for me!
Oops! The line should have read 'The ABILITY to look at a playlist as it currently exists while choosing songs to add, is vital to the process of building a playlist.'
Ok, I have been out of the scene for many days now and as the originator of this bug I have some comments which I would like to put forth here. First of all, there *should* be some way of having an 'unnamed' bucket for holding songs that I enqueue on the go, which I may or may not save as a playlist eventually. A facility should be there to save it as a playlist as well, but comes later. Obviously, you don't want songs to get knocked off this list. However, most users (including me) mistook the play queue to be this 'unnamed' bucket and tried to add features that this 'unnamed' bucket *should have(persistence), to the playqueue. Therein, lies the problem. We should not focus on the playqueue. It was created for a different purpose and let it exist. We(who think there should be a persistent 'unnamed' bucket for holding temporary songs) then would like to request a mechanism to add songs to this 'unnamed' bucket in the same manner as we were adding before. With the same convenience as with playqueue. I think we can reach a peaceful solution if we stop criticizing the playqueue and if we stop trying to do what we want the playqueue to do. Is there any possibility of having another source in RB which will act like how we want it to act? Without disturbing the current behavior of the playqueue, that is. OR If you think adding another source is too overkill then the *best* solution would be enhance playlist support to let us achieve what we want - ability to add new songs on the go, persistently, and later save them if we wanted. Because when you listen to a song, it is not necessary to save it into a playlist. Awaiting comments. ~seemanta
(In reply to comment #33) > Ok, I have been out of the scene for many days now and as the originator of > this bug I have some comments which I would like to put forth here. > > First of all, there *should* be some way of having an 'unnamed' bucket for > holding songs that I enqueue on the go, which I may or may not save as a > playlist eventually. A facility should be there to save it as a playlist as > well, but comes later. Obviously, you don't want songs to get knocked off this > list. > > However, most users (including me) mistook the play queue to be this 'unnamed' > bucket and tried to add features that this 'unnamed' bucket *should > have(persistence), to the playqueue. Therein, lies the problem. > > We should not focus on the playqueue. It was created for a different purpose > and let it exist. > > We(who think there should be a persistent 'unnamed' bucket for holding > temporary songs) then would like to request a mechanism to add songs to this > 'unnamed' bucket in the same manner as we were adding before. With the same > convenience as with playqueue. > > I think we can reach a peaceful solution if we stop criticizing the playqueue > and if we stop trying to do what we want the playqueue to do. > > Is there any possibility of having another source in RB which will act like how > we want it to act? Without disturbing the current behavior of the playqueue, > that is. > > OR > > If you think adding another source is too overkill then the *best* solution > would be enhance playlist support to let us achieve what we want - ability to > add new songs on the go, persistently, and later save them if we wanted. > Because when you listen to a song, it is not necessary to save it into a > playlist. > > Awaiting comments. > > ~seemanta I get your point about having a 'potential' playlist mechanism, so you can decide AFTER the fact to save it if you want to. It makes me realize that there've been lots of times when I've said to myself 'Gee, I really like that sequence of songs I just played -- I think I'll save it so I can use it again'. And Rhythmbox's current setup simply doesn't allow for that 'after the fact' decision to save a playlist. So thanks for reminding me of the original reason for this discussion. And now, I'd like to re-iterate why I joined the discussion, because the difficulties that brought me here are related to yours, but not the same. Simply put, in the existing method of playlist generation, the music collection is not visible while I'm editing the playlist, and this hampers my ability to choose a song based on what's already in the playlist. And, it takes way too much mouse-work to add a song to the playlist, then go back to the playlist to adjust the order, and so on back-and-forth between playlist and music collection. (Whereas if the Play Queue were persistent, one click and one drag would allow me to add a song anywhere in the list). So for me the issue is not only the 'persistent bucket', (although I agree 100%, and thanks for making me aware of it); it's also the fact that the existing mechanism is too cumbersome to be practical, even supposing that I started the whole process with the intention of creating a playlist. I really think the simplest, easiest, most elegant solution would be to add a configuration option allowing the user to specify persistence of the Play Queue. This would allow a user to decide AFTER playing a set of songs to save it as a playlist, and would also allow for straightforward and efficient creation and editing of playlists.
<quote> I really think the simplest, easiest, most elegant solution would be to add a configuration option allowing the user to specify persistence of the Play Queue. This would allow a user to decide AFTER playing a set of songs to save it as a playlist, and would also allow for straightforward and efficient creation and editing of playlists. <unquote> I actually did that. Since Jonathan refused to make this as an official fix, I went ahead and wrote my own 'personal' patch. So the rhythmbox that I use on my laptop does have that option to make the queue persistent or not, as the user chooses. This comes up in the Preferences menu. The ideal solution would be however, to address the impediments in playlist handling as Jonathan suggested and to make it possible for users to create playlists as intuitively as possible - that is assuming the playqueue behavior is not going to change. I don't care as long as I get the usability that I need - whether that comes as part of play queue or as part of the 'usual' playlists. ~seemanta
Thanks for taking the time to explain, I think we're getting somewhere now. I haven't really encountered the same problem myself because I tend to make playlists by adding all the songs I want, then rearranging them until I like the ordering. I mostly remove songs that don't fit, rather than going back to the library to find more. One relatively simple solution that comes to mind is to add the ability to display a selected playlist in the right side pane (currently used by the context pane plugin), in similar fashion to the play queue side pane. I'm pretty sure this could be implemented as a plugin without modifying the core code. This doesn't address the conceptual barrier to temporary playlist creation, mentioned a few times above. I don't know what to do about this, but I think it'd be necessary to avoid people reaching the conclusion that the play queue is meant for this kind of use. This feature wouldn't be especially obvious, even if the plugin was enabled by default. Does the 'recently played' playlist not allow you to capture sequences of songs you've already played? Creating a playlist from the last 15 songs is pretty easy - find the playlist, select the tracks you want, right click, add to playlist->new playlist; name the playlist. (In reply to comment #35) > I don't care as long as I get the usability that I need - whether that comes as > part of play queue or as part of the 'usual' playlists. I want users to get the usability they need, but I really don't want it to come as part of a modification to the most fragile and hardest to maintain section of code in the whole project. Any time the playback state code gets changed, five unrelated things break.
Thanks for responding to this. I didn't realize that changing the queue behaviour entailed so high a risk of introducing additional bugs, and I understand and support not 'fixing' something that already does what it was designed to do. And I think your proposed solution would bring something good to the table for a lot of users. For myself, I've come to the realisation that a greater variety of design philosophies makes the world a better place, and Rhythmbox successfully represents one of those philosophies. Rhythmbox doesn't mesh with the way I use a music player, but I've finally found a player that does support the way I play music and create playlists. So thanks again for your hard work on an excellent and popular application, and for your dedication and patience. Best Regards Paul Taylor
*** Bug 620300 has been marked as a duplicate of this bug. ***
How many more duplicate bugs will there need to be for re-opening the issue? ;-) The solution that arose of having a temporary playlist, deleting it and so on is very incovenient. At some point in the thread you referred "right click, new playlist, type a name, <do stuff>, delete the playlist". That's not the cornerstone of usability, imho. drag and drop to a playing 'temp' playlist that behaves exactly like a queue, except that itś not a queue but a bucket seems the logical way to go. Of course, this goes against usability, and so on and so on... but i guess the problem is out there, so it shouldn't be "resolved wontfix", but "wontfix", because resolved it ain't ;-) cheers, daniel
(taken from the duplicate bug) That is the typical usecase: I sit with my friends, drinking beer and listening to some songs that I queued up from my big library before. After a cool song finished playing, my friend tells me that he liked the song and wants to know the band. I cannot remember and I cannot have a look, because the song has vanished from the play queue already. Ideally the played songs should be greyed out and if I wanted to play them again, I should be able to move them to the songs in the queue that are to yet to be played. Banshee implemented this feature with perhaps unneeded bonus features like autofill: http://versia.com/2009/09/23/updated-play-queue-in-banshee/ But keeping track of the songs played before is certainly a basic feature and should be added to rhythmbox as well. Maybe Zeitgeist can be used to keep track of those songs?? That would be a great feature to enhance the Rhythmbox experience (queueing up songs by middle clicking them like in Winamp would be another great feature).
Youre wasting your time fellas... long story short: Rhythmbox is stable and solid as it is, more preferences go against ui design guidelines, playlists and queue works as they should already and pointing to some other players to illustrate the desired behavior or exhaustively describing use cases will NOT make any difference. Thats why its "resolved wontfix". Period. So.. use it at it is or move on. Try exaile, Banshee or Listen instead if u wish.
*** Bug 638918 has been marked as a duplicate of this bug. ***