-Brading Software Message Board
+--Forum: Mp3/Tag Studio Support and Bug Reports
+---Topic: Death during custom list creation started by calberga
Posted by: calberga on Nov. 12 2006,15:45
I was trying to get a complete list of my mp3 files (to import into a database program). I know there are a lot of them, about 300 G.
After writing 18856 lines (1766528 bytes) the process stops with the error message:
Mp3/Tag Studio 3.5(beta 17)
Access violation at address 004b8795 in module 'mp3tag_s.exe'. Read of address 000032F8
I am running XP Pro, and the mp3 files (and resulting list) are on an external USB harddrive.
Posted by: Magnus Brading on Nov. 13 2006,00:05
Thanks for the report. It might be a corrupted ID3v2 tag in one of the files. In that case, try to isolate the file and fix its tag, and then proceed.
Posted by: calberga on Nov. 13 2006,01:22
Actually, it is a bad file name! I had renamed the files from the title tags, and two of the titles in this directory were VERY long! The files seem to have lost the right end, including the .mp3, and don't seem to be renameable! Mp3/Tag Studio dies (the same error message) if I try to examine them, and worse than that, Windows explorer also refuses to rename them! The files can't be copied and pasted, either.
Well, not quite as bad as I thought. It seems that I can copy the directory up to the top level of the directory tree, and then the names work, as does Mp3/Tag Studio. So it is the sum of the containing directory names, plus the file name which is exceeding some limit or other. For what it is worth, it is a NTFS disk.
I guess I'll have to rename the two files.
Should this throw an error, though? Once I "raised" the dirctory (picked if off the tree?) the tags are just fine.
Cyril
Posted by: calberga on Nov. 13 2006,02:43
The plot thickens -- After fixing the file names the Custom list operation still dies, in the same spot. Perhaps the length of the title tag is causing an overflow?
A side note, which I should have added to the previous post, is that the last line written to the list is for the file before the one with the long tag/filename (just tag, now). And that line is cut off in the middle of it's title field.
This is all very odd, as the Custom list operation worked on the directory (with the shortened file names) when it was in the root directory of the disk, but failed again when it was moved back to its proper place. The list only has file names, no directorys.
So, I don't understand why it should work in one place, but not in another.
Cyril
Posted by: Magnus Brading on Nov. 13 2006,14:21
I have seen at some occasions before that the operation system acts crazy in some cases with very long paths and filenames. As you say, Windows Explorer has problems with the file too. It should not be any overflow though, all string handling is dynamic in Mp3/Tag Studio.
I'd try to shorten the filenames or paths when this happens, since most other methods are problematic as long as the operating system won't cooperate.
Posted by: calberga on Nov. 13 2006,15:51
Thanks, I didn't mean to throw you such a curve (US baseball metaphor). I'm happy fixing things up, although I'm still not sure why the fixed up files worked in the root directory but not when moved up/down [I never can figure out whether data trees have their branches in the air or in the ground -- one usually draws them with the "root" at the top of the page!] the file structure.
It is also a bit strange that the listing ends in the middle of the previous files data.
Any suggestion on how to get this working?
Posted by: Magnus Brading on Nov. 13 2006,16:10
The most likely reason for it working in the root but not further down the tree (yes, data trees are always upside down I think
) is that the combined path for the file gets longer when you move it down the tree, and this full path length also has some limitations in the operating system.Regarding the file output being cut in the middle of the previous entry, this is typical behavior for crashes of different kinds, when the last internally buffered data by the operating system doesn't get a chance to get flushed to disk before the program crashes.
And again, to make it work, I would try to make the paths and/or filenames shorter.
Posted by: calberga on Nov. 13 2006,17:41
Well, yes, that was what I thought -- BUT the filename at the point of death has been made shorter (by quite a lot, it is now shorter than any other filename in the directory), but the failure is still occuring at the same place in the output.
I can go and shorten the rest of the filenames, but I don't understand why, if it is a different one, the failure should be in the same point in the processing.
CNA
Posted by: Magnus Brading on Nov. 13 2006,18:17
If you put this file in a separate folder (with a name of exactly equal length) adjacent to the original folder, and try to process only that folder, does it still happen?
Just like you, I'd start suspecting that you've mistaken which file that really causes the problem in this situation. But, one should also keep in mind that these limitations/bugs in the file system/operating system might not necessarily be as simple as being dependent on just the pure length of the name/path...
Posted by: calberga on Nov. 13 2006,21:08
I think I have it sorted out, finally. I had managed (as I reported earlier) to move the guilty directory up to the root, where I was able to change the names of the super-long-named files. All well and good. But I looked more closely, and I found files with both the new, short, name and the old, long, name. I don't THINK I copied the contents of the old directory to the new one, but I also can't think of any other way this could have happened.
I'm beginning to worry that I'm down to my last two or three neurons!
Anyway, just for you amusement I can now report that the Custom list gets past that directory ----
However, when the list file reached 4563072 bytes Mp3/Tag Studio simply exited without any message, not even a fond farewell. I had directed the file to an NTFS disk, which already has at least on 12 Gbyte file on it, and with 84 Gbytes of free space, so that shouldn't be the problem.
What now, doctor???
Posted by: Magnus Brading on Nov. 13 2006,21:50
Hehe.
Again, I would guess corrupted ID3v2 tags, depending on the type and level of corruption, a silent exit could occur during some crashes.
Posted by: calberga on Nov. 13 2006,22:57
Well, I guess with 48740 mp3 files in my main library, plus another 7300 plus-or-minus waiting to be files I should expect a few bad files.
Now if you could only produce a scanner to detect them without crashing!
I guess I do a binary search to track this one down.
Posted by: chrispitude on Nov. 26 2006,03:28
I just ran into this problem. MP3TS was exiting silently partway through a custom list. I eventually tracked it down to an excessively long filename. It would be nice if the program handled this gracefully without simply exiting.
At least this thread helped me find the culprit!
- Chris
Posted by: calberga on Nov. 27 2007,18:42
Back again with the same error! Only this time it is more puzzleing.
I have created a list for a rather complicated directory structure, successfully. I am try to create another, with a different set of tags (shorter than the previous) but am getting the dreaded Access Violation error. Strange thing though, on a second try the error occured earlier in the list, on a file that had been processed successfully for the first list.
I'm going to try moving the file up, but even if it works I won't believe that that is the cause, since ALL the files were processed initially, and the second failing file had been processed before the file which killed the process previously.
One other thing -- when I click the "ok" on the error box mp3 T/S does not stop whatever it is doing, but keeps an hourglass displayed, and shows CPU usage in the Task Manager. It even ignores the "cancel". I have to close the program with the "X" box on the window.
Posted by: Magnus Brading on Nov. 27 2007,19:42
Are you using any tag(s) in the new list that was not used in the first one? In that case which one(s)?
Posted by: calberga on Nov. 27 2007,19:58
First list was:
Album | Title | Filename with relative path
second was:
Filename | Title | Filename with relative path
I edited the filename on the offending file, but mp3 TS still threw the error when I tried to edit that file. I then used another program to edit it and delete the Title tag. Then mp3 TS was able to edit it. I might be able to recover the original file, if you like to look at it.
PS, I know the second pattern looks weird, but I'm looking for file with names that don't match my ideal. Thus I need the filename at the start, to make it easy to scan, and the path so I can find the offending file to fix it.
Posted by: Magnus Brading on Dec. 03 2007,15:48
If it only happened with one file, I'd say tag corruption is quite likely. If it happens again with another file, send it to me and I'll take a look at it.
end