If you have stalled downloads that have shown up in your results page but are stuck in the Transfers queue, and are familiar with BOINC and managing files at the OS level, you may like to try this.

1. Create a cc_config.xml file http://boinc.berkeley.edu/client_msgs.php in your BOINC directory. Add the tag <file_xfer_debug>1</file_xfer_debug> to cc_config.xml in the <log_flags> section.

2. Go to the Advanced menu of BOINC Manager and click Read config file.

3. Go to the Transfers tab of BOINC Manager, select one of your stalled downloads and click Retry Now. Go to the Messages tab and highlight the line that contains [---] [file_xfer_debug] PERS_FILE_XFER::start_xfer(): URL: http://setiboincdata.ssl.berkeley.edu/sah/download_fanout/. Copy this into Notepad.

4. Open http://boinc2.ssl.berkeley.edu/sah/download_fanout/ using your favourite web-browser. Scolll down until you find the matching sub-directory e.g 73, c3, 3ae, 3d3. Open the sub-directory. Search within the page for the matching file name. (You may have to do a partial search as the file names appear truncated in the browser view, but this should narrow down your search to a few lines.)

5. Right click the appropriate file, and download to a suitable location on your computer. (I chose "\\Program Files\\BOINC\\projects".)

6. Move the file to "\\Program Files\\BOINC\\projects\\setiathome.berkeley.edu" using Windows Explorer (or equivalent); you will probably be prompted to over-write a 0 byte file with one of 354 KB.

7. Go back to the Transfers tab of BOINC Manager, select the same task and click Retry Now again.

8. Back to Messages tab and you should now see "[SETI@home] File xxx exists already, skipping download", the file should also go from the Transfers queue.

9. Run the task normally.

10. Repeat steps 3-8 as necessary.

It worked for me. HTH.

---

Sir Arthur C Clarke 1917-2008

Thanks Keith,
Tried it differently which worked for me. Instead of using the cc_config.xml approach:

1. Obtain file/foldername from the stuck workunit in the client_state.xml
2. visit the http://boinc2.ssl.berkeley.edu/sah/download_fanout/
3. download the correct file (locating by the sequence you described), overwriting the zero length one
4. "retry now"

