Old 8th February 2012, 21:35   #81
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 3,201
Hi DrO,

If you read this when you get back, I hope you enjoyed your break. I don't expect you to get deeply involved in this issue. You already do enough on your own dime. I'm hoping someone who knows the code or knows a work-around would respond.

For rebuilding a library or doing a Gracenote scan of a large collection (several thousands), the work-around is to monitor memory usage and stop and restart WA (and the scan) as needed. For scrolling through a lot of art, there is no work-around, the user must have enough available RAM to support the memory needed to avoid a crash. Using a file storage scheme that requires less art and/or using small size art only increases the time before available RAM becomes inadequate to support the app.

In my case, I use a classic skin and plug-in that displays only the image for the selected track when I start WA. Memory usage (around 37 MB) is small and consistent with the other plug-ins I use. It stays around 40 MB if I never open a panel that displays multiple art images. When I open my library panel that displays multiple art images, my art cache file (art_120.dat 225 MB) is loaded and memory usage rises to around 290 MB, consistent with the size of my cache.

If I scroll through all of my album art (only 6,186 files and a few hundred images), there is very little or no delay in displaying the images and memory rises to around 544 MB. This leads me to assume that all my art is not cached and direct reading and rendering is fast on my system (4 core CPU 3 GHz, 460GTX GPU, & 4 GB RAM). If I then close the library panel memory usage drops to around 300 MB, consistent with the art cache remaining in memory and the extra memory for the art not in the cache being released.

I can understand reasons for keeping the art cache in memory for several minutes, but after more than a half hour, with the library panel still closed, the art cache is still not released. After more than a hour, memory usage is still around 300 MB. This leads me to assume that once the art cache is loaded, it is never released.

For me this is not yet a problem. However, for those with large collections who use skins (or keep panels open) that display multiple art images, allowing memory usage related to album art to rise unchecked could be a problem. If this is by design, the WA system requirements for RAM (256 MB minimum - 500 MB or more recommended) need to be changed. Maybe 500 MB minimum and 1 GB or more recommended.

Win 7 Home Premium 64-bit SP1 desktop, Winamp Pro 5.666.3516, cPro MPxi_remix skin, 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 8th February 2012, 21:47   #82
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 4,727
Send a message via AIM to MrSinatra
i haven't done any testing, but there also does seem to be a difference between those who embed art, and those who don't. this is curious, b/c in either case there should be only one art per album, but i suspect that under the hood, its not playing out like that; it seems like you're far more likely to crash if you embed, which i think might be due to embeds exponentially exacerbating the underlying mechanics of the issue.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is online now   Reply With Quote
Old 8th February 2012, 22:02   #83
Batter Pudding
Major Dude
 
Batter Pudding's Avatar
 
Join Date: Jun 2008
Posts: 1,665
The odd part is, as Dr O points out, it is pretty hard to "run out of memory" on a PC due to the way the swap file works. You would see Virtual Memory warnings first, and then windows would automatically start expanding the size of the swap file. And usually keep going until your disk gets full or it hits a set limit.

A crash like this is more likely bad memory pointers or failing to release memory as suggested by Aminfu. Using "too much" memory does not crash a PC, it just slows it down a lot. Using the "wrong" memory is where your crashes appear.

MrSinatra's point about the embedded art makes sense. This could explain why I have never seen a problem as I don't have much embedded. It could be different handling just working in a different way. Also remember that embedded art will mean an image per track, whereas normal art is an image per album. That is potentially a huge difference.

And who let Dr O out? I thought he was permanently chained into the support cupboard? Someone needs to check the quality of the restraints. Just don't get the same quality control on handcuffs in this modern day. He must of chewed through them when no one was looking...
Batter Pudding is offline   Reply With Quote
Old 8th February 2012, 22:56   #84
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 3,201
Quote:
Originally Posted by MrSinatra View Post
... this is curious, b/c in either case there should be only one art per album, but i suspect that under the hood, its not playing out like that; it seems like you're far more likely to crash if you embed, which i think might be due to embeds exponentially exacerbating the underlying mechanics of the issue.
If the art embedded in each track per album is exactly the same, then yes you get one art image per album. Otherwise not, which is easy when adding individual tracks from the same album over time. Also, there's the behavior you noted awhile ago, namely the process WA uses to select an aggregate image for the album's tracks seems to vary.

Even so, I think it's the number of images, rather that reading them from the tags, that eventually uses up the available physical RAM and the virtual memory is somehow blocked.

