Track history window too large?

[mixxxbot]

Reported by: jamie.gifford
Date: 2018-04-23T05:46:57Z
Status: Fix Committed
Importance: Medium
Launchpad Issue: lp1766163

---

The Track History mechanism deliberately omits tracks that have been played "recently". The definition of "recent" is hard-coded to use a window of 6 tracks in setlogfeature.cpp.

A window size of 6 is inappropriate for some use cases. For example, in tango DJing it is common to separate blocks of 3 or 4 tracks with a "filler" track. With a window size of 6, the filler tracks won't be recorded properly in the history logs if the same track is used repeatedly.

Could the window size be reduced (eg to 3), or made configurable?

[mixxxbot]

Commented by: daschuer
Date: 2018-04-23T06:44:00Z

---

This is related to the code that decides which track is currently. On one hand, we want to catch any track changes like requested here, on the other hand, a mashup of all four decks should not change the current track.

I think we need to do something mor intelligent, maybe we need a timer, or luck if a track is paused an re-cued.

Any idea?

[mixxxbot]

Commented by: jamie.gifford
Date: 2018-04-23T08:24:39Z

---

Currently the code in PlayerInfo::updateCurrentPlayingDeck examines all playing decks and picks the one with the highest gain as the "current" deck. When the "current deck" changes, it emits the currentPlayingTrackChanged signal, which is then filtered by SetlogFeature using the window of 6 to determine if a new history entry is written and the playcount is incremented.

Fair enough that a mash-up of multiple decks shouldn't cause the history to spasm, and I guess the window of 6 has proven itself as a reasonable filter for that case.

But if there is only one deck contributing to the mix, there is no question of a mashup and so in that case it seems reasonable to drop the "window of 6" filter and just unconditionally write the history entry and update the playcount.

It looks like it would be simple enough to change the signature of the

currentPlayingTrackChanged(TrackPointer pTrack)

signal to something like

currentPlayingTrackChanged(TrackPointer pTrack, bool force)

and have PlayerInfo pass force=true when there is only one source contributing to the mix.

[mixxxbot]

Commented by: daschuer
Date: 2018-04-23T15:03:02Z

---

Yes something like this sounds reasonable.
We will hit the same issue if we start to publish the playing track at Twitter or as a RDS tag while broadcasting. So we should decouple the logic from the history feature.

I am still unclear when the "force" flag should be set. Or should we just raise a timer, that removed duplicates for let's say 6 min?

[mixxxbot]

Commented by: ronso0
Date: 2022-04-15T19:57:49Z

---

#4726

[mixxxbot]

Issue closed with status Fix Committed.