spoke to soon... Update information not updated

sounds like more of an update status issue to me... perhaps they can provide some hints?

A) Please post the contents of your copy of the audio.info file into this issue.

B) Please visit admin/build/modules, press the "Save configuration" button, then visit admin/logs/updates again and see if things are working as expected or not.

I just installed the audio 5.x-2.x-dev release on a test site and update_status is working just fine, so this is no longer a bug report, it's a support request...

Cheers,
-Derek

I had the same problem, with a few modules I updated. When I compared the info files of old and updated modules, they were different and the updated module was correct. As you suggested, navigating to modules admin/build/modules page and clicking 'save configuration' solved the issue and update status reported correctly.
Thanks

Sorry, I too am still having the issue... here is an example:
The updated calendar module info file

sites/all/modules/calendar# cat calendar.info
; $Id: calendar.info,v 1.1.2.3 2007/06/18 23:06:32 dww Exp $
name = Calendar
description = Adds date calendar themes to views that can display any type of date field, and creates default calendar views.
package = Views
dependencies = views date_api
; Information added by drupal.org packaging script on 2007-10-14
version = "5.x-1.6"
project = "calendar"
datestamp = "1192388405"

The old module info file:

sites/all/modules/calendar.BAK# cat calendar.info
; $Id: calendar.info,v 1.1.2.3 2007/06/18 23:06:32 dww Exp $
name = Calendar
description = Adds date calendar themes to views that can display any type of date field, and creates default calendar views.
package = Views
dependencies = views date_api
; Information added by drupal.org packaging script on 2007-07-06
version = "5.x-1.5"
project = "calendar"
datestamp = "1183737006"

When I initially ran cron and then checked manually for updates, nothing was being reported as requiring updates. After clicking 'save configuration' on the module admin page, then there was a report for a database update, so ran the update.php script. I then thought that would solve the reporting problem, but upon checking in the status report, the update is still being reported as required.
Thanks

Sorted this out... It's a bit of a long story...
So with the recent 5.3 security updates, 'update status' listed the updates I needed to get. I grabbed the 5.3 version update, backed up database and sites directory, disabled all none core modules, put the 5.3 version in the web root, moved my sites directory in and ran the update. All went well, so went off to 'Update status'. It was reporting the new Drupal 5.3 version correctly. I enabled all modules again, and checked status. The same modules that were indeed updated are still being reported as not being updated, plus two additional modules listed as requiring security updates (pathauto and token). So, I started to grab and paste all the modules that were being reported wrong to post a further support request when I noticed something. When I grab a new version of a module, the first thing I do before extracting it is to create a backup copy of the existing module directory. My naming convention is to append the module name with ".BAK". The complete list of all modules that were not being updated also happened to have the .BAK directory in the /sites/all/modules/ directory. So, I looked at the first module in the list that was not being reported properly by update status, moved the .BAK directory to another directory, refreshed the status update page and surprise, the module now reported correctly.

So, the module was reading the .BAK directory rather than the newly uploaded directory. "Bingo!" I thought, I discovered the solution and moved all the .BAK directories into a sites/all/modules/BAK directory rather than have them in the /sites/all/modules/ directory. I then went to refresh the sites status page but was greeted with:
Fatal error: Call to undefined function og_get_group_context() in /var/www/drupal/sites/all/modules/og_vocab/og_vocab.module on line 109
So, I put the .BAK files back in the modules directory and removed them one at a time until I found the culprit which was the og.BAK2 (I had more than one of some of the .BAK directories). After that, I ran cron, update.php, and checked with status update. Most of the issues went away, but a few are still lingering. So, I decided to move my backup directory from drupal/sites/all/modules/ to /drupal. I then ran cron, update.php, etc and everything was reported correctly. So, my lesson learned, nothing in the modules directory but the modules actively being used.

With regards to my organic groups issue, I think I messed that up with some sleep deprived updating in the past. I didn't see a 'og' directory, only an 'og.BAK' and 'og.BAK2' so Drupal used what it though was best and now I will have to surf on over to the Organic Groups module page and try and learn how to solve this issue *sigh*.

Glad you figured it all out. Don't know why this was left in "active (needs more info)". ;)