Since manually removing and manually adding the project on 20 May I have received 9 WU's. 5 were completed and validated succesfully, 2 error's while computing, and 2 are still in progress.

The 2 errors were
Stderr output

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
14:39:18 (15540): wrapper (7.9.26016): starting
14:39:18 (15540): wrapper: running acemd3.exe (--boinc input --device 0)
EXCEPTIONAL CONDITION: src\mdio\bincoord.c, line 193: "nelems != 1"
14:39:21 (15540): acemd3.exe exited; CPU time 0.015625
14:39:21 (15540): app exit status: 0xc0000409
14:39:21 (15540): called boinc_finish(195)
0 bytes in 0 Free Blocks.
440 bytes in 8 Normal Blocks.
1144 bytes in 1 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 0 bytes.
Total allocations: 149458 bytes.

and
Stderr output

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code 195 (0xc3)</message>
<stderr_txt>
14:39:24 (640): wrapper (7.9.26016): starting
14:39:24 (640): wrapper: running acemd3.exe (--boinc input --device 0)
EXCEPTIONAL CONDITION: src\mdio\bincoord.c, line 193: "nelems != 1"
14:39:27 (640): acemd3.exe exited; CPU time 0.000000
14:39:27 (640): app exit status: 0xc0000409
14:39:27 (640): called boinc_finish(195)
0 bytes in 0 Free Blocks.
440 bytes in 8 Normal Blocks.
1144 bytes in 1 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 0 bytes.
Total allocations: 150312 bytes.

Duplicate GPUGRID project after HTTPS switch, please correct:
http://www.gpugrid.net/forum_thread.php?id=5128

Michael.

---

President of Rechenkraft.net - Germany's first and largest distributed computing organization.

project will not let me remove and reset it

---

projset will not let me delete it so i can readd the correct url i want to work in the vuri=us 19 programs robert ritter jr

Projects can't prevent themselves being removed. More likely, you attached via an Account Manager: then you'll have to use the same account manager to remove it.

Moreover, Mr. Robert, you are trying to add to GPUGRID project a computer that seems not to have any properly working NVIDIA GPU.
Please, take a look to this previous post. It is regarding other user in similar situation, and contains a link to current project specifications.

Downloads unsuccessful:

5/24/2020 1:40:41 PM | GPUGRID | Started download of 1b06A01_348_0-TONI_MDADpr4sb-0-conf_file_enc
5/24/2020 1:40:41 PM | GPUGRID | Started download of 1b06A01_348_0-TONI_MDADpr4sb-0-coor_file
5/24/2020 1:40:43 PM | GPUGRID | Temporarily failed download of 1b06A01_348_0-TONI_MDADpr4sb-0-conf_file_enc: transient HTTP error
5/24/2020 1:40:43 PM | GPUGRID | Backing off 05:42:39 on download of 1b06A01_348_0-TONI_MDADpr4sb-0-conf_file_enc
5/24/2020 1:40:43 PM | GPUGRID | Temporarily failed download of 1b06A01_348_0-TONI_MDADpr4sb-0-coor_file: transient HTTP error
5/24/2020 1:40:43 PM | GPUGRID | Backing off 05:54:02 on download of 1b06A01_348_0-TONI_MDADpr4sb-0-coor_file
5/24/2020 1:40:43 PM | GPUGRID | Started download of 1b06A01_348_0-TONI_MDADpr4sb-0-vel_file
5/24/2020 1:40:43 PM | GPUGRID | Started download of 1b06A01_348_0-TONI_MDADpr4sb-0-idx_file
5/24/2020 1:40:44 PM | GPUGRID | Temporarily failed download of 1b06A01_348_0-TONI_MDADpr4sb-0-vel_file: transient HTTP error
5/24/2020 1:40:44 PM | GPUGRID | Backing off 04:58:47 on download of 1b06A01_348_0-TONI_MDADpr4sb-0-vel_file
5/24/2020 1:40:44 PM | GPUGRID | Temporarily failed download of 1b06A01_348_0-TONI_MDADpr4sb-0-idx_file: transient HTTP error
5/24/2020 1:40:44 PM | GPUGRID | Backing off 05:54:39 on download of 1b06A01_348_0-TONI_MDADpr4sb-0-idx_file
5/24/2020 1:40:45 PM | | Project communication failed: attempting access to reference site
5/24/2020 1:40:47 PM | | Internet access OK - project servers may be temporarily down.

Downloads unsuccessful:

Those look like these two

There were some bad tasks made by mistake around that time. Too late to rescue them now: just abort the tasks, and get another pair. The tasks being made now should download OK, though do keep an eye open for more rogue bad ones.

