Re: .92b1 problems

Bill Woodland (wcw@bga.com)
Wed, 21 May 1997 21:13:01 -0500


At 04:54 PM 5/21/97 PDT, Charles Rasnic wrote:
>Installed win95 version 92b1 Cuseeme. The following is a list of bugs that=
I=20
>found.
>
>1. If you get a connection time out, you must reboot. You will get a
>message that the software can't connect to xxx.xxx.xxx.xxx untill you
reboot.=20
>Closing the application or reconnecting with the host will not free up the=
=20
>driver.
>
>2. If you can't connect on the first try, and get a message back that the
Ref is=20
>full, you must try to connect, then stop the attempt and start the attempt
again=20
>to get it to actually try.

I've seen this, too, but thot it might have to do with buffering. I
haven't been able to reproduce this repeatedly.

>
>3.The connect button goes gray and won't restore in some instances.
>
>4. In some instances the software turns off the send video and won't
restore in=20
>the phone book. It is unchecked in the pull down menu.

This bug has been fixed in 92b2. It sometimes would connect you as a
sender when yo told it not to transmit, and the other end could open your
video window, but all they got was a grey box. I'm not sure when Steve
will release the 92b2 version, but I think it will be pretty soon.

>
>5. On certain Refs the software hangs and won't disconnect.
>
>6. You get a lot of Connection time outs, no way to set the option. This
happens=20
>even on empty, unlimited Refs.

Your other problems are probably due to buffering, or your settings are too
high. Keep in mind that if your modem doesn't TRUELY conenct at 28.8, you
can't receive 28kbps. My Motorola modem regularly connects at 24000, but
sometimes at 26400, so keep your eye on it.

Buffering info that I sent out last week:

>I've noticed the same problem lately. Here's some real good techie info
>Steve sent me when I was helping test out this version (slightly edited):
>
>>There are some behind the scenes improvements in the protocol. =20
>>
>>There are 2 new stats in the Info Window: "Link Loss" and "Link Response".
>>Link Loss is the % of bytes being dropped on the _link_ (only to and from
>>the Refl). Link Response is the number of seconds is takes for a rate
>>control/reply packet to get sent to the Refl, processed, and sent back,=
and
>>can be used as an indication of how much buffering is going on, link=
speed,
>>or how thrashed the Refl is. The Refl must be Link Rate Control capable,=
or
>>N/A will appear. =20
>>
>>In the cu-seeme.ini file, you'll see:
>>
>>Disconnect Duration=3D (default is 8)
>>Lock Out on Disconnect=3D (default is 1)
>>Lock Out Duration=3D (default is 15)
>>
>>Disconnect Duration: the number of seconds that must go by with no=
"connect"
>>or "keep-alive" packets coming in the door. This disconnection method is
>>used in the absence of a disconnect handshake.
>>
>>Lock Out on Disconnect: If set to 1, the "Lock Out" feature will be used
>>after a disconnect process is complete. If set to 0, the "Lock Out"=
feature
>>will not be used. I prefer not to use the Lock Out feature, as it makes=
my
>>testing quicker, and I have good links; but most modem users will want it.=
=20
>>
>>Lock Out Duration: Number of seconds the Lock Out feature is in effect,=
if
>>enabled. =20
>>
>>I feel it is better to have v32X not tell the user it is disconnected,=
until
>>it really is; and so have built it that way.
>
>If the ref you're on doesn't support Link Rate Control, try lowering the
>Disconnect Duration, but don't be surprised if this makes you reconnect to
>the same ref.
>
>If the ref you're on supports the Link Rate Control, you might try
>adjusting the value of the Lock Out Duration down to 10, or even 5, but
>this may also cause you MORE trouble than it solves. Adjust with caution.
>Use Notepad or similar to edit the \windows\cu-seeme.ini file.
>

Bill Woodland (Squeek =A9) PC questions only, please.
URL:http://cu-seeme.cornell.edu/~WCW
CU-SeeMe Unsubscribe? Details at http://cu-seeme.cornell.edu/listinfo.html