It should be safe now with the new app update. If you have any 3.43 jobs cached or running, please cancel them and update your client to get the new app update.

This is an easy fix on our end of course.

The database issue that I mention on the news is also being dealt with in this update. In the current update we added a new database file that would allow us to automatically generate protein fragments on the fly which would significantly reduce the turnaround time for many targets we process on our automated server Robetta. We decided to remove this file since it increased the size of the database over 2x and the file would not be used for a majority of the our BOINC jobs, and some users have reported issues that might be related to this (issues of possibly hitting disk space limits, etc.) There are other options we can pursue that will not require adding this file to the R@h application package.

That actually sounds like the screensaver. Would it be asking too much for a screenshot. You can email it to dekim at u. washington .edu

Does it look like the images on:

http://boinc.bakerlab.org/rosetta/rah_graphics.php ??

what do the pop-ups say?

we may have to revert our update if this is the case.

I also have completed work units failing to upload on two different computers(although some work units are uploading wihout any problems). Below are the Message Lines from the Event Log. Will the Rosetta Team be resolving the problem discribed above, or do I need to manually do something? Please help:-s

Please review my original comment here

I think that you are asking for validate errors with this method because it is quite possible that the server that a work unit is assigned to is the only one that can validate it.

=====
Not true. I had no validation problems, and received credit for all of the uploaded work units.

Right, it would be possible for a project to set up their servers in such a way that you'd earn yourself a validation error. I do not believe R@h's server configuration will have any problem with the specific of which upload server is used, since they all feed the same underlaying database and data store.

All I meant about the "etc." is that there are numerous ways to redirect the host name and achieve the same result. The other thing is to put it all back when you are done, although the potentially riskier approach described with modifying the client state file avoids that. I say "riskier" because there are certainly very simple ways to corrupt that file and end up trashing all of the tasks you have. Not riskier for your computer, just for your earned credits and current task list.