Greetings,
I am trying to use COTVNC to connect from my Mac OS X 10.2.4
laptop to a Windows XP desktop. I'm running COTVNC 1.3.6 on
the Mac, and RealVNC server 3.3.6 on the Windows machine.
When I try to initiate the connection, COTVNC tells me:
Terminate Connection
ZlibHex unknown subencoding 23 encountered
Peter R. Wood
2003-02-18
Logged In: YES
user_id=40562
Additional comment: I can see that on the remote computer it is registering (it is across the room from me, for testing purposes). When COTVNC first makes the connection, I see a large black window, and on the other computer I can see the pointer moving around if I move the mouse on my local computer. But before drawing anything on the screen, the window disappears and I get a message similar to the one I describe above. Subencoding "number" differs each time (not always 23).
Peter R. Wood
2003-02-18
Logged In: YES
user_id=40562
More Info:
Did a little fiddling, and discovered that the problem occurs when I have ZRLE enabled. I have all the other options enabled except for ZRLE. When I enable ZRLE and try to connect, I get the error.
Peter R. Wood
2003-02-18
Logged In: YES
user_id=40562
p.s. This is the same bug as 684338.
Jason Harris
2003-02-19
Logged In: YES
user_id=351330
I'll check this out next time I dig into Chicken. I
probably just broke something while I was tweaking
perfomance and memory leaks for last release.
Jason Harris
2003-02-19
Glen Scott
2003-03-19
Logged In: YES
user_id=370885
I received this error message when trying to connect to
RealVNC 3.3.7 running on a Windows 98 server. I don't know
if this is a limitation of the client or the server.
Anyway, to get around this problem, go into the Profiles
menu and make sure the following encoding options are set to
"NO":
Zlib
ZRLE
ZlibHex
HexTile
Jason Harris
2003-04-23
Logged In: YES
user_id=351330
I've done some checking on this and it appears that RealVNC on Windows
(version 3.3.7) is sending illegal values for the ZRLE pixel subencoding. I
think it'll be easy to hack Chicken so it's not a problem, I just need a bit
more time connected to a Windows box for testing.
In the meantime, it appears from my testing that you can work around this
by changing RFB-Pixelformat in your profile to 8-bit. If you do this, you can
keep all of the encoding enabled. This is good idea regardless, because it
dramatically speeds up interaction with the remote machine.
Hopefully I'll have a fix in a few days.
Kirk Beitz
2003-08-11
Logged In: YES
user_id=836015
don't know if there's any movement on this, but i've
encountered this as well (except using RealVNC server 3.3.7
& getting subencoding 127 instead of 23).
i've already backed out to CotVNC 1.3.1 to solve the problem
for myself. any comment on whether it would be better to
stick with 1.3.1 or to move on to 1.3.6 and use the
workaround mentioned in the comment of smeger_2003-04-23?
Jason Harris
2003-08-11
Logged In: YES
user_id=351330
Quickie update - fixing this is _not_ trivial since it seems
to be an issue with RealVNC adding their own twist to the
VNC spec rather than something wrong in Chicken. It's not
insurmountable, of course, but I don't get much time to work
on Chicken, so it's taking a long time to fix since it
involves figuring out what the hell the RealVNC people are
trying to do.
To answer johndoe_sf's question, I'd recommend using Chicken
1.3.6 and turning off the various zlib encodings rather than
using Chicken 1.3.1. 1.3.6 fixed lots of other things that
were issues in 1.3.1.
In fact, if you have the know-how, you should probably be
running the CVS version as it's stable and has a few new
features. All that's holding back a public release from CVS
is this zlib issue.
Matt Dittrich
2003-12-10
Logged In: YES
user_id=898308
Just to add another datapoint, I get this same error (which is
remedied by using the suggested workaround) when connecting
to a VNC server running on Solaris. Here's part of the server
log, so you can tell what server I'm running:
10/12/03 07:57:07 Xvnc version 3.3.4 - built Sep
20 2002 15:28:59
10/12/03 07:57:07 Copyright (C) 2002 RealVNC Ltd.
10/12/03 07:57:07 Copyright (C) 1994-2000 AT&T Laboratories
Cambridge.
10/12/03 07:57:07 Protocol version supported 3.3
Good luck nailing this down....