Using ViewerX version 2.7.7.1 and a RealVNC server, the ViewerX component crashes the program.

It seems that the more data transferred the sooner the crash happens. Stretched or none stretched mode does not have any effect.. both modes crash after a while.

The application I'm using testing is the C# sample without modifications. (well I fixed the encoding to ZRLE)

The application running on the server PC which we need to monitor has a couple of GIF-animations running, which gives datarates of approximately 700 bytes/sec with ZRLE encoding. At this rate the crash happens at about 5-7 minutes. And a lot later if these GIF-animations are disabled.

I tried to add an button to the sample.. with which I call the Refresh - method.. This method actually still works and the Viewer is really updated. The communication also works.. The GetBytesReceived keeps reporting more bytes received even after the screen updating is stopped.

When the Viewer stops updating.. I cannot move the application or minimize/maximize, i.e. anything that could trig a screen-update, will make the application crash immediately.. without any notice actually..

Any Ideas??

I saw there was a similar post in VNC manager bug report.. But I'm not sure that this was really helpful..

Erik Larsen

Systems developer

Payvend Solutions A/S

Hi Erik,
have you tried to use ZLIB encoding? If you haven't could you please give it a try. zlib is the most stable VNC encoding I'm pretty sure that you won't face such troubles as with zrle encoding.


Regards,

I have to consider network performance also.. is ZLIB as low-bandwidth consuming as ZRLE ?

-Erik 

Erik Larsen

Systems developer

Payvend Solutions A/S

ZLIB is the most effective encoding and recommended for WAN connections. ZRLE is less effective and recommended for LAN connections.


Regards,

Well.. it still crashes with ZLIB.. and I don't understand that you say ZLIB is less bandwidth consuming..

I've tried to log the BytesReceived method and for me it seems that this number is increasing at a rate of about 20000 bytes pr. sec with ZLIB and about 190 bytes with ZRLE.. Is it possible to test it like this or is there a reason why this method cannot be used?

-Erik

Erik Larsen

Systems developer

Payvend Solutions A/S