Automatic Update not working properly

Same here. I first tried Drush up and it skipped it. Then I tried manually by adding it directly to the server. The "Available Updates" page is still stating I am using 3.0

Had same problem with the automatic update. I deleted the whole folder /sites/all/themes/omega and replaced it with new unzipped omega-folder. Success: admin/reports/updates reports now 7.x-3.1

Hmm, that's what I did and it is still showing 3.0. I just tried emptying cache too.

I think the update had something in the numbering off and it's throwing Drush etc. off. Himerus can you look into this?

Worked on one site and not on a other.
The one it did not was a version of omega with some beta stuff for debugging.

In my case update did not work. I get an error: updaterexception: unable to determine the type of the source directory. in updater::factory() (line 99 of /mnt/webd/c3/96/53067996 with all three updates. Running several times resulted in accepting two updates, but not the HTML5 one.
I used ftp to overwrite the entire omega folder as described before. This worked. No updates now available.

It is unclear what causes this problematic updating. I've had this issue before, but now I'm not happy. This costs a lot of time and there is no documentation available about this error (at least, not found by me after 2 hours searching).

I also experienced this where I ended up having the directory structure omega/omega/omega/omega (seems it creates a folder everytime you update).

I don't know if it's related...but my website became unusably SLOW since the update!!!!!!!! I crapped all over the hosting company for their slow servers and they are still investigating, but since I moved the folders back to how it originally was, and cleared the cache...it seems to be running fine now. I'm running a commerce site that gets a lot of traffic! Could this folder structure have slowed the website queries so dramatically?

Presuming you are working on your localhost, back up your database and website folder, put your site into maintenance mode, and STOP your desktop drupal stack.

Update the Omega Theme from 3.0 to 3.1 Manually

Manual update for the sites/all/themes/omega. remove old omega folder (omega 3.0 version), upack zipped omega update (omega 3.1 version). So now you should have the 'omega' folder (Version 3.1) in you sites/all/themes.

Next, Update Your Sub-Theme to version 3.1

From the starterkits, select and copy the type you had previously (omega-html5, omega-xhtml, alpha-xhtml). Paste it into sites/all/themes. Create a new sub-theme, update the .INFO file with your info. I had to also add ' ' to the first few values listed in the .INFO file

Here's what I also did to patch my existing sub-theme that was carried over from omega version 3.0: I copied the new starterkit folder, renamed my existing omega sub-theme by adding'-orignal' or something, and renamed the new starterkit to what the original existing omega sub-theme had. Get it? The original is renamed and the new one is renamed to the original to take the place of the old original. You can eventually get rid of the original once you've confirmed all is well at the end of this update.

I copied the global.css and any other .css overrides and other modified files from the original sub-theme into the new 3.1 version sub-theme. However, i noticed the .INFO file from the omega 3.0 version differed from the 3.1 version, so I simply copied the pertinent info (Site name, site description) from the original to the new, and added the single quotes to the first few values.

PhpMyAdmin - Manual Updating the Database

Because of that error (described in earlier comments) of the updater adding a '/omega' directory to the structure each time the update was run from within the drupal admin, this means that the system path to the omega theme within the database needs to be manually corrected to restore the path to a not so deep directory. Comprende? Right now it's going to be looking for it 5 or 10 or so 'omega' directories deep. You need to correct it manually to restore it back to normal which is sites/all/themes/omega/... for the alpha filename db entry, and sites/all/themes/omega/omega/... for the omega filename db entry.

Using PhpMyAdmin, Browse your database, locate system and select it to Browse. You should see the columns: filename, name, type, owner, etc..
Locate 'theme' in the 'type' column. Next to the theme types are the names pertaining to Omega and your sub-theme. You'll see the alpha, omega and starterkit_..., and your sub-theme. Here is where you will check your paths for the correct directory structure, correct them as needed, and double check your work. Don't assume you got it right. Be sure.

Run Update.php

Locate 'settings.php' (sites/default/settings.php), right-click, and set the property permission - uncheck Read Only. Open the file in a text editor, and locate/search/find the line: '$update_free_access = FALSE;' change it to '$update_free_access =TRUE'. Save, but keep the file open.

Next, Restart your Drupal Stack/Developer Desktop.
Using your web browser, run your database update by navigating to your site on the local host. It'll be something like: localhost:3036/update.php
Let Drupal do it's update, and if error free, you'll see your themed page again, go to your admin page and take your site out of maintenance mode.

You're not done yet. To avoid a security risk, restore the settings of your settings.php file to it's original state: '$update_free_access = FALSE;' save the file. Set read/write permission back to Read Only.

Now you are finished and should be back to a correct directory structure and recognized in Drupal Admin as having the Omega 3.1 version installed. You have now been pimped!

Thanks @malibumarlin, you just saved my bacon.
One of my sites was completly borked due to this issue - and I've been sweating for hours. Followed steps in #8 and am now running again. Thanks.

*edit: Spoke to early - looked fine logged in as admin. Logged out and could only see maintenance screen. Refreashed cache and it's borked again. Grrr. I will nee dto sleep and try working through detail again tomorrow.

yes, that's what i saw until i ran ' /update.php' . did you go through those last couple of steps? Or, recheck your url edits in the database.

I think the issue I have left is definitely something cranky in the database. Followed instructions above, (except reboot, as I'm running this on a shared server).
I rolled back to Omega 7.x-3.0, and fixed the paths in database. ran update.php
I have worked out now that it keeps working UNTIL i manually clear caches. Then it borks again, and the only way to get it back is to restore database to point before the cache clear - which is doing my head in, as my backups (Backup and migrate) dont contain the cache tables.

It definitely started with the original attempt to upgrade to Omega 7.x-3.1, and I suspect during that process there was another database change that was not backed out when I reverted to 7.x-3.0...?

My log is showing a heap of warnings: eg:
Notice: Undefined property: alpha_theme_container::$page in omega_alpha_process_region() (line 170 of /home/clients/websites/[user]/public_html/[sitename]/sites/all/themes/omega/omega/template.php).

Notice: Undefined property: alpha_theme_container::$page in omega_alpha_process_region() (line 174....
Notice: Undefined property: alpha_theme_container::$page in omega_alpha_process_region() (line 176...
Notice: Undefined property: alpha_theme_container::$page in omega_alpha_process_region() (line 177...
Notice: Undefined property: alpha_theme_container::$page in omega_alpha_process_region() (line 179...
...

Now unfortunately - it appears that is a problem that was covered by this issue http://drupal.org/node/1253076 that looks like it was fixed for the 7.x-3.1 release. (that describes my error codes, and my clean-style page without content that I get stuck on until I revert database)
But Never saw it UNTIL I tried to upgrade to 7.x-3.1, and then had to back it out.
So now appears that my solution will be to try to install the update to 3.1 that causes all my problems to start with...

I might have to schedule that for next weekend for another attempt - and hope I don't need to clear the cache manually this week.

ooookkkk...I'll wait until there's a new version of Omega and hopefully they've fix the automatic update there of...

we experienced this is well and the issue manifested itself as us not being able to save any of the theme settings at admin/appearance/settings/THEME_NAME

we manually deleted all omega theme & subtheme files from the server, flushed caches, and then manually added the 3.1 theme and recreated our subtheme from that (similar to malibumarlin's great instructions above).

...only difference is that after doing the above the paths in the DB system table for the themes were correct without any manual adjustments. We still had to rename our theme to a different name: e.g. THEME_NAME_TWO for all to work as expected. Uploading THEME_NAME again (just to double check) and attempting to save theme settings still yields no changes for that theme...

I don't think this is an Omega issue as I am getting the same problem with a clean install (no omega) and trying to get updates for token.

I think this is something in the repos that D.O. is using. If the numbering or other aspects are off it'll throw things off. We'll keep an eye on this when 3.2 comes out.

AWESOME! Still no automatic fix!

This problem has existed for a whole year and still there is no update. I was right in leaving Omega but still have 2 legacy websites that use Omega.