Display for elapsed / remaining time shows inaccurate values

[jus]

Tested with current trunk r2793.

1. Load a track, check the tracks duration (e.g 3:00:00)
2. Play trough the track or jump to the end
3. Notice the remaining time is not 0:00:00 and the elapsed time is not 3:00:00
4. The longer the tracks duration is , the bigger the difference.

Happens with compressed/uncompressed audio.

Regression from 1.9

[jus (jus)]

Mixxx reads incorrect durations for nearly all tracks in my library (mostly mp3`s) thus displaying wrong values for elapsed / remaining time and duration. E.g. in the attached example Mixxx reads 03:17.00 while the track is 02:48.96 ( as correctly read by VLC and Quicktime Player ).

Imho this bug is a blocker for 1.10.

[Owen Williams (ywwg)]

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.

[RJ Skerry-Ryan (rryan)]

Added a workaround to 1.10 that makes WNumberPos use the above fix. Changing the Track duration itself is not good because that will get saved to the database. Arguably the track is corrupt or we have a SoundSource bug if the metadata for the track says something that is different from iTrackNumSamples / (2*iTrackSampleRate) but I'd prefer not to permanently change peoples databases until we can figure out the reason.

[Daniel Schürmann (daschuer)]

The same issue is an aspect of Bug #1087437.

[Daniel Schürmann (daschuer)]

The issue is fixed with the patch from Bug #1087437.

[RJ Skerry-Ryan (rryan)]

The patch in Bug #1087437 looks good.

[Daniel Schürmann (daschuer)]

Committed to lp:mixxx/1.11 revision 3646.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5888