Dan Cardamore wrote:
>  In 1.1 the art from MP3 files is fetched directly with MMF since the
>  MME is linked against MMF for just artwork.   This means you would
>  need to look through the top layer of the MME (devctl.c and photo.c)
>  to trace if there are leaks there.  Failing that my guess is that the
>  issue is in MMF, in which case you may want to try with different
>  types of container formats to see if it is an MP3 or MPEG4 issue for
>  example.

We've seen the problem on repositories with just aac files as well as on
mixed repositories with aac, wma, mp3 and wav files.

Part of the problem is that I have _no_ album art and the memory usage
is shooting up just because of the API call being made.

Is the release product tagged in the repository so that I could go back
and look at the code that is close to what I'm using to see if I can help
you guys narrow this down?  As far as I can tell the project was created
post 1.1 release and doesn't contain the 1.1 code as it was for the release.

Otherwise, I guess this will have to go the route of priority support to get
a patch made for 1.1 since this additional memory allocation will quickly
overflow our configuration.

I'll also take this opportunity to comment that the new history/sync 
mechanism
is kind of gross.  Every single revision log looks like:
Original-Revision: r216491
Original-Date: 2009-03-25T13:23:45.320812Z
Original-Author: groy@qnx.com
Original-LogMsg: PR:64241
CI:dcardamore
- Rename this file

Ugh ...

>  The next release that we're working towards is 1.2.  mme_getphoto( )
>  replaced with a much more robust image framework that offers the
>  following features: *  Metatadata for images.  Find out how many
>  images there are and other details such as their size and dimensions.
>  * load images on demand.  mme_getphoto( ) could only load the first
>  image, 1.2 can load any image in a file that was looked up previously
>  * large image support.  1.1 only supported images smaller than 64kb
>  * image profiles and conversion so that you can have thumbnails
>  created, or have all your images in JPEG format.  Configurable and
>  built on top of QNX's libimg library * image caching so that
>  subsequent lookups don't have to go back to the device or parse the
>  image

While the head branch is interesting, I need to work with released 
product =;-(

I'm also slightly concerned that version 1.2 (a minor version change) would
actually drop a public API.  Am I mis-understanding what you are saying?
 From what I see in the repository, there is no cover function for the
mme_getphoto() client call, though there is still an (unused?) header in 
main.h
indicating that there should be a server side call.

Thanks,
 Thomas