Forum Replies Created
-
Posts
-
Follow-up: we resolved a resource leak bug affecting Mac OS X, all versions, that MAY have caused your problem.
For sure it solves this crash:
https://www.nomachine.com/TR12K04134
We can’t be sure it also solves your problem. There is the theoretical possibility it does, since, after a while, the server started to behave inconsistently. Anyway we were able to reproduce it here only once and since updating the code we have not reproduced it anymore, so there is some hope. Another user experiencing the same problem received the fix yesterday. He has not provided his feedback yet. The new code should ship as part of the 4.1 on next Monday.
Dallas,
I’m sorry but it looks like the physical display on the server doesn’t support such resolution. There is little you can do to change that. I suggest you check if there is an updated video card driver. After all 1920×1080 is quite common these days. Otherwise you should try the Workstation version. The Workstation version will create a virtual desktop (as in the 3) that can be set to the resolution of the client, regardless such resolution is supported or not by the graphic card on the server.
Interesting. Thanks a lot for your offer ;-).
We’ll get in contact. I’m not sure yet how cooperation can be organized, but there are definitely a lot of things we can work on together.
The explanation is simple: these keyboard shortcuts had to be reorganized, be tied to the display action icons shown at the bottom of the player window and complemented with a panel letting the user selectively enable and disable them. This is because many users complained in the past that the keyboard shortcuts interfered with other shortcuts used by the host or remote environment. Since the configuration panel is not ready, the shortcuts cannot be disabled and thus the decision was taken to not enable them, hurting people like you that were used to this handy feature. My apologies. I hope it will be of relief to know that work on this configuration panel has resumed and the shortcuts will be back soon.
Quick follow-up. This report rang a bell, since it was the second specifically targeting Maverick and because in both cases there was no indication in the logs that may signal a network problem. Hence we put people on trying until it could be reproduced. And it was reproduced. The problem is that it is reproduced randomly and very rarely, here and at another customer’s site, only after many hours the session is running. On the other hand, when the system enters in such state, the problem starts to appear regularly, after every few minutes.
Since it is not easy to reproduce (it can be a combination of network jitter and some other condition, tied or not to the fact it is Mac and specifically Maverick), we would be extremely grateful if you or other people would be so kind to help us finding the bug, by running a version of the software with logs enabled. Let us know if you are interested.
As soon as VP9 will be ready ;-). VP9, at the moment, doesn’t support one-pass encoding (and so even less can encode in real-time):
https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/alfjBJLIA3g
Note also that, for a remote display system, the encoding speed is much more important than the bandwidth usage. You can compensate for the lack of bandwidth in a number of ways. Encoding speed is a different kettle of fish. It’s a losing battle if the encoder takes 100ms to complete a frame. We have customers happily using MJPEG rather than VP8 or h264 because it is 2x faster than the fastest video encoder. MJPEG can easily saturate a gigabit LAN, but this is hardly a problem if you are on a gigabit LAN. Add to this that NoMachine must be able to support multiple user sessions running at the same time and you can see by yourself how speed is crucial. But this won’t be a problem for long. In few years from now all encoding will run on silicon, including VP9.
P.S.: NoMachine can use different streams at the same time. We have evaluated using VP9 for the frame refinements, since the visual quality of VP9 frames is vastly superior to VP8 and these refinements can be computed when the CPU is idle. At the moment it’s hard to say if this would bring a real improvement compared to a lossless refinement that can be computed and transferred in the same amount of time.
Problem found and fixed ;-). Hold on, guys. We are collecting more fixes and testing everything. The new build should be out before tonight. Don’t forget to use the automatic updates to get the changes and let us know if everything worked ;-). This is another important feature we are keeping in Beta state until we get enough reports.
The client and server keep exchanging ping packets every 5 seconds. If no reply is received in 10 seconds, the client or server will print a warning in the session log. This warning has the form “No data received since…”. If you don’t see these logs, this means that client and server are communicating fine and the network is not the problem. Additionally, when no communication is possible, you should see the client screen ghosting until the communication is restored. If the duration of the freeze is shorter than 10 second, though, you won’t see anything in the logs. But this doesn’t mean that a freeze of 1 or 2 seconds is less annoying. What we want to rule out is that it is a NoMachine problem and not a network problem. If you see the logs, it’s for sure a network problem. If you don’t see the logs, it may be still a network problem but of a different kind, involving the available bandwidth.
Consider that the quality of the link is extrememly important for this kind of applications. It is not a matter of bandwidth (every residential customer having a ADSL link has enough bandwidth to run NoMachine comfortably) and not even latency (although the lowest it is, the best will be the user experience, with also a round-trip time >50 ms becoming noticeable). For quality of the link I mean the ability of the ISP to give to all users a equal share of the network, something current ISPs are very bad at doing. So all it takes is a user on the same network segment that starts a bittorrent download to cause a network congestion and packet retransmission that can take seconds to settle down.
We never investigated this, really, due to lack of time, but what chances are that the NoMachine server for Linux can work using the Linux compatibility layer?
http://www.freebsd.org/doc/handbook/linuxemu.html
If most binaries work (as I expect) adding FreeBSD support as if it was just another Linux distribution would be at easily feasible. This would at least open NoMachine to the fine BSD crowd. I wouldn’t mind performance. The underlaying NX software is very POSIX standard and, as you certainly know, Linux executables work on top of this BSD compatibility at their full speed.
When I turned off the Windows firewall on the local machine it seemed to connect, but the connection was really, really slow.
You said that it reports different errors when the connection fails. If the connection is blocked by the firewall it should always fail with “connection timeout” or, less commonly, with a “I/O error”, if the firewall is accepting and then closing the connection, but always in the same way. Please confirm that this is the case. Also: either the firewall is off or it is on. If it is on and NoMachine can connect, I presume the firewall is not working very well, that may be unlikely. NoMachine, at setup, opens the ports it is using on the firewall. Either opening the ports worked or not worked. I don’t think the firewall can let the connection succeed at random. But it can be that all connection succeeded, and later the sessions failed for some other NoMachine problem. In this case the firewall is not the culprit.
About the slowness, it can be caused by the use of UDP on a extremely congested network or the VPN software slowing down UDP to prioritize other traffic. Are you connecting the two machines using the VPN? Try to disable UDP going in the connection settings, Edit -> Advanced -> set “Use UDP” off. Also, be sure the machine can connect and the connection works fine on the LAN before adding the VPN to the game.
Since I can’t get beyond the login screen, I have no way of knowing.
You can log in on the physical screen, then connect later, after you have gone past the login.
We were able to reproduce this input bug in the login screen. There is another important bug having to do with Active Directory accounts. We hope to be able to release both fixes shortly.
Hi,
this is a complex topic. In many years of experience, and having had the chance of studying in detail practically all the remote display systems that have been ever designed, I can say that this is one of those “must have” features, one that can make the difference between a “yes” or a “no” to a product, that in reality very few user care and even less use. The problem is that displaying a single window on a remote desktop is 5% of the problem. The rest is integration with the client environment, all sort of interface issues and huge cross-platform inconsistencies that even systems that were designed with that explicit goal since the beginning, like the X-Window system, were never able to implement well. Add to this the fact that applications are progressively migrating toward a full-screen interface, influenced by the simplicity of the mobile world and the fact that browsers are pushing this all-screen, “tabbed” behavior, because studies show that users concentrate on a single task at a time. This without counting the big-screen Internet-enabled TVs and the “computer in the living room”. I don’t want to rule out the possibility, but it seems to me that the stacked window interface has a dark future. We look with more interest to some attempts that have been done recently to “merge” different worlds, without necessarily thinking in terms of “windows”.
Hi Dallas,
remember that when accessing the physical X display on the server machine, you have to modify the settings in the control panel of the server. Changing the X server resolution of the physical display (f.e. :0) normally requires changing the Xorg.conf file, selecting the graphic driver, selecting the applicable acceleration methods. This is under responsibility of the Linux distribution or the configuration software provided with the OS. Virtual desktop created by NoMachine are under our exclusive control and thus don’t have similar limitations.
See also this:
https://www.nomachine.com/forums/forums/topic/single-server-monitor-multiple-client-monitor#post-883
OK, very clear. We have a preliminary design that should commend these and the other relevant cases.
Do you want to disable it on the server or on the client?
If you want to disable it on the client, just shut down the server and tell NoMachine to never start it at boot up. If you want to disable it on the server, this was intended as a security measure, so that user know that the server is running. Due to big demand, we decided to add the possibility to hide the NoMachine icon until a remote user actually connects. AFAIK this is under development.