Does anyone have the same problem?
Ufter update to 1.2.3, the display of the time (remaining, standard, whatever option I choose) is erratic. In most cases, the time does not change at all, in other cases, it shows very strange values. Also, the slider bar which tells you where in the track you are, stays either at the beginning or at the end of the track and does not move at all.

I run amarok 1.2.3 on KDE 3.2.1.

I believe, that this worked in earlier releases, but I am not absolutely sure. Is this a bug, or a misconfiguration on my side? If you need more information, let me know.

Otherwise, amarok is great!

This happens with xine-engine in combination with ogg vorbis. For some reason libxine returns bogus values here.

I\'ve just deactivated the length code in xine-engine (for now), so that again the length value from TagLib is used. So, upgrade to amaroK CVS to get it fixed.

Thanks for the advise.
However, I am using gstreamer and I only have mp3 files, so it must be something else.

nithilher wrote:

However, I am using gstreamer and I only have mp3 files, so it must be something else.

Try to choose a different sink (gstreamer output plugin). E.g. osssink.

Ok, I played around a bit.
xine-engine: ok
arts-engine: ok
gstreamer-engien: NOT ok, independent of the sink I choose.

I use gstreamer 0.8.7 and gstreamer-plugins 0.8.6
for a few seconds, it simply shows the legnth of the track and the slider is at its maximum right position, then it shows simply zero and the slider sits at its minimum left position. With the next track, the same strange behaviour happens again.

amarok writes a lot to .xsession-errors. Strangely, when using gstreamer, the output gets flooded with warnings about an incompatible type cast:
GLib-GObject-WARNING **: invalid cast from `GstDecodeBin\' to `GstMad\'

Anything else I can try or any other information I could provide?

Same problem here with amaroK 1.2.3, gstreamer-0.8.7. and plugins 0.8.5...

Similar problem... the time display works correctly with the xine engine on mp3\'s, but not with ogg files. When an ogg file is played, the current time slider stays at 0 for the entire song, with the song length displayed as a very large value like 17265.3 or so. With the gstreamer engine, the time display doesn\'t work for anything, the slider goes straight to the end of the song for both mp3 and ogg. Both engines, however, actually PLAY the song fine, it\'s just the timer.
I have libxine1 and libxine-dev versions 1-rc5-1ubuntu2.1 installed, libxinerama 6.8.2-2, as well as libgstreamer0.8-0 and libgstreamer-0.8-dev 0.8.7-1ubuntu3 and gstreamer-plugins 0.8.5-1ubuntu3.

This is xine and ogg issue a known bug and fixed only in CVS, sorry. I think this won\'t be fixed until 1.2.4.

There might be a xine/ogg problem, yes. But there is also a problem with gstreamer and the time display. It is not related to the sink used. Others report it as well. I do not have any ogg file. I do not use xine-engine because I want the crossfading. Has something concerning this *gstreamer-engine* problem been fixed in CVS as well?

nithilher wrote:

Has something concerning this *gstreamer-engine* problem been fixed in CVS as well?

No, since I did not experience it here. But I can imagine that it\'s a timing problem. We query the engine for the time-length immediately after starting playback. I could imagine on very fast computers the codec was not yet able to calculate the time.

I\'ll be investigating solutions, like delaying the query, or querying in regular intervals and adjusting the tracklength, as Totem does. This way the length calculation would get more accurate the longer a track plays. Might look a bit funny when the tracklength changes as you play, but it\'s the only way to get accurate data for VBR encoded material.

I could imagine on very fast
computers the codec was not yet able to calculate the time.

Ok, might be. My computer is a T42p with a 2 Ghz Dothan processor, but normally it runs on 600 Mhz. Perhaps, because I have 1 GB Ram, it is very fast.

I downgraded to 1.2.2, and the problem is the same. Also, the flooding of stderr with "(process xxxx): GLib-GObject-WARNING **: invalid cast from `GstDecodeBin\' to `GstMad\'"
is the same, I must have overlooked that. I don\'t have older sources right here, so I cannot check whether this was the same in 1.2.1 as well. But I know that I never noticed a strange timer behaviour in earlier releases.

I had my similar problem with both 1.2.2 and 1.2.3, worse with Gstreamer (which could not read time nor skip to a desired time for any song) than with Xine (which could for mp3s, but not ogg). I\'ve just gone back to 1.2.1, which performs fine under all conditions.

Everything\'s okay here with today\'s CVS and latest gstreamer-packages..

Hi again,
upgrading gstreamer from 0.8.7 to 0.8.9 fixed my issues.
Time display and navigation slider work now, flooding of stderr is gone.
Thus, I can use amarok 1.2.3 with gstreamer engine now!