We found the solution via the optimiser, but the only change we made was to add one value to the Windows Registry. You can do that yourself. Details are in the post.

But i use a Linux host now. The fix is for the windows hosts no?

Yes, Linux has it enabled by default. That's why the proxy trick worked.

Then why i have the same problem and need to babysitting on the retry bottom?

Because it's probably not the same problem. Back to square 1, and re-diagnose.

IIRC, the previous problem was downloads that started, but paused part way through and wouldn't restart. Is that happening again?

IIRC, the previous problem was downloads that started, but paused part way through and wouldn't restart. Is that happening again?

The DL some WU the some stops this is an example: After you hit the retry bottom they restart :

Sat 06 Jan 2018 02:41:54 PM EST | SETI@home | Started download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar
Sat 06 Jan 2018 02:41:56 PM EST | | Internet access OK - project servers may be temporarily down.
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_07262_HIP74926_0026.863.818.22.45.164.vlar: transient HTTP error
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Backing off 00:05:58 on download of blc05_2bit_guppi_57976_07262_HIP74926_0026.863.818.22.45.164.vlar
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar: transient HTTP error
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Backing off 00:06:33 on download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar

---

So, what's the transient error? Do the <http_debug> thing.

IIRC, the previous problem was downloads that started, but paused part way through and wouldn't restart. Is that happening again?

The DL some WU the some stops this is an example: After you hit the retry bottom they restart :

Sat 06 Jan 2018 02:41:54 PM EST | SETI@home | Started download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar
Sat 06 Jan 2018 02:41:56 PM EST | | Internet access OK - project servers may be temporarily down.
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_07262_HIP74926_0026.863.818.22.45.164.vlar: transient HTTP error
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Backing off 00:05:58 on download of blc05_2bit_guppi_57976_07262_HIP74926_0026.863.818.22.45.164.vlar
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar: transient HTTP error
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Backing off 00:06:33 on download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar

+1 It's not just Juan

---

So, what's your transient error?

So, what's your transient error?

1/6/2018 12:20:03 PM | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_08930_HIP74235_0031.10414.818.22.45.14.vlar: transient HTTP error

It has cleared now, it has been intermittent all morning.

---

I'm sorry to report no problems at this end at all.

Cheers.

IIRC, the previous problem was downloads that started, but paused part way through and wouldn't restart. Is that happening again?

The DL some WU the some stops this is an example: After you hit the retry bottom they restart :

Sat 06 Jan 2018 02:41:54 PM EST | SETI@home | Started download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar
Sat 06 Jan 2018 02:41:56 PM EST | | Internet access OK - project servers may be temporarily down.
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_07262_HIP74926_0026.863.818.22.45.164.vlar: transient HTTP error
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Backing off 00:05:58 on download of blc05_2bit_guppi_57976_07262_HIP74926_0026.863.818.22.45.164.vlar
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Temporarily failed download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar: transient HTTP error
Sat 06 Jan 2018 02:41:56 PM EST | SETI@home | Backing off 00:06:33 on download of blc05_2bit_guppi_57976_06552_HIP74702_0024.909.818.22.45.128.vlar

+1 It's not just Juan

+1. It's not just them, either. I've had to hit retry with annoying regularity in the last 24 hours, which got things moving again, but even that is now having no effect. <simmering nicely>

---

Don't take life too seriously, as you'll never come out of it alive!

OK, I got one for you.

06/01/2018 20:34:07 | SETI@home | Started download of blc05_2bit_guppi_57976_07596_HIP74209_0027.12052.818.21.44.106.vlar
06/01/2018 20:34:09 | SETI@home | [http] [ID#1362] Info:    Trying 208.68.240.127...
06/01/2018 20:34:09 | SETI@home | [http] [ID#1362] Info:  Empty reply from server
06/01/2018 20:34:09 | SETI@home | [http] HTTP error: Server returned nothing (no headers, no data)

That's a transient error telling me that Vader is on strike.

And this tells me that georgem is working and carrying the load. Note it's the same file.

06/01/2018 20:38:13 | SETI@home | Started download of blc05_2bit_guppi_57976_07596_HIP74209_0027.12052.818.21.44.106.vlar
06/01/2018 20:38:14 | SETI@home | [http] [ID#1367] Info:    Trying 208.68.240.119...
06/01/2018 20:38:14 | SETI@home | [http] [ID#1367] Received header from server: HTTP/1.1 200 OK
06/01/2018 20:38:17 | SETI@home | Finished download of blc05_2bit_guppi_57976_07596_HIP74209_0027.12052.818.21.44.106.vlar

I am seeing the same thing as Richard. I accidentally uncommented Vader and commented Georgem on one machine and started getting no replies from the server for a download request. Quickly fixed again with the correct download server exposure and all things good again. Vader is out to lunch since the recovery yesterday.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

+1. It's not just them, either. I've had to hit retry with annoying regularity in the last 24 hours, which got things moving again, but even that is now having no effect. <simmering nicely>

Since uncommenting 208.68.240.119 in my Hosts file I haven't had a single download issue.
Prior to that, downloads would time out almost as soon as they started.

The Scheduler however is still randomly refusing to allocate work, but it looks like someone has been to work this morning (or at least logged in) as the Average-turnaround and Received-last-hour numbers are updating again.

---

Grant
Darwin NT

I'm getting "transient HTTP errors" when trying to download sometimes. Seems new to me, don't recall seeing them before...

Anyone else getting them?

Any idea what causes them?

I've got a couple that are hung up

I had one last night, wouldn't clear for bit, so I waited and tried again maybe 30mins later, then the download cleared.

Maybe a busy server?

---

Savoir-Faire is everywhere!
The T1 Trust, T1 Class 4-4-4-4 #5550, America's First HST

The Scheduler however is still randomly refusing to allocate work, but it looks like someone has been to work this morning (or at least logged in) as the Average-turnaround and Received-last-hour numbers are updating again.

Well, Average-turnaround and Received-last-hour numbers did update for a while there. They're back on leave again.

---

Grant
Darwin NT

My Windows 10 machine is able to get work every single time while on a VPN connection.

My Linux machines have stuck downloads but retrying seems to get them unstuck.

---

~Chris

My Linux machines have stuck downloads but retrying seems to get them unstuck.

Are you looking to see which of the two download servers that machine is trying to contact, at the time when the sticking happens?

I've been having problems for the last 2 days with stuck downloads on different machines. I have to manually go into each machine and retry downloads. I get the impressions that too many work units try to download at the same time and some get blocked, so they get moved to retry in X minutes. Unfortunately, they get stuck there and never complete the retry. So manually doing it, corrects the issue. My 2 cents.

---

My Linux machines have stuck downloads but retrying seems to get them unstuck.

Are you looking to see which of the two download servers that machine is trying to contact, at the time when the sticking happens?

Just turned on a bit more logging with my Windows 10 machine. A download just got stuck from this server:

1/6/2018 5:53:55 PM | SETI@home | [http] [ID#321] Info: Connected to boinc2.ssl.berkeley.edu (208.68.240.127) port 80 (#319)

---

~Chris

I've been having problems for the last 2 days with stuck downloads on different machines. I have to manually go into each machine and retry downloads. I get the impressions that too many work units try to download at the same time and some get blocked, so they get moved to retry in X minutes. Unfortunately, they get stuck there and never complete the retry. So manually doing it, corrects the issue. My 2 cents.

+ 1 Same experience here.

---

"Sour Grapes make a bitter Whine." <(0)>

I'm sorry to report no problems at this end at all.

Cheers.

. . I think at this stage that is taken as read :)

Stephen

:)

I've been having problems for the last 2 days with stuck downloads on different machines. I have to manually go into each machine and retry downloads. I get the impressions that too many work units try to download at the same time and some get blocked, so they get moved to retry in X minutes. Unfortunately, they get stuck there and never complete the retry. So manually doing it, corrects the issue. My 2 cents.

+ 1 Same experience here.

Since uncommenting 208.68.240.119 in my Hosts file I haven't had a single download issue.
Prior to that, downloads would time out almost as soon as they started.

---

Grant
Darwin NT