Crash in in_mp3.dll while indexing

[odoll]

Since a couple of releases (can't recall when it began) Windows (XP Home or Prof | DE (http://webtone.beyenburg.de/Winamp/Winamp_Crash.jpg) or EN (http://webtone.beyenburg.de/Winamp/Winamp_Crash2.jpg)) reports a crash of Winamp 5.551 in in_mp3.dll.

I think it happens while Winamp indexes my (remote) library (e.g. without doing something else). As far as I can tell the files still displayed in the dialog play fine (without a crash) when I attempt to play them.

[odoll]

I can't track the issue down to a specific file :-(
It is a really strange behavior.

The filename shown last as being opened can be copied to another directory and indexed there without any problems.

Also the solely directory containing this file with a few others can be indexed, but instructing Winamp to start indexing one level upwards leads to a crash again.

Using Sysinternal's Filemon to catch the last file opened reveals an even more strange situation.

The file shown in Winamp and Filemon as the last being accessed before the crash is the same and the last in a (sub)directory, e.g.

10 abc.mp3
14 def.mp3
17 ghi.mp3
28 jkl.mp3

But when I rename the last file "28 jkl.mp3" to e.g. ""28 jkl.mp3-" to prevent it from being recognized as audio file Winamp and Filemon show "17 ghi.mp3" as the last file being accessed before Winamp crashed.

I'm running out of ideas ...

[odoll]

problem persists in version 5.552

[DJ Egg]

Remote library? Are the mp3's on a network drive or something?

Alas, I'm not sure how we would go about trying to reproduce something like this....

Was this a clean install of 5.552?
Are there any 3rd-party plugins present?

[odoll]

My standard "production" music archive sits on a network share (USB HDD attached to an unslung Linksys NSLU2 running samba; e.g. \\share\Music\). The samba is also the DC for my Windows network (all Win XP Prof fully patched (either EN or DE versions tight into my domain).

Nevertheless my "master" sits on an NTFS formatted USB HDD (normally turned off) directly attached to one of my Windows PCs.

A crash occurs both either indexing \\share\Music (or further down in a subdir) or the e:\Music.

For performance reasons while "debugging" I copied my master set to another (FAT32 formated) local USB HDD, on which I performed several "mp3 repair activities" as I didn't want to effect my master at that point, unless I would have found a fix which could be seen as a workaround.
Though mp3s are corrupt, Winamp shouldn't crash at all (IMO).

I did my tests on a "clean install" in that sense that I renamed my existing c:\Program files\Winmap directory to *.bak and did a new install of 5.551.
I didn't change anything on the C:\Dokuments and Settings\<user>\Application Data\Winamp\ dir.
As that didn't help, I reverted to my initial setup.

For the test of 5.552 I just did an update to 5.551.

Do you want me to perform an even cleaner install? What must be done to have really clean install (e.g. deleting some registry entries as deinstallaing WInamp is not good enough?!)

Hmm, I could also try to have Winamp installed in my virtual Vista running on that same PC in VMware.

[odoll]

Hm, did an install of Winamp 5.552 on a "fresh" Vista HP running in a VM. Though Winamp complained about the DirectSound audio driver the indexing of the music files on the network share completed successfully after some minutes.

Encouraged by this success I de-installed Winamp (System -> ...) from my XP system, rebooted, deleted the dir under Doc&Sett and the Winamp folder in Programs, re-installed Winamp and started indexing the network share folder. After a few minutes again Windows reports a crash in in_mp3.dll :-(

[odoll]

BTW: 5.56 still crashes on my "production" XP PCs, while the indexing on my Vista VM works fine. Guess I have something insrtalled by default which conflicts with Winamp?! But couldn't spot it so far.

BTW2: as a workaround I use a Vista based Winamp version to index my (network) library and export the (iTunes) library with the intend to import it to the other instances.

That I spotted an bug (or is this intended to be in sync with an iTunes bug)?

Indexing a file from local drive

E:\music would result in

file://localhost/E:/music/

while indexing

\\share\music

the path in the xml export starts with

file://localhost///share/music/

Importing the latter leads to entries starting with

\\\ (or ///) and Winamp can't find the file.

First I thought I'd have to delete the "//localhost/" part from the string as local host just stands for 127.0.0.1, so that it reads as

file://share/music/
or
file://share.mydomain.com/music/

but that didn't work neither.

Removing just one of slashes "/" to

file://localhost//share/music/

did the trick.