The first beta build to include Aero Peek functionality worked for me, album art and controls showed up fine.
In the builds following it, it would never load and only show the spinning blue circle, no album art or controls.

The current (1292) and previous build both disabled Aero Peek, so now it just shows the full MM window, as if it were any other application's peek.
Tried it in skinned and non-skinned.

Nothing I do can get it to show, including disabling all plugins.
I've been putting of reporting this since I've seen a few posts saying this problem is 'fixed' in the next build, but the problem always persists for me.

The debug log is totally useless, at least as far as I can see, it just repeats this stuff over and over.

5. Playback is active and I am using e.g. MusicIP-Script to autotag my files: NOT OK. Both Aero Peek and the preview uppon Alt+Tab show blue circle only. As soon as MusicIP has tagged all files, the preview is updated and OK again. Other Search Scripts don't cause this trouble.

There are also some other situations causing MediaMonkey not to be able to show correctly in Aeropeek, but I have not been able to reproduce them and find out a reason.

I'm able to reproduce this problem on a transient basis, following Deathaxe's suggestion that MusicIP tagger can trigger the problem--i.e. in his case, it's clear that running the MusicIP Tagger addon can trigger the bug, but that the problem only occurs when the script is actively being used--the issue goes away once the script isn't being used. EDIT: further investigation shows that this particular case is related to the libraries used by the MusicIP script--rather than a problem that's generic to the addons framework. See: http://www.ventismedia.com/mantis/view.php?id=6185 .

Can you both tell me:
-does the problem occur for you if you rename the scripts folder (e.g. rename to /noscripts and then restart MM)?
-- if that gets rid of the problem, can you verify which plugins/addons, or view changes trigger the issue?
-- If the problem persists, does it still occur on a clean install? (clean install=ununstall MM to delete registry settings & .ini settings + rename the scripts folder + manually uninstall the DB (rename it) ).

Thanks for your help & patience re. this issue.

-Rusty

[Edited by Rusty: To indicate that I'm mostly interested in whether disabling scripts gets rid of the problem, and which scripts trigger it.]

I'm grasping and am not sure that we'll find anything, but I'm hoping that perhaps it's related to the views used on your system. To be more specific about what I would like:

1 Rename /Program Files/MediaMonkey/Scripts to .../Scripts2
2 Uninstall MediaMonkey (this will get rid of any configuration settings stored to the registry, along with your C:\Users\gpzbc\AppData\Local\MediaMonkey\MediaMonkey.ini file)--if you prefer you can first change MediaMonkey.ini to MediaMonkey.ini.bak.
3 Rename C:\Users\Rusty\AppData\Local\MediaMonkey\MM.DB to ...MM.DB.bak
4 Install MediaMonkey, let it create new MM.DB, new MediaMonkey.ini, new registry entries, and scan your library
Then verify whether the bug occurs.

You can then change back to your old DB if you wish (filters / playlists / etc. will be retained--you'll just lose some view settings such as column order).

OK, I renamed Registry Key, %Local Appdata%\MediaMonkey and MediaMonkey\scripts to make it clean. MediaMonkey still shows installed extensions, as I did not rename C:\ProgramData\MediaMonkey, but this should not be a problem.

First Situation:
1. I let MM add my Music to the new DB.
2. I press the play-button with an empty playlist.
--> Aeropeek shows waiting cursor!

Second Situation:
1. Select all files in themain listview (about 9000).
2. Start "Get albuminfo from freedb". This takes about 2...3s until the dialog pops up telling me not to have an AudioCD in my drive.
--> During these 2...3s Aeropeek shows waiting curser with and without playback enabled.

I think there I could trigger some more situations like the two above, but I am sure to have an idea what is causing the issue:

A windows application does normally have only one main thread. All messages received by e.g. a click on a menu item or windows itself are handled in this one loop. This means if one message handler needs some time to be ready all other messages are queued but not handled. In fact this means a requested paint cycle (WM_PAINT) is not handled during this time, too. I did not study aeropeek-API, but I think it requests a paint operation from the main window/form, if user hovers the taskbar icon to get the image to show in the preview window. Now that e.g. "Get albuminfo from freedb" has been started a bit earlier and is executed in the main thread by default, the requested paint cycle has to wait. As soon as "Get albuminfo from freedb" is ready, aeropeek is updated correctly.

If I start "Get albuminfo from freedb" I get a waiting curser when pointing to the main form, too and I am unable to move the main window as these requests are not handled, too.

This would mean eighter to move all operations to different worker threads or to "cache" a bitmap of MM's mainform or current album art to be used by Aero Peek. So Aero Peek would always show the last valid image. As soon as a WM_PAINT is triggered, the bitmap is updated by a simple copy operation again.

Summary:

I did not test further scripts for being responsible for this issue, as I think the issue is caused by normal limitations caused by Windows' Message structure. Normally a message handler needs only few milliseconds to finish and therefore a paint request by aeropeek is executed quite soon.

gpzbc,
Project fallback's issue could occur if there's an incorrect MM shortcut pinned to the taskbar (even if there's no quicklaunch icon). Do you have a pinned MM icon in the taskbar? If so, try unpinning it, running MM, and then see if the problem is solved.

sigh..... It didn't work. I unpinned MM icon. Closed MM, ran MM pinned to taskbar. Same spinning circle.
Oh well. It isn't really that big of a deal, but now I have a personal vendetta against the bug.