Display for elapsed / remaining time shows inaccurate values

Bug #780021 reported by jus on 2011-05-09
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
High
Daniel Schürmann
1.10
High
Unassigned
1.11
High
Daniel Schürmann

Bug Description

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) on 2011-05-22
Changed in mixxx:
importance: Undecided → Medium
status: New → Confirmed
jus (jus) wrote :

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.

jus (jus) wrote :
jus (jus) on 2011-06-19
Changed in mixxx:
milestone: none → 1.10.0
Bill Good (bkgood) on 2011-06-21
Changed in mixxx:
importance: Medium → High
Owen Williams (ywwg) wrote :

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) wrote :

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.

RJ Skerry-Ryan (rryan) on 2011-12-05
Changed in mixxx:
status: Confirmed → Triaged
milestone: 1.10.0 → none
Daniel Schürmann (daschuer) wrote :

The same issue is an aspect of Bug #1087437.

Daniel Schürmann (daschuer) wrote :

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

Changed in mixxx:
status: Triaged → In Progress
assignee: nobody → Daniel Schürmann (daschuer)
RJ Skerry-Ryan (rryan) wrote :

The patch in Bug #1087437 looks good.

Daniel Schürmann (daschuer) wrote :

Committed to lp:mixxx/1.11 revision 3646.

Changed in mixxx:
status: In Progress → Fix Committed
RJ Skerry-Ryan (rryan) on 2013-05-09
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers