Printable Version of Topic
-Brading Software Message Board +--Forum: Mp3/Tag Studio Support and Bug Reports +---Topic: Create List terminates with error started by calberga Posted by: calberga on Sep. 14 2007,20:41 I wish to create a database from my mp3s. I attempted to use Create Custom List, with the pattern <Album>§<TrackNr>§<Title>§<Artist>§<V2_TCOM>§<Genre>§<Filepath absolute> intending to import it into a database system (Paradox). However the list creation throws an error message, at different point in the process each time I try it. I can run the process on individual directories and sometimes it works and sometimes not. When it fails I have to go to sub-directories. As long as the target directory (plus its sub-directories) is small enough it completes, but a given directory can fail one time and succeed another. It seems to be my turn to have stocastic errors! To the details (of my latest attempt). I'm running WinXP-Pro, mp3/tag Studio Version 3.5 ß17. The disk I am trying to list has a bit under 10000 directories, with 73498 mp3 files (I know, I'll be dead before I can listen to most of them, don't rub it in). On this attempt the Create List process terminated with the error "Access violation at address 0033706D. Write of address 00000002. The list contains 55323 lines, the longest of which was 650 characters, and the final line ended before being completely written. The list file is 11,704,448 bytes long. I should also note that the progress meter never changes, staying at 0% throughout the whole process. Any ideas? Posted by: Magnus Brading on Sep. 16 2007,12:29 Hmm, I think it sounds like the common problem of heavily corrupted ID3v2 tags causing such crashes. It might be somewhat easy to find the bad files by looking at the resulting (cut-off) list though, the bad file should be the next one to be listed (i.e. you can rule out all the files listed so far in that directory). I'll try to catch these errors better in future versions, but there's just so many things that can go wrong with random corruption, which is what makes it a bit hard. ![]() Posted by: calberga on Sep. 16 2007,16:09 That was my first conjecture, but would that still be the case when the file in question (which ever one -- or ones -- it is/are) do not cause failure when part of a smaller set? As I tried to make clear, if instead of trying to list the whole disk I run the Create List process on individual directories then no failures occur. Sometimes I need to go down a level or two, but I can get listings of all the files, not just in one list without hand editing and combining. So, will a corrupted file cause trouble only when a lot of other files have already been processed, but not otherwise? Posted by: calberga on Sep. 16 2007,20:32 I think I've pin-pointed the problem, and it isn't corrupted files. It is filenames + path which is too long. By moving the offending directory up in the tree I can run the list creator with no problem. The original tagging was done before I moved the directory into my "library" tree (which can get a bit deep -- top-level-directory/meta-genre/composer/album/files) up to the top. When I tried running the list creator on the files in groups I also had to move subdirectories up, in order to group some of them and avoid too many runs. But, when the files are where I want them, the path+name is too long. Bummer! One last puzzle however. When I do try to run on the whole disk the progress meter sticks at 0%, never increasing dispite over 50,000 files being processed before death. Posted by: Magnus Brading on Sep. 17 2007,11:28 Great that you found the source of the problem. These kinds of path size related problems are often rooted all the way down in the operating system, which is a patchwork of old limitations and new extensions when it comes to this, so there is not always an easy fix for it except, as you did, perform some operations closer to the root, and then move the files/dirs back to their desired location. About the progress meter problem, it might be some kind of wrapping bug, I'll note it for taking a look at it later, thanks! end |