SETISpy

SETISpy has nothing to do with performance of your SETI client, or
connecting to SETI, or your SETI server statistics. Having it in the same
folder is fine.

--
Mike Bader 99.920%
Join our International team Spot_E.T.
http://www.setiathome.us

No of SETI units returned: 21978
Processing time: 41 years, 184 days, 13 hours.
(Total hours: 363589)


"Team Babtrek" wrote in message
...
Hey all!
Got a question about using SETISpy... what's the best setup (if there is
such a
thing)?
I've got mine tucked away in a folder along with the CLI 3.03 (heard it
was
faster and it seems to be). One thing I was mainly wondering about is the
configuration for the update server... what are the settings that work for
everyone out there? I've got this nagging feeling that mine are wrong
somehow
and its affecting my WUs being sent back and not getting credit for them.
Anyone out there have any suggestions as to why I wouldn't be getting
credit
for my WUs? I've been sending them back everytime one finishes, but I
haven't
gotten credit since the beginning of August.
Any help would be greatly appreciated!


Need people for Team Babtrek. Join if interested.
Computer:
IBM E2N Aptiva
266MHz AMD-K6/2
128Megs RAM
4Gig Hard Drive
2 Megs Video RAM
Win98SE

SETISpy has nothing to do with performance of your SETI client, or
connecting to SETI, or your SETI server statistics. Having it in the same
folder is fine.

--
Mike Bader 99.920%
Join our International team Spot_E.T.
http://www.setiathome.us

No of SETI units returned: 21978
Processing time: 41 years, 184 days, 13 hours.
(Total hours: 363589)


"Team Babtrek" wrote in message
...
Hey all!
Got a question about using SETISpy... what's the best setup (if there is
such a
thing)?
I've got mine tucked away in a folder along with the CLI 3.03 (heard it
was
faster and it seems to be). One thing I was mainly wondering about is the
configuration for the update server... what are the settings that work for
everyone out there? I've got this nagging feeling that mine are wrong
somehow
and its affecting my WUs being sent back and not getting credit for them.
Anyone out there have any suggestions as to why I wouldn't be getting
credit
for my WUs? I've been sending them back everytime one finishes, but I
haven't
gotten credit since the beginning of August.
Any help would be greatly appreciated!


Need people for Team Babtrek. Join if interested.
Computer:
IBM E2N Aptiva
266MHz AMD-K6/2
128Megs RAM
4Gig Hard Drive
2 Megs Video RAM
Win98SE

TB,

I think it's best to give SETI Spy it's own home. What I do is include
in my per-user "Startup" folder a shortcut for launching Seti Spy and
set the "Start in:" field of that shortcut to the directory in which
SETI@home is installed and where it keeps its operating files, which
are what SETI Spy examines to produce its displays.

Randall Schulz


Team Babtrek wrote:

Hey all! Got a question about using SETISpy... what's the best
setup (if there is such a thing)? I've got mine tucked away in a
folder along with the CLI 3.03 (heard it was faster and it seems to
be). One thing I was mainly wondering about is the configuration
for the update server... what are the settings that work for
everyone out there? I've got this nagging feeling that mine are
wrong somehow and its affecting my WUs being sent back and not
getting credit for them. Anyone out there have any suggestions as
to why I wouldn't be getting credit for my WUs? I've been sending
them back everytime one finishes, but I haven't gotten credit since
the beginning of August. Any help would be greatly appreciated!

...

TB,

I think it's best to give SETI Spy it's own home. What I do is include
in my per-user "Startup" folder a shortcut for launching Seti Spy and
set the "Start in:" field of that shortcut to the directory in which
SETI@home is installed and where it keeps its operating files, which
are what SETI Spy examines to produce its displays.

Randall Schulz


Team Babtrek wrote:

