Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
1.1.9.6 (Please use this versions before reporting a bug)
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
1.1.9.6 (Please use this versions before reporting a bug)
All changes and fixes now have been added to 1196.
http://www.uvnc.com/downloads/ultravnc/ ... -1196.html
Only winvnc.exe and vncviewer.exe changed.
There was a nasty part in the code that could crash iexplorer and possible is responsible for other
strange behaviour. Please use this versions before reporting a bug.
http://www.uvnc.com/downloads/ultravnc/ ... -1196.html
Only winvnc.exe and vncviewer.exe changed.
There was a nasty part in the code that could crash iexplorer and possible is responsible for other
strange behaviour. Please use this versions before reporting a bug.
Re: 1.1.9.6 (Please use this versions before reporting a bug
I'm (as so often) confused. You'll skip 1.1.9.5? Or testing with 1.1.9.6 and stable release will be 1.1.9.5 anyway?
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
1.1.9.5 was already to long on the net before this nasty bug was fixed.
Reuploading 1195 doesn't provide the correct test results as i never know if people are using
the old or new version.
1195 is skipped
1196 wil be next update
( release 15 dec, if no othe major issue's popup)
Reuploading 1195 doesn't provide the correct test results as i never know if people are using
the old or new version.
1195 is skipped
1196 wil be next update
( release 15 dec, if no othe major issue's popup)
Re: 1.1.9.6 (Please use this versions before reporting a bug
This absolutely makes sense.1.1.9.5 was already to long on the net before this nasty bug was fixed.
Reuploading 1195 doesn't provide the correct test results as i never know if people are using
the old or new version.
-
- 8
- Posts: 9
- Joined: 2013-07-02 06:55
Re: 1.1.9.6 (Please use this versions before reporting a bug
For information, and report, it seem that x64 files below, under 1.1.9.6 :
- UltraVNC_1_1_9_X64_Setup.exe
- UltraVNC_1_1_9_X64_Addons.exe
indicate 1.1.9.4 version, during the install
Are they ok ?
- UltraVNC_1_1_9_X64_Setup.exe
- UltraVNC_1_1_9_X64_Addons.exe
indicate 1.1.9.4 version, during the install
Are they ok ?
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
addon is 1.1.9.4, no changes were made
setup should be 1.1.9.6.
It's an error in the installer name, forgot to update. Files are OK
file reuploaded
setup should be 1.1.9.6.
It's an error in the installer name, forgot to update. Files are OK
file reuploaded
-
- 8
- Posts: 9
- Joined: 2013-07-02 06:55
Re: 1.1.9.6 (Please use this versions before reporting a bug
setup is ok now.
Thank you Rudi
Thank you Rudi
-
- 8
- Posts: 9
- Joined: 2013-07-02 06:55
Re: 1.1.9.6 (Please use this versions before reporting a bug
For information, and report, it seem that x86 files below, under 1.1.9.6 :
- UltraVNC_1_1_9_X86_Setup.exe
indicate 1.1.9.4 version, after the install, in "About WInVNC" window.
is-it ok ?
- UltraVNC_1_1_9_X86_Setup.exe
indicate 1.1.9.4 version, after the install, in "About WInVNC" window.
is-it ok ?
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
I need to verify all, this isn't correct.
One day i realy need to automate the setup creation, manual copying files for the setup always seems to introduce errors
Thanks for the feedback.
One day i realy need to automate the setup creation, manual copying files for the setup always seems to introduce errors
Thanks for the feedback.
Re: 1.1.9.6 (Please use this versions before reporting a bug
Two suggestions:
Firstly, would it be possible for you to avoid releasing test versions packaged in setup exe's, limiting yourself to producing packages only for stable releases? I get the impression that the majority of UltraVNC users are capable of unpacking ZIP files directly replacing previous binaries; only the technically adept are likely to go for these 'bleeding edge' versions anyhow. I understand that you want to limit the amount of forum help you need to give when novice users make installation mistakes, but you should let other forum users take care of that!
Secondly, I'm good with MSDOS batch scripts so if I can build you a (configurable) script to take care of version checking and other automation, I'd be happy to help!
Firstly, would it be possible for you to avoid releasing test versions packaged in setup exe's, limiting yourself to producing packages only for stable releases? I get the impression that the majority of UltraVNC users are capable of unpacking ZIP files directly replacing previous binaries; only the technically adept are likely to go for these 'bleeding edge' versions anyhow. I understand that you want to limit the amount of forum help you need to give when novice users make installation mistakes, but you should let other forum users take care of that!
Secondly, I'm good with MSDOS batch scripts so if I can build you a (configurable) script to take care of version checking and other automation, I'd be happy to help!
-
- 8
- Posts: 9
- Joined: 2013-07-02 06:55
Re: 1.1.9.6 (Please use this versions before reporting a bug
Report Bug :
- UltraVNC_1_1_9_X86_Setup.exe
Server On Windows Xp SP3, After the upgrade with the last version 1.1.9.6 (last night), CPU usage 100 %
Old version installed before :1.1.9.3
Viewer on Windows Seven 64, with 1.1.9.3 or 1.1.9.6
I'have undergrade server to 1.1.9.3 and all seem ok. (CPU usage 5%)
my 5cents
- UltraVNC_1_1_9_X86_Setup.exe
Server On Windows Xp SP3, After the upgrade with the last version 1.1.9.6 (last night), CPU usage 100 %
Old version installed before :1.1.9.3
Viewer on Windows Seven 64, with 1.1.9.3 or 1.1.9.6
I'have undergrade server to 1.1.9.3 and all seem ok. (CPU usage 5%)
my 5cents
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
Can you pm the ultravnc.ini ( without passwd) so we can do identical tests.
I tried to repeat it on a vmware with xp installed, but winvnc.exe cpu stayed around 5-20%.
Tested with and without hooks.
Was it the winvnc.exe with a high cpu ? Normal winvnc monitor himself and slowdown update speed
when cpu reach 40%.
It's possible that the new presets use more cpu ( auto capture alpha blending when semi transparent is supported), but 100%
looks like a loop.
I tried to repeat it on a vmware with xp installed, but winvnc.exe cpu stayed around 5-20%.
Tested with and without hooks.
Was it the winvnc.exe with a high cpu ? Normal winvnc monitor himself and slowdown update speed
when cpu reach 40%.
It's possible that the new presets use more cpu ( auto capture alpha blending when semi transparent is supported), but 100%
looks like a loop.
-
- 8
- Posts: 9
- Joined: 2013-07-02 06:55
Re: 1.1.9.6 (Please use this versions before reporting a bug
it's doneRudi De Vos wrote:Can you pm the ultravnc.ini ( without passwd) so we can do identical tests.
To be precise, it's not winvnc.exe process what use 100 %, but the global CPU usage that growup to 100 %.Rudi De Vos wrote: I tried to repeat it on a vmware with xp installed, but winvnc.exe cpu stayed around 5-20%.
Tested with and without hooks.
Was it the winvnc.exe with a high cpu ? Normal winvnc monitor himself and slowdown update speed
when cpu reach 40%.
It's possible that the new presets use more cpu ( auto capture alpha blending when semi transparent is supported), but 100%
looks like a loop.
So it's can be interactions with another process, but taskmgr use more with 1.1.9.6 that in 1.1.9.3.
The system is clearly slow with simple 4 opened windows of explorer.
I hope that can help you
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
Tested with your settings...but can't repeat it.
Tested with a single and multi core XP.
In one case i had a 100% cpu, but even after closing uvnc it was still 100%.
high svchost process wich i could trace to an update that was running.
Most people had an issue with 1993 because the fast inputthread switching.
Theoretical this should use mor cpu... but with so many hardware and video cards
performance is unpredictable.
Waiting for more reports, can't find it.
Tested with a single and multi core XP.
In one case i had a 100% cpu, but even after closing uvnc it was still 100%.
high svchost process wich i could trace to an update that was running.
Most people had an issue with 1993 because the fast inputthread switching.
Theoretical this should use mor cpu... but with so many hardware and video cards
performance is unpredictable.
Waiting for more reports, can't find it.
-
- 8
- Posts: 9
- Joined: 2013-07-02 06:55
Re: 1.1.9.6 (Please use this versions before reporting a bug
Ok, i see,
For information, the CPU on Windows Xp SP3 is a AMD Athlon 64 3500+
Wait and see if another report is done.
Thanks you
For information, the CPU on Windows Xp SP3 is a AMD Athlon 64 3500+
Wait and see if another report is done.
Thanks you
Re: 1.1.9.6 (Please use this versions before reporting a bug
Here are some performance results which may be useful. I would post pics, but it's not obvious how... you can check at my server http://theghetto.undo.it/UVNCPerf
Conditions in all cases:
Encoding methods manually switched at random: Tight, Hextile, U2, ZRLE (note: they are in order of increasing memory usage) to observe CPU
All servers use identical config, poll: fullscreen only, CaptureAlphaBlending=1,RemoveWallpaper=1,RemoveAero=0
Wherever mentioned, idle tests all used U2 encoding {EDIT: Encryption used throughout}
Here are the computers used for the tests:
Desktops
CPU: Intel Pentium 4 @ 2.6GHz, GPU: Intel82865G @ 1152x864, OS:NT51_x86 [CPU Usage: 30% with regular sustained spike of 60-70% during total inactivity, e.g.: minimised viewer]
CPU: AMD Athlon 64 x2 3800+ @ 2.0GHz, GPU: nVidia 7950GT @ 1680 x 1050, OS:NT51_x64 [CPU Usage: 8% with no changes or periodicity]
CPU: AMD Athlon 64 x2 3800+ @ 2.0GHz, GPU: nVidia 7950GT @ 1680 x 1050, OS:NT61_x64, Aero Off [CPU Usage: 8% with no changes or periodicity]
CPU: AMD Athlon 64 x2 3800+ @ 2.0GHz, GPU: nVidia 7950GT @ 1680 x 1050, OS:NT61_x64, Aero On [CPU Usage: 10% with no changes or periodicity, dwm complains about a drop in performance and requests a change to Basic]
Laptop
CPU: Intel Atom N270 @ 1.6GHz, GPU: Intel 945 @ 1024 x 600, OS:NT51_x86 [CPU Usage: 6-20% with regular and sustained fluctuation as above but also at a later time produced a flat line of 3-5%!?]
CPU: Intel Atom N270 @ 1.6GHz, GPU: Intel 945 @ 1024 x 600, OS:NT61_x86 [CPU Usage: 5-8% with no changes or periodicity however dwm is going nuts using around 15-20%]
Conclusions:
Switching encoding made no significant difference to CPU usage, just memory - entirely consistent with screen size and encoding method
Windows 7 DWM process isn't pleased about being used in this way. Switching to RemoveAero=1 kills DWM usage to 0% but increases UVNC server usage by a relatively small amount
Intel-based chipsets / video chips under XP perform in an inconsistent manner, but still within the bounds of usability
T
Conditions in all cases:
Encoding methods manually switched at random: Tight, Hextile, U2, ZRLE (note: they are in order of increasing memory usage) to observe CPU
All servers use identical config, poll: fullscreen only, CaptureAlphaBlending=1,RemoveWallpaper=1,RemoveAero=0
Wherever mentioned, idle tests all used U2 encoding {EDIT: Encryption used throughout}
Here are the computers used for the tests:
Desktops
CPU: Intel Pentium 4 @ 2.6GHz, GPU: Intel82865G @ 1152x864, OS:NT51_x86 [CPU Usage: 30% with regular sustained spike of 60-70% during total inactivity, e.g.: minimised viewer]
CPU: AMD Athlon 64 x2 3800+ @ 2.0GHz, GPU: nVidia 7950GT @ 1680 x 1050, OS:NT51_x64 [CPU Usage: 8% with no changes or periodicity]
CPU: AMD Athlon 64 x2 3800+ @ 2.0GHz, GPU: nVidia 7950GT @ 1680 x 1050, OS:NT61_x64, Aero Off [CPU Usage: 8% with no changes or periodicity]
CPU: AMD Athlon 64 x2 3800+ @ 2.0GHz, GPU: nVidia 7950GT @ 1680 x 1050, OS:NT61_x64, Aero On [CPU Usage: 10% with no changes or periodicity, dwm complains about a drop in performance and requests a change to Basic]
Laptop
CPU: Intel Atom N270 @ 1.6GHz, GPU: Intel 945 @ 1024 x 600, OS:NT51_x86 [CPU Usage: 6-20% with regular and sustained fluctuation as above but also at a later time produced a flat line of 3-5%!?]
CPU: Intel Atom N270 @ 1.6GHz, GPU: Intel 945 @ 1024 x 600, OS:NT61_x86 [CPU Usage: 5-8% with no changes or periodicity however dwm is going nuts using around 15-20%]
Conclusions:
Switching encoding made no significant difference to CPU usage, just memory - entirely consistent with screen size and encoding method
Windows 7 DWM process isn't pleased about being used in this way. Switching to RemoveAero=1 kills DWM usage to 0% but increases UVNC server usage by a relatively small amount
Intel-based chipsets / video chips under XP perform in an inconsistent manner, but still within the bounds of usability
T
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
Thanks for the tests...
It's hard to test encoders this way.
A frame ( time to encode + time to encrypt + time to send data + time to decrypt + time to decode)
Using encryption,
hextile ( 1% cpu) + encryption (5%)
zrle (5% cpu) + encryption (1%)
The better you compress the less data need to be encrypted and sended.
VNC try to generate the mosts FPS. If an encoder is faster, it generate more FPS.
If the viewer has processed an update, he ask for the next one. ( viewer pulled speed)
Perhaps i need add some FPS indication in the status window,
it's hard to compare encoders with different speeds.
On idle screens, we slowly decrease the polling frequency and force an update every X seconds.
Spikes could be caused by the forced update on idle.
DWM: To see if the screen changed we need to scan for changes, this is done by copying video to system memory.
This is done several times a second and sometimes cause wdm to go in overdrive.
It's hard to test encoders this way.
A frame ( time to encode + time to encrypt + time to send data + time to decrypt + time to decode)
Using encryption,
hextile ( 1% cpu) + encryption (5%)
zrle (5% cpu) + encryption (1%)
The better you compress the less data need to be encrypted and sended.
VNC try to generate the mosts FPS. If an encoder is faster, it generate more FPS.
If the viewer has processed an update, he ask for the next one. ( viewer pulled speed)
Perhaps i need add some FPS indication in the status window,
it's hard to compare encoders with different speeds.
On idle screens, we slowly decrease the polling frequency and force an update every X seconds.
Spikes could be caused by the forced update on idle.
DWM: To see if the screen changed we need to scan for changes, this is done by copying video to system memory.
This is done several times a second and sometimes cause wdm to go in overdrive.
Re: 1.1.9.6 (Please use this versions before reporting a bug
You also have to take video card driver into account.
I had two machines here where Windows was complaining about perfomance
always after a short period after connecting via UltraVNC and wants to switch
to Basic mode.
Updating the video card driver on both machines (Catalyst 13.4)
solved the problem in both cases.
Regards
grubi.
I had two machines here where Windows was complaining about perfomance
always after a short period after connecting via UltraVNC and wants to switch
to Basic mode.
Updating the video card driver on both machines (Catalyst 13.4)
solved the problem in both cases.
Regards
grubi.
Re: 1.1.9.6 (Please use this versions before reporting a bug
To give a short positive feedback: With 1.1.9.6 our refresh problems are better. The first time since win8 changes the things are getting better and not worse (for us, don't misunderstand it please. We really really appreciate your work). We have a reference server (at customers side) were we normally have to refresh the screen manually. Refresh problems are already there with 1.1.9.6, but much more better. Some changes are recognized after up to 6 seconds, but they are recognized.
Should the viewer also be updated?
Should the viewer also be updated?
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
corrected ( file was the old 1.1.9.3, link behind buitton was wrong)
Thanks for the feedback
Thanks for the feedback
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
Gonna check them again, setup(s) are partly manual generated.
Re: 1.1.9.6 (Please use this versions before reporting a bug
I have installed ChunkVNC_3_3_1 . When i use compiler.exe and create exe files it gives error likeRudi De Vos wrote:All changes and fixes now have been added to 1196.
http://www.uvnc.com/downloads/ultravnc/ ... -1196.html
Only winvnc.exe and vncviewer.exe changed.
There was a nasty part in the code that could crash iexplorer and possible is responsible for other
strange behaviour. Please use this versions before reporting a bug.
---------------------------
WinVNC Warning
---------------------------
WARNING : Running WinVNC without setting a password is a dangerous security risk!
Until you set a password, WinVNC will not accept incoming connections.
---------------------------
OK
---------------------------
I have replaced winvnc.exe of old version with latest version 1.1.9.6 in application path of ChunkVNC_3_3_1 . Why this error comes when compiling using comiler.exe. in compiler.exe i have filled WAN,viewer,server port and Instantsupport password properly while using compiler.exe.
So please help me
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
Chunk is maintained by someone else, you gonna have better luck posting it there.
VNC give this error when winvnc.exe is started and the ultravnc.ini doesn't have a passwd.
If you can preset the ultravnc.ini before running the compiler you don't have the warning.
VNC give this error when winvnc.exe is started and the ultravnc.ini doesn't have a passwd.
If you can preset the ultravnc.ini before running the compiler you don't have the warning.
Re: 1.1.9.6 (Please use this versions before reporting a bug
Hello, where can I download the bin of addons for 32/64?
Thanks
Thanks
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
A link to the addons is on the same webpage as the link to the setup.
The addons didn't change.
Uvnc 1196 use addons 119X.
The addons didn't change.
Uvnc 1196 use addons 119X.
Re: 1.1.9.6 (Please use this versions before reporting a bug
Ok, but I saw in http://www.uvnc.eu/1196/ the date of the msi addons package was december, and I saw one post of yours in 1194 saying "Addons64 updated , pointer error" also
Thanks
Thanks
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact:
Re: 1.1.9.6 (Please use this versions before reporting a bug
To be sure i will check again that the latest version (src) is also in the 199x folder.
Else i just copy the december version to both folders.
Else i just copy the december version to both folders.
Re: 1.1.9.6 (Please use this versions before reporting a bug
When i build winvnc.exe from the source code i get below error
Error 2 error PRJ0019: A tool returned an error code from "nasm -fwin32 -DWIN32 -DMSVC -Iwin/ -Isimd/ -o "D:\UltraVNC\winvnc\DebugLib-Static/jsimdcpu.obj" "simd/jsimdcpu.asm"" libjpeg-turbo-win libjpeg-turbo-win
Error 66 fatal error LNK1104: cannot open file '..\debuglib-static\libjpeg-turbo-win-static-d.lib' winvnc winvnc
Why this comes? How to solve these errors
Error 2 error PRJ0019: A tool returned an error code from "nasm -fwin32 -DWIN32 -DMSVC -Iwin/ -Isimd/ -o "D:\UltraVNC\winvnc\DebugLib-Static/jsimdcpu.obj" "simd/jsimdcpu.asm"" libjpeg-turbo-win libjpeg-turbo-win
Error 66 fatal error LNK1104: cannot open file '..\debuglib-static\libjpeg-turbo-win-static-d.lib' winvnc winvnc
Why this comes? How to solve these errors
- Rudi De Vos
- Admin & Developer
- Posts: 6864
- Joined: 2004-04-23 10:21
- Contact: