hello

(see title). That happened just yesterday. In order to see what changed, here are the modifications I did :

$ urpmi --update --auto-select --auto

and updating by hand
libopenssl0.9.8-0.9.8b-1mdk.i586.rpm
libtcl8.4-8.4.13-1mdk.i586.rpm
libtcltls1.50-1.5.0-1mdk.i586.rpm
openssl-0.9.8b-1mdk.i586.rpm
rootcerts-20051111-1mdk.noarch.rpm
tcl-8.4.13-1mdk.i586.rpm

As I discovered the problem, I updated to libxmms1-1.2.10-28mdk.i586.rpm
in order to install the last xmms rpm from the mandriva coocker, but mandrake/mandriva xmms rpms are buggy, so I recompiled from a tar.gz. But the problem persists.

The key of the problem is probably in the things updated with urpmi, but except some openoffice or some cdrecord/mkisofs related components, I don't remember what was updated, nor if it is dangerous for my system to have typed such command.

I think also that such delay must be caused by a library which is not immediately found in a default location...

Any idea or help would be welcome

is the file on the local disk or cd drive?
if you run xmms from the command line file an mp3 to play as the option, what is the output? it should print out what its doing (or trying to do) and may indicate what is taking so long.

if you open an mp3 in a different mp3 player does it take the same amount of time to play?

-the file is on the local disk
-from the command line it takes as much time the program need to run. the sound file is launched immediately, and I get no output.
-It doesn't take so much time with any other program, as I can immediately listen to the preview in KDE.

in fact, this seems to be a bug in xmms. As I run the file with a double-click, it often starts immediately, or with a delay of roughly 5 seconds, and the problem occurs only when I start the program. Any file launched after the 1st try is played immediately.

okay, this seems to be a bug in xmms : this occurs when I listen to the preview with KDE while xmms is running...