Post All Winamp 5.666 Core Bug Reports In This Thread

[Juanus]

Reproduced the crash with that file, also it doesn't crash when I open the mass tagger via the library only via playlist it crashes.

I've checked the file with MP3Val and there does not to seem any issues with the header or the tag.

I'm not able to create a report with procdump, when Winamp closed, procdump only said, that the process has been exited.

Koopa, Thanks for varifying that. I also tried to check the tags and such to see if there was any difference between the files that would make it crash and the ones that didn't. I wasn't able to find anything out of the ordinary.

For me it's only crashing when I click 'Update' without actually updating any of the tags. If I select a tag and change it, then click 'Update', it doesn't crash. Is that what everyone else is seeing?

Nope getting the crash when i update 'Producer' field for example.

I get the crash no matter if I update a field or not, as long as I press update, it crashes. And like I said, on some mp3 files, it will crash, on others, it will not. So I don't know what the difference between the files (or way that the files are processed) might be.

[MrSinatra]

does it matter if the file is currently playing or not?

[lostinsound]

I'm also finding that when you use 'Edit metadata for selection...' in the Playlist Editor for tracks that aren't already in the Media Library, it adds the tracks to the Media Library when you click 'Update'. Not sure if that's intended or not.

[ryerman]

I'm also finding that when you use 'Edit metadata for selection...' in the Playlist Editor for tracks that aren't already in the Media Library, it adds the tracks to the Media Library when you click 'Update'. Not sure if that's intended or not.

I see the same behaviour. I hope that is not intended.
Files in the Playlist Editor can be added to the Library using the Send To menu and my opinion is that files should not be added merely because their metadata is edited.

[MrSinatra]

I think I went over a similar issue with DrO where when you'd rate a file currently playing that wasn't in the ML, simply rating it then added it to the ML.

my recollection is that he said nothing really could be done about it, b/c the behind the scenes mechanics of it made it too difficult to change the behavior of.

[DJ Egg]

It was a last minute addition.
Let's bear in mind that in 5.65 and earlier, it was a media library feature only.
So files had to already be in the library before you could use the mass editor.

[Juanus]

does it matter if the file is currently playing or not?

I have never tried it with the track playing. I have always had a different track playing while trying to edit this track.

It was a last minute addition.
Let's bear in mind that in 5.65 and earlier, it was a media library feature only.
So files had to already be in the library before you could use the mass editor.

You are not going to hear any complaints from me. I love last minute additions. I just wanted to make sure I reported everything I saw before the end of days.

[Aminifu]

As to the 2nd issue, I also see that the 2nd illegal filename is not removed from the list of playlists after a command to delete until Winamp is restarted, but the filenames in the 2nd list are deleted before the restart. The filename of the playlist should have been removed, but at least the filenames in the list were. It is probably to late for this cosmetic error, imo, to be fixed.

Hi Dro Chilla,

Short Version:
Upon further examination this is not a cosmetic bug. On my system attempting to delete the last remaining 'illegal' playlist name appears to do nothing, but it really causes the playlist at the top of the library listing to be deleted. If I keep trying to delete the 'illegal' name, I'm actually deleting other playlists (from the top down)!

I have a long list of playlists and the top of the listing was not visible, so I didn't notice this until today. Luckily the deleted playlists were put in the Recycle Bin, so I was able to retrieve them without having to use my backup files.

Thank you for reporting this bug! I now know not to keep trying if I delete something with Winamp and it appears to not have been deleted.

More Info:
I've always made separate playlists and then imported them to the media library. This is why my playlist names do not have 'illegal' characters in them. Anyway, until the last few Winamp versions, importing only made media library copies of the source lists. So if I deleted the media library copy, I still had the source list. The recently added feature allows linking to the source lists instead of copying them. Since Winamp does not automatically keep the library copy in sync with the source, linking removes the need for making new copies when the source list is changed. The downside of linking is that deleting the list in the library also deletes the source.

A few weeks ago, I deleted all my media library playlist copies and re-imported my playlists using this linking feature. When testing for the bug you reported, I used the "Send to:" context menu command to create media library playlists (with 'illegal' characters in their names) from an active list in the playlist editor. These playlist copies where added to the library listing of my linked to playlists, so the playlists that were inadvertently deleted were my source lists.

Bottom line, I don't know it this bug you discovered is related to the new linking feature or not. With the noble attempt to add so many fixes and improvements to the last AOL supported Winamp version (and the relatively short time for testing), some unintended consequences have occurred. Going forward we need to careful and maintain current backups of anything that could otherwise be irretrievably lost.

[Aminifu]

For me it's only crashing when I click 'Update' without actually updating any of the tags. If I select a tag and change it, then click 'Update', it doesn't crash. Is that what everyone else is seeing?

Like ryerman, I can not reproduce a crash with this file (trying everything that's been mentioned). As was the case with MP3Val, MP3 Diags also does not report any errors in this file. I'm also using the same version of msvcr90.dll that Juanus reported.

Most strange, other than Juanus, 2 people can get Winamp to crash with this file and 2 can not.

[Juanus]

Like ryerman, I can not reproduce a crash with this file (trying everything that's been mentioned). As was the case with MP3Val, MP3 Diags also does not report any errors in this file. I'm also using the same version of msvcr90.dll that Juanus reported.

Most strange, other than Juanus, 2 people can get Winamp to crash with this file and 2 can not.

It is definitely a random type kind of crash. For me, with some files it happens, and with some it doesn't. (I just picked out one that I could narrow down) And when trying to recreate it, I started to get Pavlovian with it. I wasn't sure if it crashed updating certain fields or maybe the amount of files trying to be updated. I am just glad that other people were able to recreate it.

[DrO]

I get a crash on this file (and other files from this publisher) when I used the "Edit Metadata for Selection" feature in the Playlist.
I just added this file to the playlist > right click > Edit Metadata for Selection > Press the Update button and crash.

reproduced, is something to do with the genre handling it seems (from a quick look at a crash dump).
[edit]
checked a bit more and is due to there not being any genre and some quirks with just doing 'update' when there hasn't been any edits actually made.

I'm also finding that when you use 'Edit metadata for selection...' in the Playlist Editor for tracks that aren't already in the Media Library, it adds the tracks to the Media Library when you click 'Update'. Not sure if that's intended or not.

I see the same behaviour. I hope that is not intended.
Files in the Playlist Editor can be added to the Library using the Send To menu and my opinion is that files should not be added merely because their metadata is edited.

with the coding of things, it is intended as that's what happened with taking the library implementation and quickly porting it for the pledit. i had meant to add in the means to choose between the behaviour (which would have been an ini option due to the time of when the feature was added) that happened (which will add or update in the library) or allow for it only to update if already in the library along with both actions always trying to update the local file tag (if the option is enabled).

if the library isn't present then it'll work as is being talked about, but when the library is present, it's going to add as it also helps to match the rating behaviour which goes in the library. so not as nice as people would like but with the timings of things and with ensuring consistency with other behaviour, adding to the library is a necessity and fully expected.

[Juanus]

reproduced, is something to do with the genre handling it seems (from a quick look at a crash dump).
[edit]
checked a bit more and is due to there not being any genre and some quirks with just doing 'update' when there hasn't been any edits actually made.

So basically just add a genre and all is well. I did that and it seemed to work properly.
Problem solved.
THANKS DrO!

[MrSinatra]

that explains why I did not see it, as all my files have a genre tag. (love em!)

[Aminifu]

reproduced, is something to do with the genre handling it seems (from a quick look at a crash dump).
[edit]
checked a bit more and is due to there not being any genre and some quirks with just doing 'update' when there hasn't been any edits actually made.

So wondering why ryerman and I didn't have a crash, I just tried it again. I enqueued Juanus' file in the playlist editor, opened it in the Shift+E editor (with the option to update the file tags enabled), clicked Update without changing anything (unpopulated genre tag), and all it did was add the file's existing data to my library and updated the file (and it's modification date) without changing any of it's tags.

But when I tried again to update the file without changing anything, I did get the crash. So when the file was not in the library then no crash (creating the original database record and updating the file tags). After it was in the library then the crash (trying to update the record and the file tags).

Populating the genre tag allows things to work. I was even able to remove the genre tag data without a crash. But trying to update again without a populated genre tag (and no other edits) caused a crash.

Note: Disabling the option to update the file tags will prevent a crash, if you use the Update button to exit the editor containing the library record of a file without a genre tag (when there hasn't been any edits actually made).

Bottom line: When using the Update button in the Shift+E editor for a file already in the library and the option to update the file tags is enabled, then it must have a populated genre tag (when there hasn't been any edits actually made).

It is better to use the Cancel button in both the Shift+E and Alt+3 editors when there hasn't been any edits actually made. Using the OK button in the Alt+3 editor will also cause a file update (rewrite of the same tag data) and a change of the file's modification date, even if no edits have actually been made. Fortunately, the Alt+3 editor doesn't care if a particular tag is populated or not.

As Spock may say, it's fascinating that the Shift+E editor does care. Why couldn't it have been one of the tags that is usually populated. Then the bug may have gone unnoticed.

Note: When trying to update tags of a read-only file with the Alt+3 editor, Winamp will generate a notification that the file is protected. When using the Shift+E editor, Winamp will crash given the conditions discussed above, before it can generate this notification.

[Leehong47]

Hello,

We are a bug since i use Win8 64bit... (and on the last year of version)
in converting for my a mp3 SdCard for my Car, each title converted lag on 45% or 47% of conversion...
Winamp stay laggy 10-15 sec and become normal...

what's the problem ?

Many Thanks