Win 7 Home Premium 64-bit SP1 desktop, Winamp Pro 5.666.3516, cPro MPxi_remix skin, 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 8th February 2012, 23:15   #85
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 3,201
Quote:
Originally Posted by Batter Pudding View Post
The odd part is, as Dr O points out, it is pretty hard to "run out of memory" on a PC due to the way the swap file works. You would see Virtual Memory warnings first, and then windows would automatically start expanding the size of the swap file. And usually keep going until your disk gets full or it hits a set limit.
True for a default setup. But you also have those who set their swap files to a set size or remove it all together because they think they have so much RAM that one is not needed.

Remember the OP's video. Do not remember if his system's virtual memory setup was stated, but there were no virtual memory warnings displayed.

Win 7 Home Premium 64-bit SP1 desktop, Winamp Pro 5.666.3516, cPro MPxi_remix skin, 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 4th March 2012, 14:59   #86
damenace
Member
 
Join Date: Aug 2003
Posts: 53
friendly reminder: please fix :-(
damenace is offline   Reply With Quote
Old 22nd March 2012, 16:52   #87
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
well i cannot make anything like is shown in the video happen.

as for the points about the artwork cache being held in memory, i don't think it is even intentionally done though yes when looking at things like the working set it will drop down but won't drop all of the way but that's not necessarily because of things not being released and could be coming from what the OS thinks is still needed so it essentially keeps that reserved.

as for the friendly reminder: please fix :-( comment, it's nigh on impossible to fix something which cannot be replicated. yes that sounds like a crap excuse but there is so much code in Winamp, not being able to replicate it makes it massively tricky to even know where to start looking. if there was a way to consistently reproduce it on a developer machine then it could be more easily fixed but i'm not able to (and only looked again at this whilst waiting for something else to finish) and i doubt anyone else is going to be able to (especially when this only seems to affect a minority - based on your video and not the other threads of stuff in this thread).

[edit]
how deep do the folders go? just wondering if it might be related to how many levels of recursion are needed and how much stack space is needed to keep a track of things (though it's probably going down the wrong line of ideas).

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 17:14   #88
damenace
Member
 
Join Date: Aug 2003
Posts: 53
the problem should be easy to replicate.
if anyone needs any info on how to, just ask me. pm me. whatever.

it's really not that hard. if you have a big enough library and it it properly tagged then most images will be 500x500 or larger and 40-100kb in size. that should suffice.
if not, as i said, contact me. happy to help fix this problem.

if you want me to run some kind of debug more or anything...eager to help


folders are "U:\-= mp3 =-\-= Soft =-\Artist\Album\"
damenace is offline   Reply With Quote
Old 22nd March 2012, 17:31   #89
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
the information to replicate it should be clearly stated in this thread in one place instead of being all over the shop - it took me a few minutes to find the video, let alone to find the plug-ins list.

if i was going to properly look into this (which i don't have to do irrespective of having code access), with how things have been laid out / provided, i'd really not want to since there is no specific method laid out - just saying 2000 albums and artwork and a few other things isn't anywhere reliable to work against.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 19:40   #90
damenace
Member
 
Join Date: Aug 2003
Posts: 53
well, i was hoping that devs might actually be following the thread while it was still active.

and as i said, i am happy to give any information needed.
and as i cannot edit any of my posts anymore, i cannot sum it all up in the first post.

if some one is willing to take a look at it i would be happy to sum it all up in one post including the video.
damenace is offline   Reply With Quote
Old 22nd March 2012, 19:51   #91
damenace
Member
 
Join Date: Aug 2003
Posts: 53
Winamp 5.621 (build 3173) AND also tried current version
Clean install, no 3rd-party skins or plugins
Also happened in 5.62


OS: Windows 7 Ultimate (64-bit)
Locale: English US
CPU: core duo@2.1 GHz
Memory: 3GB RAM
DirectX 11

Problem:
Winamp crashes due to RAM overconsumption when adding huge library with big or a lot of coverart

Method of Reproduction:
- Select a folder with more than 2000albums as a Watched Folder
- All mp3s need to be properly tagged including coverart in EACH mp3 (not one per folder, but coverart in every single file)
- ideally the coverart should be min. 500x500 and 40kb or bigger
- Scan (foreground or background does not matter)
- RAM will fill up and then at around 1500MB RAM Winamp will crash
- RAM is not freed during the update progress nor after
- the surge in memory usage only happens when freshly adding new files to the media library. not upon re-scan (which only confirms the files still being present)

please see video for further information

video:
http://imageshack.us/clip/my-videos/841/poo.mp4

the folder structure is
U:\-= mp3 =-\-= Soft =-\Artist\Album\

working theory:
there seems to be a memory leak somewhere when reading the coverart.

workaround:
scan until RAM consumption reaches almost critical level and then abort and close winamp. all information will be stored in the database.
however, this is no solution. why? because most albums are on an external drive. if i disconnect it and open winamp, all media information is deleted as the drive is no longer present and upon opening winamp, all folders are checked.
so next time i hook up the drive, files will be scanned, winamp will crash...etc

Last edited by damenace; 22nd March 2012 at 21:01.
damenace is offline   Reply With Quote
Old 22nd March 2012, 20:42   #92
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
when the re-scan happens or when files are added to the library, there is no loading of the artwork from the files happening. that is the first thing i've just confirmed so am putting that to bed.

artwork look up (either from the files of the cache which is built) happens only when a view is opened which shows the artwork.

i've briefly tried to see what happens if i force Winamp to save the scan after 1000 and then 5000 results and it showed the memory being used then freed then reloaded but it slows the scan down and also causes other issues when still trying to use aspects of the library at the same time. so that's not really a viable option to keep going down.


with the code i'm looking at, nothing obvious jumps out as all of the memory allocation i can see does have a matching freeing done. so what is the actual memory column you are showing as it's not visible in the video?

however whatever is going on for you, the crash happens because Winamp is hitting the limit of what can be properly accessed by a 32-bit program (as Winamp is).

i did find what i think is a possible cause of some issues people see on re-scans where it was trying to clean up something which had already been removed, but i don't think that has any bearing on your issue.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 20:56   #93
damenace
Member
 
Join Date: Aug 2003
Posts: 53
it doesn't happen on re-scans.
only if files are added freshly.

if all the files are availble in the library and winamp just does a re-scan to confirm the files are still there, no crashes occur.

it is only when freshly adding those files.
and i think coverart is being scanned when you freshly add new media. because even if the files are not present anymore, the coverart is stored in the library. so it has to be scanned and added. coverart is not being red from the files on access but rather from the library after the scan.

and the memory is not being freed once the scanning is stopped. if i stop it at 1400MB it will remain at 1400MB until i close winamp.
what do you mean you cannot see what my memory is doing in the video? if you can give me further instructions i can make another video with other info
damenace is offline   Reply With Quote
Old 22nd March 2012, 21:06   #94
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
coverart is not being scanned as part of the adding to the library - i clearly stated that and i would not have said that unless i'd first spent the last 30 minutes checking that is the case.

coverart is loaded when the view is loaded and is either then read from the file's tag, or the associated artwork files or from the cache. it is not loaded when the files are added to the library either manually or as part of the scan process.

your problem is somewhere in the handling of the database being generated and has nothing to do with coverart which goes into a completely separate set of database files from what is being used as part of the scan process.


i asked what is the title of the column which shows the memory usage. as there are at least 3 different types of memory information which can be displayed.

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 21:15   #95
damenace
Member
 
Join Date: Aug 2003
Posts: 53
ah, i understand.

ok, the column is called "Arbeitsspeicher (privater Arbeitssatz)" which apparently translates to "Memory - Private Working Set" according to Microsoft.

Quote:
Subset of working set that specifically describes the amount of memory a process is using that can't be shared by other processes.
damenace is offline   Reply With Quote
Old 22nd March 2012, 21:31   #96
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
ok, so we're at least looking at the same column which is better than i thought was the case.

i've had a quick look through the artwork cache used for the views and nothing is coming out as not freeing memory which is explicitly allocated. though obviously it could be coming from the loading of things related to the caches, but that really doesn't explain the allocation you get.


how many files do you actually end up adding into the library? also it might be useful to provide a copy of your main.dat and main.idx as it might make it easier to work out how much data is being pulled from the files. you can either email (from my site) or pm me a link or you can post it publically if wanted.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 21:36   #97
damenace
Member
 
Join Date: Aug 2003
Posts: 53
i will need to re-scan tomorrow. i'll send you the files needed

is there some kind of debug mode i can run that will show you what is being written to RAM? so you can see what is taking up the space (given that you were able to rule out artwork).
damenace is offline   Reply With Quote
Old 22nd March 2012, 21:42   #98
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
there's nothing in place for really determining what is or isn't going on. which is why i'm hoping by looking at what is eventually created and stored (as i assume you've be doing in a batch) will give some sort of hint on where in the source code i should be looking at.

though i'd be much happier knowing this is done on 5.623 rather than the 5.621 you said you're using (since i know i'm working with 5.623 source code).

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 21:52   #99
damenace
Member
 
Join Date: Aug 2003
Posts: 53
i am using the 5.623
the thread was created and the problem first reported back when 5.621 was current.

will do the scanning tomorrow...in a dozen runs or so...and post or email the files
damenace is offline   Reply With Quote
Old 22nd March 2012, 21:57   #100
Batter Pudding
Major Dude
 
Batter Pudding's Avatar
 
Join Date: Jun 2008
Posts: 1,665
DrO - The artwork was being pointed at as a possible culprit because of work we did in the first page of this thread (especially #20 to #40). I do believe it is worth reading the second half of the first page (before the thread went OT) as we did some testing in there.

It was in there that we noticed a difference between a collection of music I scanned on a clean virgin PC with no embedded artwork and Damenace's collection with quality embedded artwork in every file (Artwork sizes of 40-100kb and some are 300-900kb per track)

Specifically I noticed (post #38) that when watching the video it could be seen each album caused a jump of multiple megabytes in the memory allocation. I don't embed artwork, so my test laptop did not show any jump. A back-of-fag-packet calculation came up with ten tracks with 600KB images in them adding up to 6MB per album on demenance's scans. This seemed to fit the video.

So it was my fault for the "blame the embedded quality artwork" comments. The maths seemed to fit. Could it be that as the MP3 TAG fields are loaded up into memory it is also picking up the data that would be the artwork? I don't mean specifically loading the "art" to store, but reading in the data because it is a TAG field?
Batter Pudding is offline   Reply With Quote
Old 22nd March 2012, 22:19   #101
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
maybe something is loading it in the input plug-in but i'm not sure on that side of things until looking into it.

all i've done so far is going through and trying to track through what is going on when the scan/re-scan happens and what it then tries to call. it was from that that i confirmed the artwork isn't directly loaded at that point in time.


i've just quickly tried against in_mp3 and there's no calling of the artwork pulling api during the scan and from a look at the id3 reading i'm not seeing anything obvious. this would be so much easier for someone who actually knows the code or can reproduce it since i do see an increase in the working set but it then comes back to around where it was when things started, which is what i would be expecting to see.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 22nd March 2012, 22:35   #102
Batter Pudding
Major Dude
 
Batter Pudding's Avatar
 
Join Date: Jun 2008
Posts: 1,665
What I was suggesting is the in_mp3 code could be loading all the MP3 TAGs before working out what they actually are. So this would not trigger any calls to the image library. It would just cause something to allocate some memory for the data being read from the .mp3 file.

You may need to use something like mp3tag to insert some huge 1MB JPGs into every mp3 file of an example album to see the memory changes. Personally I'd be tempted to make an example album with stupidly big MP3 tags for testing using 5MB images. But then I always did like evil test cases when coding.
Batter Pudding is offline   Reply With Quote
Old 23rd March 2012, 06:49   #103
damenace
Member
 
Join Date: Aug 2003
Posts: 53
i must say, i am really surprised nobody else has this problem.

i cleared my library and then told it to re-scan hence adding all my local mp3s again.
and even just my collection stored in my notebook, a mere fraction of my acutal collection used up 1732MB of memory during the scan process.

almost enough to kill winamp, but not quite

it consists of just 8004 files in 749 folders totalling 65.8GB

i waited for over a minute and it remained above 1730MB of used RAM.

just to rule it out, you guys are using win 7 64 bit or 32bit? or not even win 7?

p.s.: @DrO: I sent both files, main.dat and main.idx, to your email adress
damenace is offline   Reply With Quote
Old 23rd March 2012, 08:55   #104
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
just quickly loaded up the files and in the simple view it's giving me 7696 entries (which matches my csv dump of it). on loading the view i went from 44Mb to 51Mb and on leaving the view it then goes back to 50Mb which is about what i'd expect since the raw db is a ~5Mb file.

the csv dump so far doesn't show up anything which would seem like an obvious cause though have noticed there are also flac and m4a files in there as well. one thing to try is just adding one file type at a time and see if that makes any difference - it may also help to confirm if it's just a single format issue or is something more general in your case.

i'm on Win7 64-bit though i'm also not seeing it on my XP 32-bit install.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 23rd March 2012, 09:11   #105
damenace
Member
 
Join Date: Aug 2003
Posts: 53
well, most of my files are mp3 and as the increase in memory is constant, it should not be due to the flac or m4a files.
the increase in memory usage, as i said, is only when freshly adding files. not when loading winamp or re-scaning to make sure the files are still available.

only upon adding previously non-existant files.
damenace is offline   Reply With Quote
Old 23rd March 2012, 09:17   #106
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
i know that it only happens when the files are freshly added, but i need to discount the other input plug-ins since otherwise if i'm going to try to keep looking into this, i then need to look at 3 times as much code and as i'm doing this off my own back and tripling the work load on my side when i shouldn't be doing it doesn't make things that attactive for me to look further.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 23rd March 2012, 09:27   #107
damenace
Member
 
Join Date: Aug 2003
Posts: 53
i understand

so, i removed the non-mp3s and re-added. same increase in memory usage

p.s.: would you like me to remove some of the plugins? if you can tell me which files to remove from which folder, I can give it a shot.
damenace is offline   Reply With Quote
Old 23rd March 2012, 09:52   #108
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
ok, what tags do you have on the files i.e. ID3v1, ID3v2.3, ID3v2.4, APEv2, Lyrics3 etc. as the volume increase makes me wonder if it's more tag type specific (as i saw something in the ID3v2.4 handling which is nagging at me but that might not be relevant anyway).

there's no need to remove plug-ins just yet though i'm not sure there is too much else which would even be interacting with things. since it's really just winamp.exe, in_mp3.dll, gen_ml.dll, ml_local.dll and some of the *.w5s components in the system folder which are used during the whole process.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 23rd March 2012, 10:06   #109
damenace
Member
 
Join Date: Aug 2003
Posts: 53
i emailed you two example mp3s. should be with you in a few minutes

i use mp3tag to tag artist, title, track, year, genre, coverart etc.
usually whatever info is on amazon, musicbrainz etc.

i also added replaygain to all my files using foobar. replaygain per track of course, so stored in each single file.
damenace is offline   Reply With Quote
Old 23rd March 2012, 10:30   #110
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
got the files and i think that makes things a bit clearer.

i've added them to my playlist and then in conjunction with http://nunzioweb.com/daz/gen_classicart/index.html, having it set to show information about the selected song, by moving between one of the files and one of my own files and doing that a few times, the memory increases when the selection ends up on the starting file.

however, when i do the same with my own files only, the memory will change but it comes back to the same memory amount as was there on the starting file.


now as you've got ID3v1, ID3v2.3 and APEv2 tags, i thought i'd disable APEv2 support and then repeated the same process and it now acts like my own files do with your ones in there.

so can you go to preferences -> plug-ins -> input -> nullsoft mpeg audio decoder v4.98 -> 'APEv2 and Lyrics3' tab -> uncheck 'Read APEv2 tags' and then see if that makes any difference with the memory on adding to the library.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 23rd March 2012, 10:46   #111
damenace
Member
 
Join Date: Aug 2003
Posts: 53
i unchecked it.
when i add the files memory still increases rapidly. but this time "only" to 934MB

but the memory is not freed afterwards and i would expect it to exceed the maximum if i were to scan my entire database.

so it seems that maybe that plugin is the culprit. however, seems something is still flooding the memory and is not releasing it afterwards or during the process.


should all boxes in the ID3 tag register be checked? mine all are.
damenace is offline   Reply With Quote
Old 23rd March 2012, 10:57   #112
damenace
Member
 
Join Date: Aug 2003
Posts: 53
update:
i deactivated apev2, lyrics AND both id3

but still the memory increases to 900+ MB

might it have less to do with the read and more with the write process?
damenace is offline   Reply With Quote
Old 23rd March 2012, 10:59   #113
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
right, well that's a start and now gives me something to work from - had a horrible feeling it was going to be related to in_mp3.dll in some form.

from what i can see in the code, when the tags are read everything is in place to free the memory afterwards, though maybe something specific is causing that not to be triggered (maybe the order things is called is somehow different though i'd have expected the code to catch those scenarios as well).

all options ticked on the ID3 tab is the default handling.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 23rd March 2012, 11:01   #114
damenace
Member
 
Join Date: Aug 2003
Posts: 53
added last post. unticked all id3 as well. same behaviour as after unchecking apev2.
apev2 seems to increase memory usage even more, but the underlying issue remains even without apev2, lyrics or id3
damenace is offline   Reply With Quote
Old 23rd March 2012, 11:25   #115
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
with the number of files you have and the data which is added to the database, 900Mb+ would not relate to the database write process which happens at the end of the whole process and there's no reason for it to be allocating that much code.

so based on un-checking APEv2 reading, it's pretty much got to be the tag read handling. however until i actual start debugging things properly, i cannot say for certain what is / isn't going on. but i've now spent too much time on this today instead of actually doing the work i'm meant to be doing.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 23rd March 2012, 15:50   #116
damenace
Member
 
Join Date: Aug 2003
Posts: 53
I'll run a few extra tests myself. maybe one or two will be of interest. maybe they'll be a waste of time. who knows. but I need to copy 50gb of mp3s first as a test-library. so will take a while until i'm done.

thanks for your work so for. maybe you'll find the problem :-)
damenace is offline   Reply With Quote
Old 24th March 2012, 09:00   #117
damenace
Member
 
Join Date: Aug 2003
Posts: 53
hmmm. no luck. thought trying the different tags would show me something. but guess not.

let me know if there is anything i can do, test, alter for you
damenace is offline   Reply With Quote
Old 23rd April 2012, 12:01   #118
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 3,201
Hi damenace,

So far DrO thinks that your issue may be related to WA tag read handling. Have you tested your mp3s for structural tag errors (to rule that out as a possible contributing factor)? You did not answer this question earlier. If not, please run them through 'MP3Val' and/or 'MP3Diags'. Both are free utilities that can identify and correct many various structural errors that may be in your mp3s. MP3Val is much easier to use and probably safer. MP3Diags is more comprehensive. No app is perfect, so make a backup before letting either app 'correct' a mp3 (or use your test collection, if you still have it).

http://mp3val.sourceforge.net/

http://mp3diags.sourceforge.net/

Like you, I'm very much interested in a resolution to this problem, if possible. I know you said you are careful with tagging, but it can't hurt to check them. I found that many of my mp3s had errors (extra junk) that showed no visual or audio symptoms.

At the least, removing any 'extra junk' will allow for faster scans of huge collections.

Win 7 Home Premium 64-bit SP1 desktop, Winamp Pro 5.666.3516, cPro MPxi_remix skin, 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 23rd April 2012, 12:10   #119
DrO
Winamp Team
 
DrO's Avatar
 
Join Date: Sep 2003
Posts: 26,018
i really don't think it's anything to do with the structure of the files themselves but is something with the tag handling and is not something i've since had any further time to look into as with what i was seeing, a complete disable of all tag reading alleviated it but it's never doing the massive increase being seen by others and doesn't make sense when all of the code paths that i had looked at are correctly freeing the memory which is being allocated. either way something likely isn't right but time and my actual job means i've not been able to do anything further.

-daz

If you have issues with Winamp or still want to get it, ensure
you get v5.666 build 3516 and the required plug-in updates
DrO is offline   Reply With Quote
Old 25th April 2012, 06:50   #120
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 4,727
Send a message via AIM to MrSinatra
i think we should be careful in our terms. to me, "tags" are what an app like mp3tag shows you, (and some tags can be "bad" or corrupted) while "headers" are what apps like mp3val are meant to address, mostly fixing audio issues.

i agree that art itself is not scanned in at scan time, and is only accessed "on demand" ie. while playing or scrolling or viewing in ML. however, if art is in the tag, ie. embedded, it does seem to make this problem worse. since art can be in an ape tag, or a id3 tag, etc... perhaps its worse yet in one or the other, depending on how winamp reads such tags, and then manipulates the data.

also, it wouldn't surprise me if two different yet seemingly similar problems are at work here:

1. seems to be the fresh scanning in problem, while the other
2. seems to be the accessing/browsing of art problem, where the more you have, the bigger it is, if you embed, etc all seem to be part of it.

in my usage, i have mostly flacs and mp3s, about 415 gigs worth, and i do not embed, and i delete all extra tag types except id3v2.3 for mp3s, and my art rarely is larger than 500x500, with most being 200x200, and so i think i suffer the problem less seriously than others.

nevertheless, the more i scroll and browse artwork, the more my ram usage rises, and it doesn't seem to ever get released.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is online now   Reply With Quote
Reply
Go Back   Winamp Forums > Winamp > Winamp Bug Reports

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump