-Brading Software Message Board
+--Forum: Mp3/Tag Studio Support and Bug Reports
+---Topic: out of memory started by Johnny Danger
Posted by: Johnny Danger on July 30 2003,09:38
Hail to this great program.
here's the problem: every time I mass remove/rename tags, I get an out of memory error at the 3% progress mark. If I do these operations on a few files, it works fine.
what gives?
Posted by: Magnus Brading on July 30 2003,12:17
There is most likely a file with a corrupted ID3v2 tag in your collection that's causing this. I would try to isolate which file it is, extract it from the collection, and then try again.
Posted by: PREMIERDJ on July 31 2003,05:08
MAGNUS!!! DUDE WHATSUP, Previous Versions NEVER!!!!!! Crashed like this, i'm getting the same error, on MULTIPLE TAGS, combined with an i/o Error, for a while you had me thinking it was my harware
Posted by: Johnny Danger on July 31 2003,06:24
Right. Magnus the problem only appears when I execute for real (when I preview everything works fine). I removed the songs which could have caused the problem, but the program still crashes at 3%. I also used the filter and tried filtering songs with/without tags; still, 3% is all she wrote.
By the way, I quite like the disco effect; you should think about keeping it and embellishing it instead of fixing it, since it's not really a problem.
Posted by: Magnus Brading on July 31 2003,14:38
Johnny, since this is not a commonly known problem, and since I don't really see a way for a bug to be able to cause an error at a certain percentage into the processing, I would still guess that it has something to do with the tags, or possibly other properties, of the files you process.
Could you please try the following:
1.
Divide the mp3 files into two or more separate folders.
2.
Try to process all these folders separately. Does the error still occur for all of the folders? For the ones that gets the error, try to divide them up the same way again, until you have been able to isolate small groups of files that cause the problem.
3.
Also try to move the files to other directories (preferably with short simple names, like e.g. "c:\test"), and see if the problem still occurs when you process them from there.
Let us know about the results.
Posted by: Johnny Danger on Aug. 02 2003,06:51
Salute. Magnus I have done what you counseled and came to the conclusion that the problem lies with the software. Here's the lowdown: divided about 200 mp3's into 5 folders named a-e. I had problems removing tags in two of them. Folder d game me a weird error in frame size calculation AND an access violation. Don't know what the problem here is, but what is most interesting is with folder a. You were right about the 3% being irrelevant BUT the out of memory problem is real and this is the way it develops: out of memory at song 25 (for example's sake). I remove song, close and restart tag studio, restart removal of tags and now the program crashes at song 19. I then remove this song, and proceed in the same way. Program crashes at song 15, And so forth, with the program crashing earlier and earlier until finally it crashes with NO SONGS in the directory, i.e. it announces being out of memory without having treated a single file. This having been done, I proceeded to erase all the temporary folders that had been created for the test. Abracadabra, folder a will not delete. The folder is empty, tag studio is closed, and still windows (XP) states the folder is being used by a program.
Obviously something queer is up (no pun intended).
Posted by: Magnus Brading on Aug. 02 2003,13:19
The problem is that the status messages about which song is being processed comes up first after a song has been processed, and if a corrupted tag makes the program crash during processing of a song, you will not know which song it was, because the song last mentioned in the status list will be the song processed before that file. The same may be the case when you say it crashes before any song has been processed, it might just be that the first song is the faulty one.
But if you claim that the program crashes when processing a single completely empty directory, please tell us the full name (path) of this directory, and we'll see if anyone can reproduce it.
About the locking of the directory, such a thing has been reported before and concluded to be caused by third-party software like e.g. shell extensions and such. There is no way that a program can lock a folder after its process is terminated.
end