Winamp slows to a crawl from file

[ChiggyChiggy]

For some reason when i play this file https://app.box.com/s/wehol8claffjp4d2s5sg Winamp's CPU usage jumps up the roof and i cant even move my mouse without it stuttering until i somehow manage to make it stop playing it

In every other player ive tried (AIMP, VLC, MPC-HC) it plays just dandy, but with Winamp however....

What could be possibly wrong here? I thought perhaps the file was corrupt so i cleared the mp3 file using foobar's stream rebuilder that clears out any corruptions, bur nada D:

[DrO]

assuming you're just playing the file as an mp3 and not inside of the rar file, it's most likely because you've got a 4650x4650 piece of album art embedded in the file and based on the skin you're using, Winamp will be doing multiple artwork lookups from the file and due to the shear size of it, it takes time and so it all adds up.

ironically this is something i've been working on reducing the number of lookups made so it caches things and comparing 5.666 build 3516 with the internal dev build, it's still slow, but it's far better than what is seen with the version that you can use.

there's not much to suggest other than to down-size / remove the artwork or you'll need to put up with the lag (which is more noticeable with Modern skins due to how they work).

[Sabine Klare]

I am just interested, which size-maximum do You suggest for an image-file, which is embedded or should be embedded in the MP3?

I have MP3s with embedded album art of 120x120 pixel. A SoundCloud Podcast Label has album art between 511x510 and 4033x4032 pixel. I was shocked a little bit, when I have discovered, that some album art is so large. But I love the embedded album art in the MP3s, especially in the downloaded SoundCloud Podcasts.

I myself think, 400x400 pixel should be the minimum (I save also the profile-picture as username.jpg and cover.jpg). Also I think, the album art should have not more than 2000x2000 pixel.

Can SoundCloud Podcasts with embedded large album art be played with Classic Skins better than with Bento and other Modern Skins? For the Classic Skins I have the gen_classicart.dll...

[DrO]

it all depends on your needs as to what size to go with and if you're sourcing it directly or relying on someone else / a service. though ~500x500 seems to be a good compromise for how the artwork is normally displayed vs any scaling which needs to be made. so is best to go with what you're happy with and what best suits your needs.

as for the second question, the file ChiggyChiggy provided causes both modern skins and classic skins with gen_classicart to have issues since they're both dependent upon the underlying artwork API which the Winamp core provides for plug-ins to use.

[ChiggyChiggy]

I guess the artwork is rather large and massive, under 1080x1080 it is then!

Winamp also goes to a crawl when theres a file that its trying to play but it doesnt exist, itll make everything so slow and give the same scenario like with this file, is there a way to make Winamp say the file doesnt exist instead of making it presumably constantly try and play said nonexistant file?

Wait, the issue was from the Album art viewer for classic skins plugin you mean? I font have that plugin anymore but i still get it...

[DrO]

file lookups are based on the OS and in some cases that can be slow which can cause the Winamp UI (dependent upon the skin) to either lockup or act slow as you're describing.

as for your last comment, if that plug-in is present, then it can cause a slow down since it's causing Winamp to do artwork lookups which if it's a massive image, will be slow.

if anything, i think there's probably something wrong in general with your install or it's just normal if you've got 1000x1000+ images in the files and is probably time you provide an info report of your Winamp install (see http://forums.winamp.com/showthread....161361#plugins and attach the report to this thread).

[ChiggyChiggy]

If its using the OS's search function, why does searching for a file in explorer not make it lockup my system the same way Winamp does then? D: I dont have anything out of the usual with Winamp really, and a small amount of plugins in total...

Anyway I attached the report in the attachement.

[DrO]

comparing Winamp to Explorer is like comparing a banana with a haddock - they're completely different beasts.

from the info report, you've got a number of 3rd party plug-ins present (listed below) as well as you're using a cPro based skin which itself might be the cause of the issue since that will attempt to load artwork into a number of places in it's layout iirc which then exactly matches the slow down behaviour on artwork lookup as well as what could happen if a file is missing (as i don't know how it handles lookup failures):

