tags->artworkcount incorrect about mp4v2 HOT 10 CLOSED

It looks like the problem might be (and I'm waaay out of my depth here) that in
CoverArtBox::list, it calls genericGetItemsByCode( file, "covr" ) to get the 
artwork,
but in reality if there are two pieces of art, there's one covr atom with two 
child
data atoms representing the two pieces of art.

Which version of mp4v2 are you seeing this issue with? The latest trunk 
*should* be working.

Looking at src/itmf/CoverArtBox.*

I have not analyzed the source but I can definitely confirm that this is a bug 
introduced between the unofficial v2.0 released in January and the current 
v1.9.1.  
All other tools, including itunes, agree with v2.0 and attempting to manipulate 
multi-image mp4s will lead to data loss or complete file corruption.

It is 100% reproducible:

% cd .../mp4v2-2.0-20090110/...

% .\mp4art.exe --version
mp4art - MP4v2 2.0-20090110

% ./mp4art.exe --list "Y:\FILE.mp4"
IDX     BYTES  CRC32     TYPE       FILE
----------------------------------------------------------------------
  0   1439270  666f3c3e  implicit   Y:\FILE.mp4
  1   1279714  e2c4f40a  implicit
  2   1352985  f9b1b93a  implicit
  3    666888  215c975c  implicit
  4   1884494  ff3e8afa  implicit

% cd .../mp4v2-2.0-20090110/...

% .\mp4art.exe --version 
mp4art - MP4v2 1.9.1

% .\mp4art.exe --list "Y:\FILE.mp4"
IDX     BYTES  CRC32     TYPE       FILE
----------------------------------------------------------------------
  0   1439270  666f3c3e  png        Y:\Movies\FILE.mp4

[deleted comment]

It looks like this bug has creeped back into trunk. Files that show multiple 
images in itunes only have a 
showCount of 1 in mp4info.

If I try to force iterate, e.g. ignore the count and increment the pointer 
anyway it segfaults.

should be fixed in r372 .
hopefully you guys can confirm and close-out this issue.

Yep, this appears to fix it, I'll close the item.

Good to see you back Kona8blend.

Well I would close this if I could only figure out how.  If someone with the 
proper
authority would close this, it's fixed.

This definitely fixes the bug.  Could I plea for a new source release under 
Downloads?  
The tools from the latest source archive available for simple download 
actively, 
silently and irrecoverably eat data from many mp4 files.  A source archive 
without this 
bug might save a lot of grief to people who do not run an SVN client.