GNOME Bugzilla – Bug 337308
Implement a playback queue
Last modified: 2008-01-29 03:53:49 UTC
I think I'd be a nice feature if there was a temporary playlist, probably somewhere on the left that you could drag files to to be played. If you close your player you loose this playlist, but if you want you can save it as a permanent one. It would be also great if after clicking a music file in Nautilus it showed in the queue (temporary playlist) waiting for being played.
Moving to the User Interface component.
This would probably be best implemented as a plugin. It could have a temporary source that provided the functionality you described. Renaming and moving to Plugins for clarity.
*** Bug 341043 has been marked as a duplicate of this bug. ***
Comments from bug 341043: Opened by Scott Ferguson 2006-05-08 16:15 UTC --------------------------------------------- Banshee should have the functionality to enqueue a song whether in shuffle mode or not. This could be added into the right-click menu when clicking on a particular file. Beagle used to have this functionality with Totem as well which allowed you to enqueue a song in Totem through Best.
Created attachment 83921 [details] Screenshot of Banshee + Beagle Banshee/Beagle still DOES have this functionality. See the attachment.
*** Bug 433780 has been marked as a duplicate of this bug. ***
Is there any consensus on whether this should be a plugin or a part of the User Interface proper?
This feature will be worked on shortly, but blocks on a number of other important features to be implemented efficiently. http://banshee-project.org/Roadmap
The feature shown in the beagle screenshot is still there. It's not a plugin. That is simply a source that allows you to enqueue local files for playback that are not imported to the library, so Banshee can play files from Nautilus or something without having to import them. It's not exposed in the UI directly because it doesn't make much sense unless invoked by a file manager or Beagle, in this case. You can use it like this: banshee --enqueue <filename> This is the default action for the banshee.desktop file, which Nautilus and Beagle use. --- Regarding the upcoming playback queue, which has nothing to do with Beagle or the Local Queue source (what the earlier comment in this bug described): It will be done in three stages: a) Allow playback to happen from a dedicated/flagged source. That is, when playing a song from source A, and switching to source B, if the song from source A finishes, the next song should be chosen from source A, even if source B is focused, unless a song is started explicitly from source B, at which point source B becomes the dedicated source. b) Add a dedicated "Queue" source. Essentially this will just act like a temporary playlist. It will have special logic that controls playback in a different manner. It will pop tracks off the top of the list after playback instead of moving the pointer down the list. c) Allow the dedicated queue source (b) to be detached (removed from the source view), and redrawn as a custom track list somewhere else in the UI (below the source view? on the other side of the track view?). This will allow you to control the queue without having to change sources. In all honesty, I want this feature to block on some more internal things that need to change regarding playback controlling, which will end up being tied to the new model that will drive the new view, so it's probably a few months off. If it's done with the current code base, I have a strong feeling that much of it will end up being rewritten when the new model/view and playback controller are introduced.
*** Bug 433840 has been marked as a duplicate of this bug. ***
Please specify the latest version of banshee you have been able to test this against or let us know that this is no longer a problem. Thank you for helping us keep track of your bug.
+1 This is the only thing that is keeping me as a Rhythmbox user.
*** Bug 490131 has been marked as a duplicate of this bug. ***
I would be nice if queue will not be cleared. Rhythmbox is clearing queue - this is stupid behavior, un-user-friendly.
(In reply to comment #14) > I would be nice if queue will not be cleared. Rhythmbox is clearing queue - > this is stupid behavior, un-user-friendly. At that point, would there be any difference between a queue and a playlist?
queue is kind of "current playlist", which is not to be saved. it should not be cleared because of usability.
I don't know how far the progress is with this feauture, but I have two ideas, some of which might be interesting (and easy enough?) to implement: - you could allow other playlists to be queued - if the queue is finished: what happens next? stop playing? play random songs from the entire library? pick a certain playlist? It would be nice to have all of these options in a simple richt-click menu just something that crossed my mind! thanks for all the effort, Grtz, mathijs
Part (A) is now complete, landed in trunk. From my Comment #9: "a) Allow playback to happen from a dedicated/flagged source. That is, when playing a song from source A, and switching to source B, if the song from source A finishes, the next song should be chosen from source A, even if source B is focused, unless a song is started explicitly from source B, at which point source B becomes the dedicated source." The other parts should be landing in the next week or so. The queue source *will not* get cleared like Rhythmbox. It essentially will just be a special playlist where tracks are popped from the top during linear playback, and any track played from it are removed after transition or completion. That is, it will behave like a play queue, but its state persists across instances.
Fantastic! In time I might like to contribute some things to this project, but for the time being I'm still learning C#, Gtk# and the like from square 0 (let alone that I've never used a subversion) thanks for the quick reply! Mathijs
Alright, the queue source is now implemented in trunk. It should behave like Rhythmbox from what I can tell. I initially thought RB did not persist the play queue across instances, but I was incorrect. So to be clear, we do persist it, and RB does as well. I'm going to close this now. We still need to implement the queue detaching, but I consider that a separate feature altogether and would rather not track it here. It is being tracked in our roadmap: http://banshee-project.org/Roadmap Enjoy everyone!