View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005696 | MMW v4 | Properties/Auto-Tools | public | 2009-05-31 01:41 | 2019-01-30 09:06 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Target Version | 3.1 | Fixed in Version | 3.1 | ||
| Summary | 0005696: Reading corupted/mixed multiple MP3 tag types can Block MM | ||||
| Description | As Reported here http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=40020 Adding that file to MM NowPlaying locks/slows MM to beyond usability. Tested with 1249, Original file is uploaded to FTP along with Fixed Tag Version of Same File | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1250 | ||||
|
|
The problem is in the file, the header indicates ID3v2.3, while in reality it looks like ID3v2.2. This causes that we read Title field of a length of ~2mil. characters, which makes everything pretty slow then. We should review, whether we could make some small a safe tweak to ID3Lib, so that the Title field isn't incorrectly read from the file. |
|
|
Fixed in build 1250. The file has ID3 tag with 2MB Title field (it contains copy of the first 2MB of mp3 binary data and then title), working with this field make MM nearly frozen. I limited reading of the text field to 1kB, I think this is enough. User then should use "Clean ID3v2 tags". |
|
|
As discussed over IM, this solution should be reverted, as we can't limit field length for users. We should check out, why ID3lib parses the file, as I look into it, it seems that according to specs, there shouldn't be any valid field found (as also WinAmp doesn't find any). |
|
|
Fixed in build 1250. Jiri was right, ID3lib recognized frame in the tag wrongly (mixed ID3v2.3 and ID3v2.2 names). The file has ID3v2.2 tags, but indicates them as ID3v2.3 tags. I've fixed ID3lib and removed the 1kB limit. |
|
|
Verified 1250 |
