Quote:
Originally posted by Matamoros
At version 3.9.10, after ~60s , rather than the CPU jumping to 99%, I get a the following error message (twice) during a lot of disk activity. Is it something to do with ID3v2 parsing? In other words, in subsequent versions, does something get caught in a loop rather than generate an error???
|
We know that there are issues in ID3v2 parsing, because of he way it encodes some field sizes (and ambiguities in its past specifications).
If you have an example of such MP3 file that causes such issue, i would be good to upload it somewhere in a private URL, and to report this URL in a email to dev(at)core.limewire.org (don't post a file to this developers mailing list).
I had personnally a similar issue with a MP3 file that was created or tagged by an unknown codec or tagging tool. The solution o this problem was in a revision of the ID3v2 spec.
We have put some security for this parsing (because in the past it could cause LimeWire to not starting): now we track some malformed or unexpected formats, as well as the possible out of memory errors they could produce.
If your MP3 plays well in your player, or if your player displays the ID3v2 tag correctly, then we have another issue with an unsupported format. Now there is the ID3v2 spec, but there are also undocumented features used in some codecs or taggers, and sometimes too some bugs in various MP3 tagger tools.
The LimeWire's code tries to manage them by at least ignoring unparsable ID3v2 frames. If you know ID3 tags well, you'll see that no player today can read all possible formats (Windows Media Player for example is unable to parse many valid MP3 files and ignores many ID3 tag variants or more recent versions)