GNOME Bugzilla – Bug 553399
Don't remove items from play queue immediately after playing
Last modified: 2009-09-10 02:17:12 UTC
I'd rather see Banshee *not* remove my songs from the play queue the moment they've finished playing. I can't go back to a song I just listened to (or to look up which song it was). Keeping the last N played items (perhaps configurable?) in the list (a la iTunes) would solve this issue in an elegant way for me.
I'd be a fan of this. I really, really like the iTunes party shuffle.
Keeping played tracks will also make "Repeat all" work.
Personally, I would hope that leaving recently played songs on the list wouldn't make "Repeat All" possible. If the user is listening to Song A in the music library and they think, "hmm, I'd like to listen to Song N next," they can drag it to the queue and Banshee will play it next. As soon as Song N finishes, Banshee jumps back to wherever it left off in the Library (this is a good thing). If the song didn't leave the play queue when it finished and Banshee started to "Repeat All," that could get pretty annoying in this (probably common) scenario.
(In reply to comment #1) > I'd be a fan of this. I really, really like the iTunes party shuffle. > Bug 571970 has a screen-shot of how this looks like in iTunes. In particular, there is a spin button to set up the number of recently played songs.
We do this in Last.fm right now, keeping the previous 5 songs I think (but disabling/greying them out b/c Last.fm doesn't let you go backward). I do like the small config panel at the bottom of a source that iTunes has for the queue.
*** Bug 565212 has been marked as a duplicate of this bug. ***
Created attachment 131539 [details] [review] First iteration Marking it as needs-work because the patch is still work in progress. Still to do: * Configure the number of tracks to keep, probably using the panel a la iTunes. * Save the current track when Banshee quits, currently the play queue will start from the first track if you restart Banshee. * "Previous" behaves oddly in some cases. I would really appreciate your feedback on it. I tested it as much as I could but I probably missed something.
I would love it if there were some way of setting N to infinite as well. There are times when I don't want any tracks to disappear from my playlist. I don't mind that the default behavior is disappearing after playing as long as I can choose to keep them in the list when I want to.
Created attachment 132109 [details] [review] Second iteration This patch saves the currently played song's position. It also adds a small configuration pane at the bottom that allows to change the number of played tracks to keep in the queue. Aaron also asked to change the opacity of played tracks, this still needs to be addressed.
(In reply to comment #9) > Aaron also asked to change the opacity of played tracks, this still needs to be > addressed. What's the best way to implement this? I see two options, probably there are more: 1. Subclass TrackListView and change the opacity from ColumnCellDataProvider() override, it would require a custom ISourceContents implementation. This is very similar to what the Podcasting extension does. 2. Extend the ListView to include IsRowOpaque in addition to IsRowSensitive and IsRowBold. Would require a new property on the TrackInfo. The first one is less intrusive: only the extension would be changed. On the other hand, the second one would allow other extensions to take advantage of this functionality. For example, Podcasting wouldn't require a custom ListView subclass.
I think the second option is better.
Created attachment 132321 [details] [review] Changing opacity of played items It also slightly re-factors the Podcasting extension to take advantage of the new functionality in the ListView control.
Created attachment 133092 [details] [review] Bugfixes This patch fixes a couple of glitches including the odd "Previous" behaviour mentioned in comment #7.
Created attachment 133544 [details] [review] Fixed a visual glitch when switching to the play queue
Some questions as I was reading the patch: Why does context.Sensitive still exist but isn't used? If a song is !Enabled b/c it's in the last 10 played in the play queue, does it also show up as translucent in Music Library and any playlists it's in? If it does (or maybe either way) we'll need to change the logic to be source-specific - so maybe a delegate on the ListView that each Source sets, eg list_view.IsRowOpaqueHandler = new delegate (TrackInfo track) { track not in last 10 in play queue } Can you put some explanatory documentation in where you've changed the SQL queries? Probably should have had some to begin with.
(In reply to comment #15) > Some questions as I was reading the patch: > > Why does context.Sensitive still exist but isn't used? Good catch, I will remove it. > If a song is !Enabled b/c it's in the last 10 played in the play queue, does it > also show up as translucent in Music Library and any playlists it's in? > If it does (or maybe either way) we'll need to change the logic to be > source-specific - so maybe a delegate on the ListView that each Source sets, eg > list_view.IsRowOpaqueHandler = new delegate (TrackInfo track) { track not in > last 10 in play queue } No, the song is translucent only in the play queue. The Play Queue has its own database model, changing Enabled doesn't affect other sources. > Can you put some explanatory documentation in where you've changed the SQL > queries? Probably should have had some to begin with. Will do.
Created attachment 133623 [details] [review] Updated to comment #15
Created attachment 134467 [details] [review] Fixed bugs when disabling and re-enabling the extension The global events were not properly disconnected from, the patch fixes this.
Created attachment 136208 [details] [review] Updated to git master + minor changes
Superseding patch from bug 565767 is committed to git master.