TrackLength is seconds rather than milliseconds

[Mark Kretschmann]

On Mon, Oct 26, 2009 at 5:48 AM, Victor W <victor.w at pervices.com> wrote:
> In the course of developing a patch for bug 195935, I've discovered think I've
> disovered another bug. This bug manifests itself as the slider apparently not
> working; with all the times are completely off. This was independently confirmed
> by someone else on #amarok.
>
> A sample debug log shows this;
>
> amarok:         BEGIN: void EngineController::slotNewTrackPlaying(const
> Phonon::MediaSource&)
> amarok:           [EngineController] Using gain of 0 with relative peak of 0
>
> amarok:            returning bookmarkcurrenttrack action
>
> amarok:           BEGIN: virtual void ProgressWidget::engineNewTrackPlaying()
>
> amarok:             BEGIN: virtual void
> ProgressWidget::engineTrackLengthChanged(qint64)
>
> amarok:                new length:  262
>
> amarok:                slider enabled!
>
> amarok:                BND: START - trackLengthText = Meta::secToPrettyTime(
> milliSeconds/1000 ) + '-  ' =  "0:00-  "
>
> (This all happens in src/widgets/ProgressWidget.cpp).
>
> The problem is that rather than being in milliseconds, it's expressed as
> seconds. The expection is that tracklength is in milliseconds, we end up
> dividing by 1000 which nominally gives us seconds, but in this case effectively
> returns 0. This breaks stuff lot of things.
>
> I've traced this back, and the millisecond value being passed to the function
> comes from The::engineController()->trackLength(), which comes from
> m_media->totalTime() which is a Phonon::mediaObject.
>
> The QT class specifications indicate that totalTime should be milliseconds. I'm
> not sure that this is a bug in QT as that something in my configuration is
> causing the decoder for MP3/FLAC files to return tracklength in seconds rather
> than milliseconds. For some reason, OGG files seem to work normally. I use a
> xine backend.
>
> If anyone has an idea about what may be causing this, I would really appreciate
> it; I'm not quite sure how to continue.

I think what you're seeing there is another symptom of our botched
database update code, which was necessary because of the big "seconds
-> milliseconds" migration we did all over Amarok. This bug is very
serious, but we're aware of it. That said, we really need to come up
with some ideas ASAP for fixing it somehow (I'm currently tending
toward forcing a full collection rescan).

Read up here:

http://lists.kde.org/?t=125459916600004&r=1&w=2


-- 
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org