in_vgm.dll - (unlikely to be a cause of issues)
gen_bpembededart.dll + bpembededart.w5s - (unlikely to be a cause of issues)
ClassicPro.w5s - (the cPro engine which may not be the cause as described above)
gen_nopro.dll - (won't have any effect)
gen_saveas.dll - (won't have any effect)
gen_skinmanager.dll - (won't have any effect)
gen_timerestore.dll - (only time it can cause UI issues is if the write settings option interval is too low)
gen_undo.dll - (should only affect things if the playlist physically changes)
gen_win7shell.dll - (depends on how it has been configured as to how much it might be affecting responsiveness)
ml_umlp.dll - (i have no idea what this could be doing or what effect on things it could have)

so i'd probably start by disabling gen_win7shell.dll and ml_umlp.dll and if that doesn't help, try with a non-cPro skin e.g. one of the Bento skins and see if that helps.

[ChiggyChiggy]

I never did remember to come back to this thread.. crap... thanks @Aminifu for reminding me lol.


In the end the cause was the rather large cover art that it had (which was the only one i found at the time for it) Getting a smaller covert art fixed it. Winamp doesnt handle album art thats over 1000x1000 very well, not well at all infact >.>

[DrO]

the current release doesn't and there's already been changes made but when you start using very large artwork, not matter what will start to see a slow down in things as it can be a lot of data to process (especially with the 5000x5000 images that some people use).

[Aminifu]

5000x5000 sounds excessive, even for display on a big screen tv. But as ChiggyChiggy says, it's easy to find stuff that is either too small or too big. It takes a bit of digging to locate 500x500 or 600x600 images of the things you want. The huge images can be resized, but that's just one more thing that eats into limited time. Oh well, such is life.

[DrO]

well it's often the resizing down to what's needed for display where the time is being taken. though it wasn't helped that Winamp in a number of cases was pulling the image from the tag a couple of times and re-processing on every instance which for very large images is noticeable.

so the internal builds now instead will cache the request from the file / lookup service and provide that for subsequent requests until a different file is asked for. since some of the requests are for different information, so it's possible now that the initial lookup is slower as all of the origin stuff and a few other things will be calculated, but more time is saved in the following requests made as we're not re-doing all of it over and over again (so slower one time to be faster for multiple times afterwards).

[Victhor]

Speaking of image's size, I use this handy tool to do a quick resize on the fly, handles quite well all resolutions: Image resizer (free, small and integrated in Window's right click menu so I don't need to open another prog separately) .

(by the way, my preferred size is between 750 -if done manually- and 900px -specially if it's a good cover-)

[ChiggyChiggy]

Ah, so the next Winamp will have an artwork lookup provider then? This is news
How come large artwork causes Winamp to have that issue in the first place though? Ive never seen another player have that behaviour o.O
And is it exclusive to only the main displayed image? For example sometimes a file can have several cover arts (Front cover, back cover, booklet images, etc..) If the rest are rather large but the main front one is tiny, would it still more or less have the same issue?

And thx for that resizer, previously id use paint to reduce the pic's size... but that ends horribly cuz the pic looks mushed up u_u

[DrO]

it was mentioned a good 2 months back that we're looking to provide some sort of lookup service integration.

it's most likely because we're generally doing the artwork lookups synchronously instead of asynchronously (though there were a few parts that attempted to do it asynchronously). i've still to find time to do more work on things, but some of the slowness is just how we've implemented things as-is and some is down to what needs to be done to get an image decoded and put into use for whatever case it's being used (which for large images just doesn't seem to work well but that more stems from large artwork not being the norm when the whole feature was implemented).

so i've done the most obvious things possible in doing a load once & return cached data, but there is likely to be other cases where things could be optimised (since it's mainly modern skins this affects anyway) but that'll more likely be for something further down the road as time allows.