Hey all! Got a question about using SETISpy... what's the best
setup (if there is such a thing)? I've got mine tucked away in a
folder along with the CLI 3.03 (heard it was faster and it seems to
be). One thing I was mainly wondering about is the configuration
for the update server... what are the settings that work for
everyone out there? I've got this nagging feeling that mine are
wrong somehow and its affecting my WUs being sent back and not
getting credit for them. Anyone out there have any suggestions as
to why I wouldn't be getting credit for my WUs? I've been sending
them back everytime one finishes, but I haven't gotten credit since
the beginning of August. Any help would be greatly appreciated!

...

Randall R Schulz wrote:

I think it's best to give SETI Spy it's own home.

best how? it's not like it suffers any from sharing a directory with the
client.
i've always kept them together (well, partly because all instances are
either run from a remote machine or on a ramdisk) with nothing but
excellent results.

rgds,
netcat

Randall R Schulz wrote:

I think it's best to give SETI Spy it's own home.

best how? it's not like it suffers any from sharing a directory with the
client.
i've always kept them together (well, partly because all instances are
either run from a remote machine or on a ramdisk) with nothing but
excellent results.

rgds,
netcat

Netcat,

Best because a program (it's author, really) should not have to
contend with an unknown, uncontrolled environment in which to exist.
SETI Spy has built-in, on-line update. The author cannot really be
expected to contend with extraneous files from other applications
residing in the same directory where it wants to install its own
files.

Likewise for the authors and maintainers of the SETI@home software.
They should not have to accommodate nor coordinate with every separate
piece of related software that a user might deposit in SETI@home's
working directory.

Randall Schulz


netcat wrote:


Randall R Schulz wrote:


I think it's best to give SETI Spy it's own home.


best how? it's not like it suffers any from sharing a directory
with the client. i've always kept them together (well, partly
because all instances are either run from a remote machine or on a
ramdisk) with nothing but excellent results.

rgds, netcat

Netcat,

Best because a program (it's author, really) should not have to
contend with an unknown, uncontrolled environment in which to exist.
SETI Spy has built-in, on-line update. The author cannot really be
expected to contend with extraneous files from other applications
residing in the same directory where it wants to install its own
files.

Likewise for the authors and maintainers of the SETI@home software.
They should not have to accommodate nor coordinate with every separate
piece of related software that a user might deposit in SETI@home's
working directory.

Randall Schulz


netcat wrote:


Randall R Schulz wrote:


I think it's best to give SETI Spy it's own home.


best how? it's not like it suffers any from sharing a directory
with the client. i've always kept them together (well, partly
because all instances are either run from a remote machine or on a
ramdisk) with nothing but excellent results.

rgds, netcat

Randall R Schulz wrote:

Netcat,

Best because a program (it's author, really) should not have to
contend with an unknown, uncontrolled environment in which to exist.
SETI Spy has built-in, on-line update. The author cannot really be
expected to contend with extraneous files from other applications
residing in the same directory where it wants to install its own
files.

generally, that would be a sensible approach with a lot of other
software out there.

OTOH, i have to note that the original setup instructions for SETISpy
clearly state:
"Unzip the contents of the zip file to your SETI@home folder" and
"Please make sure that you unzip to a folder containing the "state.sah"
file." similar info is repeated in the SETISpy FAQ. therefore it is safe
to conclude the author has planned for this environment from the start
and sharing a directory with the working S@h client does not present an
"unknown, uncontrolled environment" for SETISpy.

rgds,
netcat

Randall R Schulz wrote:

Netcat,

Best because a program (it's author, really) should not have to
contend with an unknown, uncontrolled environment in which to exist.
SETI Spy has built-in, on-line update. The author cannot really be
expected to contend with extraneous files from other applications
residing in the same directory where it wants to install its own
files.

generally, that would be a sensible approach with a lot of other
software out there.

OTOH, i have to note that the original setup instructions for SETISpy
clearly state:
"Unzip the contents of the zip file to your SETI@home folder" and
"Please make sure that you unzip to a folder containing the "state.sah"
file." similar info is repeated in the SETISpy FAQ. therefore it is safe
to conclude the author has planned for this environment from the start
and sharing a directory with the working S@h client does not present an
"unknown, uncontrolled environment" for SETISpy.

rgds,
netcat