After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 621222 - [gapless] Play count should not be incremented as soon as song plays
[gapless] Play count should not be incremented as soon as song plays
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Metadata
1.6.0
Other Linux
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
: 632340 635922 640285 649756 (view as bug list)
Depends on:
Blocks: 638943
 
 
Reported: 2010-06-10 16:49 UTC by Antonio Roberts
Modified: 2014-01-26 23:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Antonio Roberts 2010-06-10 16:49:02 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
Comment 1 Michael Martin-Smucker 2010-06-10 20:11:50 UTC
I also noticed this, and it seems to only happen when Gapless Playback is enabled.  Confirming.
Comment 2 Brendan 2010-06-11 07:08:53 UTC
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.
Comment 3 Michael Martin-Smucker 2010-08-25 18:22:26 UTC
(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!
Comment 4 Brendan 2010-08-28 14:36:21 UTC
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.
Comment 5 Michael Martin-Smucker 2010-10-17 13:04:02 UTC
*** Bug 632340 has been marked as a duplicate of this bug. ***
Comment 6 Michael Martin-Smucker 2010-10-17 13:25:25 UTC
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).
Comment 7 Michael Martin-Smucker 2010-11-27 15:13:33 UTC
*** Bug 635922 has been marked as a duplicate of this bug. ***
Comment 8 Michael Martin-Smucker 2010-11-27 15:27:03 UTC
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.
Comment 9 Michael Martin-Smucker 2011-01-22 21:38:02 UTC
*** Bug 640285 has been marked as a duplicate of this bug. ***
Comment 10 Michael Martin-Smucker 2011-05-09 00:43:50 UTC
*** Bug 649756 has been marked as a duplicate of this bug. ***
Comment 11 Ismael Olea 2011-10-03 17:30:39 UTC
I deactivated the gapless option and tested it's not duplicating the song counter or the lastfm scroblling.

Using v 2.0.1.

fyi
Comment 12 Craig Duncan 2013-05-11 14:38:36 UTC
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
Comment 13 Andrés G. Aragoneses (IRC: knocte) 2013-05-13 14:59:28 UTC
(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
Comment 14 Craig Duncan 2013-05-13 15:40:50 UTC
Yes I have gapless playback enabled.

With it disabled the problem disappears
Comment 15 Andrés G. Aragoneses (IRC: knocte) 2013-05-13 15:42:07 UTC
Cool, thanks for the info Craig.
Comment 16 Andrés G. Aragoneses (IRC: knocte) 2014-01-24 01:28:32 UTC
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.
Comment 17 Ismael Olea 2014-01-25 22:07:39 UTC
Here it is the latest stable 2.6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6453707
Comment 18 Ismael Olea 2014-01-25 22:24:50 UTC
At first glance, seems the duplicated count is fixed now.
Comment 19 Andrés G. Aragoneses (IRC: knocte) 2014-01-26 16:41:06 UTC
(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.
Comment 20 Ismael Olea 2014-01-26 22:44:41 UTC
(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.
Comment 21 Andrés G. Aragoneses (IRC: knocte) 2014-01-26 23:01:11 UTC
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.