play count increases even if same track is played

[mixxxbot]

Reported by: ywwg Date: 2012-05-16T20:31:13Z Status: Fix Released Importance: Low Launchpad Issue: lp1000431

---

If a deck is stopped and started multiple times, the play count will be increased every single time the play button is toggled. This could be fixed a few ways:

• don't increase play count unless a track is newly loaded
• keep a "we counted this one" flag, and don't increment the play value if it's already set
• don't increase play count if the current track has the same ID as the last track.

[mixxxbot]

Commented by: rryan Date: 2012-05-16T20:46:28Z

---

Yea.. this is from the history's new way of counting plays.

I prefer option 1 .. if the track is already marked played, don't count it again. I think that it still might be fair to add to the history ONLY if it wasn't the immediately previously played track (b/c you might play a track twice during your set) or maybe if it has been unloaded from a deck since it was first counted.

[mixxxbot]

Commented by: ywwg Date: 2012-05-17T14:00:17Z

---

Ok I'll give that method a shot. I notice this bug most when I'm bpm-ing and tagging tracks and I play them one at a time. I'll skip around and check things and the play count goes up to 6 or 7.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2012-05-17T14:26:15Z

---

This is also affected by the cross-fader. If you switch to deck B for like 1 second, then back to A, both tracks get a count increase.

I like method #⁠3, discard the increment if the current track was the last one played on this deck. (To avoid double-counting a track if you're previewing a number of them on this deck and reload the first one you previewed and decide to play it.)

[mixxxbot]

Commented by: daschuer Date: 2012-05-17T21:26:47Z

---

This bug depends on Bug #⁠783634.

The original solution had a "m_oldTrackIdPlayer[]" to detect if the track was newly loaded to the deck and to prevent multiple counts while heavy mixing. http://bazaar.launchpad.net/~daschuer/mixxx/features_setlog/view/head:/mixxx/src/library/setlogfeature.cpp This was lost on the way to trunk and I have not noticed it until now.

I thing this was most like solution #⁠1 and my favorite.

Inc played-count when a track is newly loaded AND played to the audience. Inc playcount again if the track is played again later in the evening.

[mixxxbot]

Commented by: rryan Date: 2012-05-25T03:50:17Z

---

I added a 6-track window that if the current-playing track is in the window it doesn't get an incremented playcount or addition to the session history. This way if you play a track later on in the night it still gets counted but quickly juggling between tracks doesn't count as an additional play. Sorry for removing this from the setlog branch Daniel -- I didn't like how it used track-ids since those don't work for itunes/rb/traktor but I forgot to add the logic back in!

[mixxxbot]

Commented by: daschuer Date: 2012-05-25T08:10:25Z

---

Hi RJ,

I just wonder why you think comparing the track Ids will not work. For the setlog feature every track played has to be stored in the mixxx database and must have a track ID. This should already be the case. If not, it is a different bug. A Track without a track ID can not be listed in the set log play list.

see: src/library/rhythmbox/rhythmboxtrackmodel.cpp line 50.

I would prefer to compare the unique track ID, because i am not sure if a pointer compare is valid in all conditions. Does storing it in a Linked list increment the reference counter of the shared pointer? Does this introduce a second kind of (not intended) track cache? We will get a new pointer address if the track falls out of cache and the comparison fails or furthermore can it be false equal?

Kind regards, Daniel

[mixxxbot]

Commented by: rryan Date: 2012-05-26T20:07:53Z

---

Hm, good point. It's very rare that a track will not have an id -- it would have to fail to be added to the library first.

This code has to process tracks that have an id and tracks that don't (because it is now the place in Mixxx that's in charge of marking tracks as played and incrementing their play count. We won't add tracks to the setlog playlist if they don't have an id)

In general, it's always valid to compare pointers because we don't ever have more than one TrackInfoObject for a library track (this list does keep hard-references to the tracks so they won't go out of cache).

Good point about the unintended track cache. When the SetlogFeature is deleted these references will be freed so the tracks will be saved before shutdown, but I agree this isn't ideal.

So to summarize, I think the only downside of using ids instead of TrackPointers is that tracks that don't have an ID will have exhibit the problem this bug describes -- their play count will be incremented every time they become the current-playing-track. This is OK though since we don't really display or record the play-count for tracks that aren't in the database (and you're right that RB/IT/T tracks are indeed Mixxx library tracks after getTrack()). I'll switch us to using IDs instead of TrackPointers.

Thanks for insisting :) RJ

[mixxxbot]

Issue closed with status Fix Released.