Have 2 workunits crunching now :D [ Sadly my other machine has no downloads allocated, oh well, ones enough 'til they get back and kick those servers :D ]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Thanks Keith,
Tried it differently which worked for me. Instead of using the cc_config.xml approach:

1. Obtain file/foldername from the stuck workunit in the client_state.xml
2. visit the http://boinc2.ssl.berkeley.edu/sah/download_fanout/
3. download the correct file (locating by the sequence you described), overwriting the zero length one
4. "retry now"

Have 2 workunits crunching now :D [ Sadly my other machine has no downloads allocated, oh well, ones enough 'til they get back and kick those servers :D ]

Glad it worked, your method is probaly simpler for those that do'nt already have a cc_config file. It also involves less load on the server as you only need to re-try once for each file instead of twice.

I have also set SETI and SETI Beta to No new tasks for a few days until network traffic quietens down.

While you are waiting for more SETI tasks, why not add Rosetta or another project. I like Rosetta because it has a quorum of 1 so you get instant credit for valid results!, the graphics are very good too.

---

Sir Arthur C Clarke 1917-2008

Well done Keith - splendid workround, worked a treat.

But a word of warning - it can become horribly addictive!

I had a few stuck, so I downloaded them manually and started crunching SETI again. As soon as the download queue, was empty, the beast contacted the scheduler again and got allocated some more. So I downloaded a few of those as well: all with the shortest deadlines (4+ days). Which on my rig go immediately into EDF. And some of them were -9 overflows, so now they're in the upload queue instead. So I need to download some more....

Ah well, back to the asylum, LOL.

It is a lot easier if you just use proxy 128.32.18.173 this will allow download but not uploads, please turn off the proxy when downloads complete so others can use it.

---

i have done a bulk replace of
http://setiboincdata.ssl.berkeley.edu/sah/download_fanout/
to
http://boinc2.ssl.berkeley.edu/sah/download_fanout/
in
client_state.xml

bussy downloading WU's

---

Thanks Keith,
Tried it differently which worked for me. Instead of using the cc_config.xml approach:

1. Obtain file/foldername from the stuck workunit in the client_state.xml
2. visit the http://boinc2.ssl.berkeley.edu/sah/download_fanout/
3. download the correct file (locating by the sequence you described), overwriting the zero length one
4. "retry now"

Have 2 workunits crunching now :D [ Sadly my other machine has no downloads allocated, oh well, ones enough 'til they get back and kick those servers :D ]

Thanks Jason and Keith.
I can get wu to work.

i have done a bulk replace of
http://setiboincdata.ssl.berkeley.edu/sah/download_fanout/
to
http://boinc2.ssl.berkeley.edu/sah/download_fanout/
in
client_state.xml

Just a suggestion, but don't forget to return it to normal once all available work has been downloaded.

It is a lot easier if you just use proxy 128.32.18.173 this will allow download but not uploads, please turn off the proxy when downloads complete so others can use it.

Thanks for the tip. Worked like a charm and I've turned off the proxy.

---

It is a lot easier if you just use proxy 128.32.18.173 this will allow download but not uploads, please turn off the proxy when downloads complete so others can use it.

WOW! that's awsome!!

If you have stalled downloads that have shown up in your results page but are stuck in the Transfers queue, and are familiar with BOINC and managing files at the OS level, you may like to try this.

Thanks Keith

This worked out great. I have never looked or even played with Boinc codes, but your instructions worked the first time. I usually just let Boinc crunch away. I was able to download all five wu's on SETI, but SETI beta has the scheduler disabled so I can not clean that wu up. I will have to start to look into Boinc coding more now.

---

[color= blue][u]SETI@home classic workunits = 5,906 with CPU time of 60,377 hours[/u][/color]

It is a lot easier if you just use proxy 128.32.18.173 this will allow download but not uploads, please turn off the proxy when downloads complete so others can use it.

Worked a charm to get the WUs stuck in the download queue clear (very fast transfers too). Thanks, helps keep things going while we're waiting for someone to smack the servers around.

Now if only there was a way to clear the 16 WUs stuck in upload.

---

The proxy server setting work to get my downloads. I also noticed very fast transfers. How does this work? I have never tried or had to use a proxy server in Boinc before.
And is there such a thing as a proxy server that will handle the uploads?
Thanx for the work around.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I think we ought to be a bit cautious about the proxy. The IP address given resolves to galileo.SSL.Berkeley.EDU: a few days ago Tony (Astro) posted here:

they've blocked the galileo loophole. That addy went through the campus network which they paid dearly for(in cash). Not to mention that it'd do NO good this time as all outgoing work need to be written to thumper so it knows who's got what. there's no sneaking around this time.

It looks as if they unblocked the galileo loophole - deliberately or otherwise.

If what Tony says about the cost of the Campus network is still true, then anyone who used that proxy owes them (another) donation - and please make doubly sure that you remove the proxy information as soon as possible after use.

I know people snuck around the normal path using galileo one time previously. It used to go through the much more expensive campus network. They saw the traffic and killed it. Looks like the loophole is back open. I view the previous use of this as selfish and self serving. Having NO respect for the project and it's needs($$$). Just because it works, doesn't make it the right thing to do. This only applies if it's still on the campus network (which it used to be, but I don't know that now). They're required to use the campus network and have been using it for low traffic things like these message boards.

I await word from them, before solidifying my position on this issue. I won't be using it. Until I know it's not costing them an arm and a leg.

The final part of my tracert looks like this:

23 177 ms 177 ms 177 ms calren-trcust.plalca01.transitrail.net [137.164.131.254]
24 178 ms 185 ms 177 ms ucb--svl-dc1-egm.cenic.net [137.164.23.66]
25 178 ms 177 ms 176 ms g3-17.inr-202-reccev.Berkeley.EDU [128.32.0.35]
26 177 ms 177 ms 177 ms g6-2.inr-230-spr.Berkeley.EDU [128.32.255.114]
27 177 ms 177 ms 177 ms ssl-f1.SSL.Berkeley.EDU [169.229.0.218]
28 179 ms 178 ms 178 ms galileo.SSL.Berkeley.EDU [128.32.18.173]

inr-230 Sproul looks, according to the cricket graphs, very much like a primary campus network. I think we should stay off it.

Anyway, it's all academic (sorry) now. The cricket graphs also show that the proper route has just started up again, and with a vengeance - Cur: 55.21 Mbits/sec.

It is a lot easier if you just use proxy 128.32.18.173 this will allow download but not uploads, please turn off the proxy when downloads complete so others can use it.

Thanks, works like a charm (not that fast, but enough)

How ever any donations is out of the question, it's quite enough I participate in this thankless drivel for free ...

Did you expect to be compensated for volunteering? ROFLMAO Ok.

---

thanks for the work round julian with the proxy server
worked a treat 4 computers working again crunching for setti.


greenfinger

---

i have done a bulk replace of
http://setiboincdata.ssl.berkeley.edu/sah/download_fanout/
to
http://boinc2.ssl.berkeley.edu/sah/download_fanout/
in
client_state.xml

bussy downloading WU's

Excellent! You identified what was failing (the redirect) and found the correct workaround method.

                                                               Joe

Oh yeah this.. Sorry but this doesn't work anymore.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude