GNOME Bugzilla – Bug 621222
[gapless] Play count should not be incremented as soon as song plays
Last modified: 2014-01-26 23:01:11 UTC
When playing on a song the play count is incremented as soon as it starts. I think this should be changed to either increment when the song has finished or from when it is over 50% (or more) through the song. Using the method that is currently implemented one could easily get any song to the top of their most played list by holding down enter or double-clicking on the song many times
I also noticed this, and it seems to only happen when Gapless Playback is enabled. Confirming.
I noticed this also. The main annoyance with it is that it also adds a play count when it finishes which makes the play count +2 for only 1 play.
(In reply to comment #2) > I noticed this also. The main annoyance with it is that it also adds a play > count when it finishes which makes the play count +2 for only 1 play. Brendan, can you elaborate on "when it finishes..."? Do you get a play count of +2 for every track that finishes playing, or every time playback completely finishes (like if the playlist ends, or if 'stop when finished' is enabled)? I'm trying to figure out if this issue is actually the same as Bug 619970. Thanks!
What I'm saying is the play count number inclines by 1 when the song first starts playing and then once again when the track ends (plays right through, not stopped by user), however if I were to manually change track or press stop before completion this second incline would not happen. I believe the first incline when the track starts playing is the one that shouldn't be happening - either that or a bit of code that ensured that there is always 1 and only 1 incline for any amount of playing of a track, i think that would be a smart feature as currently on every media player i've ever used if you play 99% of a track but change it before then end there is still 0 play count which is a little silly imo... just a thought amidst my tiredness. Bug 619970 indeed appears to be the same thing I'm trying to explain & sorry if any time was wasted.
*** Bug 632340 has been marked as a duplicate of this bug. ***
I'm still not completely sure that 619970 is the same thing, but you answered my question, so I'm removing the NEEDINFO status. From the report that I just marked as a duplicate, it sounds like incrementing the playback at the beginning of the track breaks smart playlists that depend on a specific play count (like the default Unheard playlist).
*** Bug 635922 has been marked as a duplicate of this bug. ***
The latest duplicate, bug 635922 confirms that this causes problems for the Unheard playlist. IMHO, if some of these gapless issues aren't worked out by 2.0, it should probably be turned off by default (and maybe labeled 'Beta' in the preferences window) because it's causing some problems with a default smart playlist, play count tracking, and last.fm scrobbling.
*** Bug 640285 has been marked as a duplicate of this bug. ***
*** Bug 649756 has been marked as a duplicate of this bug. ***
I deactivated the gapless option and tested it's not duplicating the song counter or the lastfm scroblling. Using v 2.0.1. fyi
I never had this problem, but with an upgrade to 2.6.1 a similar bug has occurred. When letting banshee play through songs, it correctly increments the play count at the end of the track. However if you manually select a track to play, it instantly increments the play count, and then does so again at the end of the track, so any track you specifically ask to play, ask it's play count incremented by 2 instead of 1
(In reply to comment #12) > I never had this problem, but with an upgrade to 2.6.1 a similar bug has > occurred. > > When letting banshee play through songs, it correctly increments the play count > at the end of the track. > > However if you manually select a track to play, it instantly increments the > play count, and then does so again at the end of the track, so any track you > specifically ask to play, ask it's play count incremented by 2 instead of 1 Craig, do you have gapless playback option enabled or disabled? If you have it enabled, can you test if disabling it makes the problem disappear? Thanks
Yes I have gapless playback enabled. With it disabled the problem disappears
Cool, thanks for the info Craig.
I think I just fixed this in master and stable-2.6 branch: https://git.gnome.org/browse/banshee/commit/?id=6c890659b766879e0bbd08e6ea29d836b9c3281c I'm therefore setting this bug as NEEDINFO state. If someone has the expertise to build banshee from git, I would appreciate feedback about this. If none of you are able to do this, then let's just leave the NEEDINFO status until we release version 2.6.2 and packages appear, no rush. Thanks for being so patient.
Here it is the latest stable 2.6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6453707
At first glance, seems the duplicated count is fixed now.
(In reply to comment #17) > Here it is the latest stable 2.6: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6453707 Sorry, what's this? A custom package (equivalent to a PPA?)? If yes, can you confirm what's the last commit hash it's being built on? (In reply to comment #18) > At first glance, seems the duplicated count is fixed now. Thanks for testing.
(In reply to comment #19) > Sorry, what's this? A custom package (equivalent to a PPA?)? It's just a build I launched > If yes, can you confirm what's the last commit hash it's being built on? I've removed the git repo but I can assure it's the last one on «stable-2.6» branch at that moment. That build is not for being published at Fedora. Just for testing as you asked.
Ok, cool, let's mark this as fixed then, and if anybody can reproduce this in upcoming banshee 2.6.2, please reopen the bug. Thanks! This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.