Hmm, and now I can't reproduce. Could it be that this was not committed to the database, since I quit banshee right after the song finished playing...

(Anyway, it should also update the play count if I quit after half of the song has been played—at least that's how it works for skipping afaics.)

I see this and can confirm with 1.4.1.  It seems that the play count is updated when the next song begins rather than when the song finishes.  This is also the case for the last song in the play queue.  When the last song finishes, if Banshee doesn't start playing from some other source, that song's playcount doesn't increase.

Confirmed with trunk version.

Benjamin, do you not have bug editing privs?  If not, go to http://live.gnome.org/Bugsquad and get them.

*** Bug 586101 has been marked as a duplicate of this bug. ***

Created attachment 145027 [details] [review]
Call IncrementLastPlayed() when the playback is stopped

The patch fixes both this bug and the duplicate. Please test.

I tested this with the three scenarios that came up in this report and the duplicate:

1. Stop after song
2. End of the Play Queue (with manually added songs, when Banshee doesn't continue to another source)
3. End of a smart playlist of songs with 0 plays

All of these scenarios work flawlessly with this patch, and I haven't seen any negative side effects.

Committed, thanks for testing!

@Alexander: One more thing - and I realize that this is a bit of a separate issue, so I'll gladly file a separate report if you don't have a magical one-line fix up your sleeve - but a variation of this issue still exists with the play queue. 

If you're listening to the queue, and you tell it to "stop after song," the play count is now updated as expected, but the queue doesn't treat the song as if it were played.  For example, you listen to a song in the queue, it stops after that song; you then listen to a second song, not in the queue, after the second song finishes, it jumps back to the play queue and plays the song that you already listened to a second time.

If this takes any significant amount of work to fix, let me know and I'll file a separate bug for it.

Created attachment 146718 [details] [review]
Advance the current track if StopWhenFinished is on

Thanks Michael, this patch should fix it.

*** Bug 600612 has been marked as a duplicate of this bug. ***

Alexander, thanks for the patch!  Your patch fixes the issue as I described it, but the bug that I closed as a duplicate of this report is not quite fixed with the patch.  Specifically:

Let's say I'm listening to the play queue.  I choose "stop after song" and walk away from my computer.  If I come back to my computer awhile later and hit play, the same song will play again, because even though it is "grayed out" and marked as played, it is still selected.

It would be nice if when the "stop after..." song finishes, it would be moved up a slot, auto-dj (if on) would add another song to the queue, and selection would move to the next song.  This should avoid playing the same song twice in a row with "stop after song" enabled.

Michael, I committed the previous patch, thanks for testing it!

The issue you described applies to all sources, that's how the StopWhenFinished currently works: it stops playback without querying for the next track to play and changing the selection.

I'm not sure what the correct behaviour should be. For example if I'm in the music library and the shuffle is on, advancing to the next track means I won't know which song played last when I selected the "stop after..." option.

Anyway, I'm closing the bug because I think the play queue is now on par with the rest of the app in how it handles the "stop after..." option. Feel free to open a new bug if you think the option's behaviour should be changed, whether globally or only in the play queue.

Fair enough, and thanks for writing/committing the patch.  I opened bug 601538 to address the remaining issue.  I'm also not really sure what the best fix is.