I've lost my statistics in the local BOINC manager. I monitor these. This is frustrating. I wish I hadn't bothered. I also lost all running work units. What happens if I don't bother making this change to https on my other machines?

If projects make these changes then surely they should provide detailed step by step instructions as to how to achieve the change without affecting this type of thing. As a matter of courtesy, if for no other reason.

We shouldn't have to read through forum posts to find out the potential issues.

Can somebody confirm if the system works (after resetting the project)?

Yes, it's working fine. TY.

Just a thought, but this MAY effect why some are seeing this and some aren't. I've got my stats exported (there was an option for hiding this on this project wasn't there? Willy mentioned it for some projects), with BOINCstats saving the data tied to one's cross project ID. When one attaches to a project, a ID is issued, but BOINCstats takes care of the reversion back to a static ID so stats can be maintained cross project. If we're exporting and have the stats on the stat sites already, it should maintain? Unless it lists as a new project for purposes of stat exports that is?

Naturally for this to work, one would need to attach existing account, and use identical passwords, as a hash on the password is part of the identifier for BOINCstats as I remember Willy explaining how he maintains the stat service...

---

I've lost my statistics in the local BOINC manager. I monitor these. This is frustrating. I wish I hadn't bothered. I also lost all running work units. What happens if I don't bother making this change to https on my other machines?

If projects make these changes then surely they should provide detailed step by step instructions as to how to achieve the change without affecting this type of thing. As a matter of courtesy, if for no other reason.

We shouldn't have to read through forum posts to find out the potential issues.

The instructions are a few posts below yours. I'll save you the exertion of scrolling down:
https://www.gpugrid.net/forum_thread.php?id=5124&nowrap=true#54906

Yep, I have had files download and complete since the 20th, given I only started GPUGRID after that date.

I got the same issue as well, it's not downloading any of the jobs with the "Project backoff" message since the 21st.
https://www.gpugrid.net/result.php?resultid=25072076

I've disabled the project for now in Boinc until this issue might be fixed.

The issue is fixed. They were faulty jobs, unrelated to the global HTTP --> HTTPS issue. Just abort the task that won't download, and get a new one.

@Aurum Thank you for your response, which I presume (?) was not intended to come across as anything other than helpful, although it could be taken, rightly or wrongly, to imply that I was too lazy to go through forum posts.

Just to clarify, then: the point I was making was that we get a message within BOINC Manager telling us to remove and re-attach the project, without any reference to searching forums for what may happen or what actually did happen. I lost my statistics - that was not even mentioned in messages within BOINC Manager as a possibility. The projects can post messages within BOINC Manager and the message could include refernece to the risks of making a chnage and how to mitigate. Even the link to the forum post did not say that there was any risk in doing this. As I said we should not have to search through a whole plethora of forum posts to find out that there is a risk, or how to avoid it.

I volunteer my computer time and I pay extra for the electricity to run my computers longer and at greater overhead to help the various projects. As a courtesy, I reasonably expect that changes are properly trialed before giving them to me to alpha test, or at least for it to be made clear that I am alpha testing a change when I'm asked to make the change.

If any of the above seems unreasonable on my part, then we have different values, and so let's not fall out over this and just recognise that each of us has a legitimacy in our respective viewpoints.

unfortunately I don't have a clue as to what you are asking me to do. I am very inexperienced on this platform
bill

Thanks very much Richard Haselgrove-

The issue is fixed. They were faulty jobs, unrelated to the global HTTP --> HTTPS issue. Just abort the task that won't download, and get a new one.

Just a 'heads up' for y'all.

I had to exit the BOINC manager (stop processes) to completely clear the bad tasks from the download cue after aborting them. It kept spitting out this routine- "some download is stalled". On one machine it had to be reloaded twice because I didn't give the server time to clear the aborted downloads and they showed up again. Be sure to wait a bit before starting BOINC back up.

This might deserve a courtesy notice, no?

unfortunately I don't have a clue as to what you are asking me to do. I am very inexperienced on this platform
bill

Bill, your computer does not show a GPU. There is only work here for CUDA compatible graphics processors. See this post-
https://www.gpugrid.net/forum_thread.php?id=5124&nowrap=true#54891
There is no CPU-only work here.

There is virus research going at Folding@home which you will be able to benefit with your machine.
https://foldingathome.org/

There is currently a problem with a number of BOINC projects that have switched to https downloads and uploads - those downloads and uploads are blocked, at least for Windows users.

The problem is due to an expired entry in the ca-bundle.crt file that's part of BOINC.

You may need to create a few more workunits to check for this problem.

For users who can't edit that file properly, this is likely to require a new version of BOINC containing an updated version of that file.

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14006

https://boinc.berkeley.edu/forum_thread.php?id=13758&sort=5