Have 3 project Seti/Climate/Rosetta,
Seti or Climate Cross-project ID is equal,
Rosetta different.
It is possible equal Cross-project ID for all the 3 project????

---

If you have all three on the same host, they _should_ sync. If you have SETI & Rosetta on one, SETI & CPDN on another, and Rosetta & CPDN on a third, it is _possible_ that they'll "toggle" back and forth - but even then, they _should_ eventually sync.

It looks like you're not doing SETI at the moment; you may need to let it do some work and connect to the servers, just a couple of WUs, to help the syncing.

If all else fails, you can edit the xml files in the BOINC folder and force all the CPIDs to match - make a backup first!

---

You also have to make sure your E-Mail Address is the same at all your Projects. It may take some time like a month or more for them to sync with each other.

Editing the xml files doesn't seem to work, at least for me anyway. I've had the same problem ever since I joined the BOINC Projects. Half my PC's want to show 1 ID & the other Half another ID. I've tried editing the XML Files but they just go back to what they were before.

I have noticed though that a few PC's of mine have jumped to the proper ID the last few days, so maybe they all will eventually ... :)

This seems to work for me.

1) Before my first attach to a new project, have a host attached to the existing project with the cpid I want to keep.

2) Create a new account either on the website of the new project.

3) Attach the client with the existing project to the new project.

This has always resulted in the old cpid being carried forward - my guess is that the important thing is that the first attach to the project is from a client that is already running work - the server then does the sensible thing and adopts the existing cpid.

This is important for me, as if my cpid ever changes again, I will lose my Pirates credits. Pirates is a retired project, so will never update its cpid again.

If my method is not guranteed to work in all cases, I would be glad if the BOINC people could address this point and define at least one method that is guaranteed to preserve old cpid's and thus preserve out links with retired stats.

River~~

---

If my method is not guranteed to work in all cases, I would be glad if the BOINC people could address this point and define at least one method that is guaranteed to preserve old cpid's and thus preserve out links with retired stats.

I don't think _all_ of the stats sites even use the CPID; BOINC Synergy for example uses your actual project ID# for each project, or at least that's what they ask for when you set up your sig. I agree there needs to be a way to manually "force" a CPID change at a site, that would make life a lot easier...

---

What happens to the CPID depends upon the version of the BOINC daemon. If the version is old enough, it was using the numerically largest CPID as the selected CPID. Newer clients use the CPID from the project with the earliest join date on that computer - it does not keep track of a CPID and date that was assigned on a computer with a project with a project with an earlier join date.

So, currently, attaching to a new project with a computer that is already attached to at least one project with the correct CPID before attaching it to any new computers will always synch the CPIDs in short order.

I would like to see the CPID have a date that is transmitted from the client to the server back to the client to indicate the join date that was used for the current CPID.

---

BOINC WIKI

If the version is old enough, it was using the numerically largest CPID as the selected CPID. Newer clients use the CPID from the project with the earliest join date on that computer

From which version, do you happen to recall? Or if you don't know exactly, would you know if 4.45 counts as old or new in this context? (I've some remote win boxes still on 4.45 as it's such a pain to update them)

I would like to see the CPID have a date that is transmitted from the client to the server back to the client to indicate the join date that was used for the current CPID.

Yes, that would be a good cure for the retired project issue unless someone had a very weird history...

---

If the version is old enough, it was using the numerically largest CPID as the selected CPID. Newer clients use the CPID from the project with the earliest join date on that computer

From which version, do you happen to recall? Or if you don't know exactly, would you know if 4.45 counts as old or new in this context? (I've some remote win boxes still on 4.45 as it's such a pain to update them)

I would like to see the CPID have a date that is transmitted from the client to the server back to the client to indicate the join date that was used for the current CPID.

Yes, that would be a good cure for the retired project issue unless someone had a very weird history...

I believe (but I am not quite certain) that 4.45 falls on the new side.

Save the internal CPID from Pirates (if you still have it around) it can be used later during a hand edit to put things back to where you want them to be.

---

BOINC WIKI

Save the internal CPID from Pirates (if you still have it around) it can be used later during a hand edit to put things back to where you want them to be.

Thanks John, that is good advice. So far Ive kept my Pirates CPID on all the other projects, but I hadn't thought to back it up separately.

So yes, I'd better back it up now I've been warned... ;-)