Track history window too large?
Bug #1766163 reported by
Jamie Gifford
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Fix Committed
|
Medium
|
ronso0 |
Bug Description
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?
Changed in mixxx: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in mixxx: | |
milestone: | none → 2.2.0 |
Changed in mixxx: | |
milestone: | 2.2.0 → 2.3.0 |
Changed in mixxx: | |
milestone: | 2.3.0 → none |
Changed in mixxx: | |
assignee: | nobody → ronso0 (ronso0) |
status: | Confirmed → In Progress |
milestone: | none → 2.4.0 |
Changed in mixxx: | |
status: | In Progress → Fix Committed |
To post a comment you must log in.
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?