This report echoes the concern in Bug 540525 comment 4. I haven't done much work with Banshee's code - especially recently - but with a little trial-and-error and IRC chatting, I think I might be able to figure this one out.  So, I'm going to be especially bold here and assign this to myself, but if I haven't produced a patch by the weekend, no one else should hesitate to fix it if they feel inspired.

Removing this as target=2.0; Michael, please consult a maintainer before setting that in the future; I'm using it as a way of keeping track of what I consider the most important bugs to fix for 2.0, and this isn't one of them.

This would be tricky to implement well when you delete multiple songs at a time, to ensure you don't select one of them and then it's deleted, so you get this churn for as long as it takes to delete the songs (which could be quite long).

It would be simple(r) to do if deleting only a single track that is playing.

(In reply to comment #2)
> Removing this as target=2.0; Michael, please consult a maintainer before
> setting that in the future; I'm using it as a way of keeping track of what I
> consider the most important bugs to fix for 2.0, and this isn't one of them.

Sorry 'bout that.  I figured that this is fairly easily doable by 2.0, even for someone like me.  I didn't realize that "target" also implies a priority, but I'll be sure to check first before re-targeting in the future.
 
> This would be tricky to implement well when you delete multiple songs at a
> time, to ensure you don't select one of them and then it's deleted, so you get
> this churn for as long as it takes to delete the songs (which could be quite
> long).

To handle this, I was planning on declaring a `bool was_playing_before_delete` flag (set to false) around line 500 of /Core/Banshee.ThickClient/Banshee.Gui/TrackActions.cs.  Then, in the following foreach loop, if (track.IsPlaying), I could set that flag to true.  After that, the player engine could be allowed to close, as it does now, then it would open and play after the track(s) are finished being deleted/removed (same logic would apply to line ~560).  Would this approach make sense?

If that is the right approach to take, then all I need to do is figure out how to start the player engine.  It looks like I need to pass in either a track or uri when opening the player engine.  If so, how is the track chosen?  Does the selected track have priority, and if nothing is selected, then choose either the first track in the library or a random track based on shuffle preferences?

I haven't looked too closely at the code yet; is there a more standardized way to pick the next track?  Something like an overloaded OpenPlay () method that takes no parameters might be what I'm looking for, but it doesn't look like that exists.

(In reply to comment #2)
> ...as long as it takes to delete the songs (which could be quite long).

Hmm, how long is 'quite long'?  Because even though my plan would ensure not choosing a to-be-deleted song, I guess it would still have to wait for the delete operation to finish, so still potentially a problem.  Maybe the better solution would be to pick a song, then make sure it isn't part of the current selection before starting to play it...?

Why not just `Next` instead of `Close` if the playing song is deleted/removed?

In case anyone is interested, I'm still working on this, but a fix to Bug 635951 will make this a lot easier to fix by eliminating the need to iterate through the whole selection to figure out which tracks are being deleted (which can definitely take awhile).

(In reply to comment #5)
> Why not just `Next` instead of `Close` if the playing song is deleted/removed?

I assumed the solution would be this simple when I signed up for the task. :)  Is there a next() method that doesn't require any parameters?  From what I've found, it looks like setting the next track expects you to tell it either a specific track or a specific uri.  If this is the case, is there a standard way of calculating the next track (or an example that I could use for reference)?

Wouldn't it make sense to have an overload of SetNextTrack that doesn't require a parameter and calculates the next track automatically?  or am I missing something?

(In reply to comment #6)
> Is there a next() method that doesn't require any parameters?

ServiceManager.PlaybackController.Next()

From what Gabriel said in Bug 635951 Comment 8, it sounds like the commit to fix that issue (http://git.gnome.org/browse/banshee/commit/?id=958a5e2743341ec87a6d17714815ca28f1ce6a1a) also fixes this issue, so I'm marking this as resolved.