Problem reporting tasks

I have been unable to connect to the server for close to a week now. All I get is the HTTP internal server error; Project communication failed; Internet access OK: project servers may be temporarily down; Scheduler request failed:attempting access to reference site.

Am I out of luck with my application now because of the changes that Seti@Home has made? When I was able to get WU's last, I got the invalid app error.

I run a legacy operating system. We only have the one application that has ever been written for it. Is the problem of older application version in the app_info.xml file the reason I can no longer communicate with the project?

I also recently installed a Ubuntu Linux system onto this computer and have been switching between the OS's occasionally. When I booted into the Linux system, it had no problems getting new work after the servers came back online.

Is there anything I can do to correct the issue on my end with the eComStation application? Can I edit something in the app_info.xml file that will fix it and not break the application further. Can I spoof some other version of the application to make Seti believe I am running a more recent version of the application?

Cheers, Keith

Hey guys and girls,

Sorry i haven't been around much. Been busy working on some web servers for a company.

Anyway.. After having these same issues i did some debugging.

Noticed that the URL boinc tries to connect to is initiating a request on port 80 (http) so naturally that means apache or something is installed on that server.

Tried accessing http://setiboinc.ssl.berkeley.edu or even http://ssl.berkeley.edu a few times over an hour, i got 4 successful requests which returned the default fedora test page. And the rest were not successful.

"The server at http://setiboinc.ssl.berkeley.edu is taking too long to respond."

This means boinc cannot communicate with it either. Now i'm not sure if it's some sort of network issue and why it's only affecting a few people and not others. But i know one thing, it's certainly an issue with the server running the scheduler since obviously it's inaccessible a large amount of the time.

I have a feeling either there is an issue with the web server setup or a routing issue somewhere, if they use NFS maybe something isn't working right between communication of the schedule servers and database servers.

Just thought i should let you know, since although there have been a few fixes listed here, none of these /should/ in theory be actually fixing anything as the problem lies with the connection to that URL.
____________
- Jarryd

@Hellsheep, solving the "can not connect error" is indeed beyond our control (apart from retrying over and over ;)) However the "HTTP internal server error" is returned by the server. So in those cases the connection did succeed. This error is found to be related to a reference in onces app_info.xml file to the old AP version. Appearantly the update to the server sided software on July the 26th does not take into account that reference anymore.

Since this is a referal to an optimized application on the windows platform, only those clients who installed that particular version of the optimized client are affected.
Removing the entry for optimized AP versions other then v505 will solve it for now.
____________

@Hellsheep, solving the "can not connect error" is indeed beyond our control (apart from retrying over and over ;)) However the "HTTP internal server error" is returned by the server. So in those cases the connection did succeed. This error is found to be related to a reference in onces app_info.xml file to the old AP version. Appearantly the update to the server sided software on July the 26th does not take into account that reference anymore.

Since this is a referal to an optimized application on the windows platform, only those clients who installed that particular version of the optimized client are affected.
Removing the entry for optimized AP versions other then v505 will solve it for now.

There's two different problems here:

a) a general connectivity issue i.e. difficulties to connect for everybody getting through only part of the time

b) a host specific 'unable to connect at all' issue, that has been traced to app_infos containing old (no longer supported) application data, probably due to some server side change. This problem can be resolved by removing blocks refering to old applications from app_info.
____________
Carola
-------
I'm multilingual - I can misunderstand people in several languages!

Well....
I would debate the effect of anything in the app_info.
All 4 of my crunchers are running the exact same Lunatics installed optis and app_infos....
And have been able to connect and report work most of the time.

I just tried a manual update on the Frozen 920, and got the can't connect to server error twice in 10 minutes trying to report 41 completed tasks.

Watching the NIC status lights, I can see Boinc trying to get the server, but the server never answers. So whatever is in my app_info isn't even coming into play. And this with the Cricket graphs showing slightly declining traffic all day....

The problem is not with my television set.

It depends on the messages you see in BOINC Manager.

but...

b) If you see the specific message "HTTP Internal Server error", check that your app_info.xml file is really as clean as you think it is.

I cleared my app-Info.xml, but still getting the HTTP Internal Server Error.

2-8-2010 0:07:28 SETI@home update requested by user
2-8-2010 0:07:30 SETI@home Sending scheduler request: Requested by user.
2-8-2010 0:07:30 SETI@home Reporting 11 completed tasks, requesting new tasks
2-8-2010 0:08:44 SETI@home Scheduler request failed: HTTP internal server error

Could some one check my xml and tell me weather it is correct or not?

<app_info>
<app>
<name>astropulse_v505</name>
</app>
<file_info>
<name>ap_5.05r168_SSE.exe</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse_v505</app_name>
<version_num>505</version_num>
<file_ref>
<file_name>ap_5.05r168_SSE.exe</file_name>
<main_program/>
</file_ref>
</app_version>
<app>
<name>setiathome_enhanced</name>
</app>
<file_info>
<name>AK_v8_win_SSE2.exe</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>603</version_num>
<file_ref>
<file_name>AK_v8_win_SSE2.exe</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

Looks fine to me....only 603 and 505, both of which should be fine.

Which confirms to me that the problem is within the Seti servers, and may have little to do with the condition of one's app_info file.

There was an error in my app_info file.
After adding <app> right after the first <app_info>, restarting BOINCmanager and trying to update 4 times, suddenly the wu's were reported, and new wu's were downloaded.

Thanks BuddyWolly for this work-aroud.

Ah, I thought I saw a difference between Mark's quote and my quote of ostensibly the same message. If you've posted asking for help, and subsequently edit the data you're asking about, it would be helpful to mention the edit in a footnote.

Anyway, glad you worked it out in the end.

You are right, sorry for that.

But there still seems to be another problem: