Jump to ID:
Multimedia

Project Home

Documents

Discussions

Wiki

Project Info
Forum Topic - mme_metadata_getinfo_current() returns misleading album art info for a track without any album arts on iPods: (5 Items)
   
 
 
mme_metadata_getinfo_current() returns misleading album art info for a track without any album arts on iPods  
Hi,

Just found an issue of mme_metadata_getinfo_current() returns misleading album art info for a track without any album 
arts on iPods.

For the current playing track without an album art on the connected iPod, by using mme_metadata_getinfo_current() to 
query the album art info, it returns the following info from the MME_EVENT_METADATA_INFO event:

ptMME_event_metadata_info->error = 22
ptMME_event_metadata_info->metadata.len = 0
(ptMME_event_metadata_info is a pointer pointing to mme_event_metadata_info_t)

The error=22 means invalid argument, it is a little bit misleading here for the track without an album art. Anyway, it 
is not too bad because we still can refer to the metadata.len member which equal to 0 for a track without any album art.


For s a track it does have album art,  mme_metadata_getinfo_current() will return the album art info as follows:
ptMME_event_metadata_info->error = 0
ptMME_event_metadata_info->metadata.len = 434
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<container type="file">
 <track index="0">
  <audio>
   <stream index="0"/>
  </audio>
  <images>
   <image index="0" loadable="true">
    <format width="100" height="100" size="20070" mimetype="image/bmp"/>
   </image>
   <image index="1" loadable="true">
    <format width="200" height="200" size="80070" mimetype="image/bmp"/>
   </image>
  </images>
 </track>
</container>

It is perfectly fine for a track with an album art. However, the problem is that once mme_metadata_getinfo_current() 
successfully returns an album art info for a track with an album art, it will always report the same info as above for 
the subsequent playing tracks, no matter the track has an album art or not. 

After the problem occur, we have no idea to know whether the current playing track has an album art or not through the 
return info of  mme_metadata_getinfo_current(). That means we have to use mme_metadata_image_load() to attempt to load 
album arts for every song according to the above misleading return info. For the one without album art, 
mme_metadata_image_load() will return a void URL. That is not bad, however, the annoying thing is it still generates a 
void image file in the corresponding location(in my case, /tmp/FAA368087.png) which can not be read by any image viewer.
 Can see the void image as attached.

Just wonder any solutions for that, thanks.

Regards,
Chris
Attachment: Image FAA368087.png 19.6 KB
Re: mme_metadata_getinfo_current() returns misleading album art info for a track without any album arts on iPods  
I can reproduce this or a very similar issue using the trunk software. I have created a QNX problem report 69185. Once 
fixed I can point you to the fixed source code on the foundry and you can try that out to see if it fixes your problem. 
I can't provide you with a fixed binary though, you would have to contact QNX support for that.

Regards,
Gilles
Re: mme_metadata_getinfo_current() returns misleading album art info for a track without any album arts on iPods  
It is now fixed in services/io-media/modules/mediafs/services.c. You should see the change propagate to foundry27 by 
tomorrow, in case you want to test it out yourself. To get an official build you would have to talk to support.

I can't say how it would be best to work around the issue, perhaps you should stat that the temporary image file? If it 
is 0 bytes don't try to display it?

Regards,
Gilles
Re: mme_metadata_getinfo_current() returns misleading album art info for a track without any album arts on iPods  
Hi Gilles,

Thanks for the fix, now asking QNX support for the official build and see how it goes.

Regards,
Chris
Re: mme_metadata_getinfo_current() returns misleading album art info for a track without any album arts on iPods  
Hi Gilles,

Got a build from support team, tested it and found that the problem has been fixed, thanks.

Regards,
Chris