I don't know what the cause of this bug is, but this one-liner fixes it. The problem is that it only fixes the duration if the track has been loaded. But the fundamental idea -- number of samples divided by samplerate -- is robust:
=== modified file 'mixxx/src/engine/enginebuffer.cpp' --- mixxx/src/engine/enginebuffer.cpp 2011-07-28 20:21:01 +0000 +++ mixxx/src/engine/enginebuffer.cpp 2011-07-30 20:00:13 +0000 @@ -347,6 +347,9 @@ m_pTrackSampleRate->set(iTrackSampleRate); slotControlSeek(0.);
+ //fix the duration + pTrack->setDuration(iTrackNumSamples / (2 * iTrackSampleRate)); +
// Let the engine know that a track is loaded now. m_pTrackEndCOT->slotSet(0.0f); //XXX: Not sure if to use the COT or CO here
The question is if this is the right place for this hack, or if the scanner can do it instead.
I don't know what the cause of this bug is, but this one-liner fixes it. The problem is that it only fixes the duration if the track has been loaded. But the fundamental idea -- number of samples divided by samplerate -- is robust:
=== modified file 'mixxx/ src/engine/ enginebuffer. cpp' engine/ enginebuffer. cpp 2011-07-28 20:21:01 +0000 engine/ enginebuffer. cpp 2011-07-30 20:00:13 +0000 pTrackSampleRat e->set( iTrackSampleRat e); lSeek(0. );
--- mixxx/src/
+++ mixxx/src/
@@ -347,6 +347,9 @@
m_
slotContro
+ //fix the duration >setDuration( iTrackNumSample s / (2 * iTrackSampleRate));
+ pTrack-
+
// Let the engine know that a track is loaded now. pTrackEndCOT- >slotSet( 0.0f); //XXX: Not sure if to use the COT or CO here
m_
The question is if this is the right place for this hack, or if the scanner can do it instead.