'Attaching' is a multi-stage process. You go through several stages, the first one being to locate and download the 'Master file'. SETI is a live project (as we verify by posting here), and this stage will succeed - it fails when a project suffers a major crash of its single server.

The next stage is to contact the 'Scheduler', to introduce your new computer to the database, get assigned a new Host ID, note the machine's ownership and team affiliation, and so on. This will currently fail, because SETI's scheduling server doesn't currently have a scheduler. End of.

So you'll never make it to stage three, when an initial test workload of 1 second is requested to confirm that everything is working normally at both ends. It isn't.

'Attaching' is a multi-stage process. You go through several stages, the first one being to locate and download the 'Master file'. SETI is a live project (as we verify by posting here), and this stage will succeed - it fails when a project suffers a major crash of its single server.

The next stage is to contact the 'Scheduler', to introduce your new computer to the database, get assigned a new Host ID, note the machine's ownership and team affiliation, and so on. This will currently fail, because SETI's scheduling server doesn't currently have a scheduler. End of.

So you'll never make it to stage three, when an initial test workload of 1 second is requested to confirm that everything is working normally at both ends. It isn't.

Thanks, that explains it. I'm stuck on stage 2, and thought manual intervention was required, because I use Boinctasks rather than looking at 7 seperate Boinc managers. Boinctasks has no ability to remove (detach) a project until it's properly attached. I just removed them all manually except the Android which is running a "Boinc for Boinctasks" cut-down client with virtually no interface. That one will have to remain stuck forever, or hopefully do something if they restart SETI on the same address. I guess if it's a different address, it would treat that as a seperate project and I could still attach to it.

'Attaching' is a multi-stage process. You go through several stages, the first one being to locate and download the 'Master file'. SETI is a live project (as we verify by posting here), and this stage will succeed - it fails when a project suffers a major crash of its single server.

The next stage is to contact the 'Scheduler', to introduce your new computer to the database, get assigned a new Host ID, note the machine's ownership and team affiliation, and so on. This will currently fail, because SETI's scheduling server doesn't currently have a scheduler. End of.

So you'll never make it to stage three, when an initial test workload of 1 second is requested to confirm that everything is working normally at both ends. It isn't.

Thanks, Richard. This helps explain a lot. This also got me thinking that the BOINC code could make use of an enhancement, such as read-only feature (set by an admin):
I.e., The scheduler service running in read-only mode would only respond with computer ID that already exist; new computers would be given an error, told to detach, etc. Obviously, work requests would also return zero.

Not sure how difficult such an enhancement would be... I guess the idea is to keep the task/computer database read-only (to not affect the analysis/research) but still allow existing computers to have statistics/reporting on their clients.