There is a major difference between SETI Driver and SETI Stash.  SETI Driver
runs N+1 instances of the CLI at the same time.  N is the Maximum Processes
plus one more for the transmit session.  SETIStash appears to only run one
instance.  Back in 2000, some SETI Driver users ran into video systems that
didn't properly handle multiple, simultaneous, hidden command windows.  This
isn't an issue with SETIStash since it only hides one command window at a
time.  This is also why a multi-processor system requires multiple instances
of SETI Stash to process more than one WU at a time but only a single
instance of SETI Driver in the same configuration.

This gives me a thought - it's possible this problem is still there and is
actually a timing problem with the CLI starting and stopping too fast for
some drivers.  I'll see if I can improve the transmit loop delay to give the
Windows GDI a chance to stabilize before starting the next transmit.

Mike.

"Bill Langley" <astrologynut@mailinator.com> wrote in message
news:f974508c.0406070431.44482ee1@posting.google.com...

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:<1VMwc.23984$Tn6.7895@newsread1.news.pas.earthlink.net>...

Also, if you don't like SETI Driver, I'll refund your $0.00 you
paid for it.  So delete it from your system and use a different
caching program.  I suspect you'll have the same problem with most
caching programs that manage the SETI CLI program.

Bullshit.  I had exactly the same freeze with SETIdriver in 2000.
After searching around I found SETIStash - I still use it today.
That's 3.5 years of ZERO problems.