Well it's nice to know that the program is working for somebody other than myself. Long filenames ( > 48 characters long as a conservative estimate) ARE what's causing the current unreliability, so next on my list is getting this issue fixed. I have the code for extracting ID3 tags mostly completed, so once I finish with long filename support I'll probably finish implementing it and then post the fixed version. From the test that I've been running, the current version on my computer can handle all the following situations reliably:
Any number of songs with short names which do not contain any ID3 info, located across any number of different folders/drives, using any naming convention(s).
Any number of songs with short names which contain ID3v1 and/or ID3v2 info, located across any number of different folders/drives, using any naming convention. Info in ID3 tag does not have to match naming convention(s).
Any number of songs with short names which do not contain any ID3 info, mixed with any number of songs which do have ID3v1/ID3v2 tags in any order, across any number of different folders/drives, using any naming convention(s).
A list containing a single long filename may work provided that the long filename is the last entry. Nero will not be able to read it, however, and will give you an error message wbout how it cannot find the file, thus making it pointless to have the long filename in the playlist in the first place.
Support for any length filename and ID3v1 tags is pending...also, if you are using Winamp 2.xx to generate the .m3u file, make sure you have the playlist configured so that it displays songs in <artist> - <title> format. This may prevent some issues with the version posted above, and will help to ensure that the filepath is always the largest element of data in each set (which is important because I plan on using the path to determine whether an entry counts as a long entry or not...although I guess I could just as easily check both fields).
EDIT: The long name problem is pretty simple actually...if the length of an entire entry (path + filename + filename + ID3 tags + "blank" space used to seperate + bytes used to indicate the length if each individual part) is greater that 255, extra characters are needed to represent the length...I predict that fixing this will take about 5 mins. I guess I'll start rambling about this stuff and go code now.
EDIT2: it worked...the app now supports all files up to a length of 255 * 255 characters long. They don't even MAKE an operating system that would let you overrun that buffer...
Last edited by Some1; 19th September 2002 at 07:22.