Forum / NoMachine for Windows / NoMachine 4.4.12 black screen connecting from Win 8.1 to Mac OS X Yosemite
Tagged: 4.6.3, black-screen, Mac OS X Yosemite, Windows 8.1
- This topic has 11 replies, 5 voices, and was last updated 9 years, 5 months ago by esotericbyte.
-
AuthorPosts
-
March 11, 2015 at 09:31 #6568shepardroadParticipant
I installed NoMachine 4.4.12 on my Windows 8.1 machine and my Mac OS X Yosemite machine this past weekend. Everything installed without issue on both boxes. I can log into my Win 8.1 box using NoMachine without a problem; however, while I can log into my Mac using NoMachine, I can see that I am controlling the Mac fine, but my virtual display on the Win 8.1 side just shows a black screen.
FWIW–My Windows box is running an AMD Radeon HD 5670, feeding 2 monitors–one via DVI-DVI and the other monitor via DisplayPort-DVI; my Mac is a Macbook Pro 13” running standalone, no external monitors…
Any ideas where to start troubleshooting? On the client (Windows) machine? Or the server (Mac)?
Just let me know what additional info to provide–I am brand new to NoMachine, so any guidance would be appreciated!
Thanks!
Tom
March 13, 2015 at 08:50 #6602BritgirlKeymasterWe aren’t aware of a black screen connecting to Yosemite :-/ from Windows. Can you send us the logs if possible? The article here will help you locate them.
https://www.nomachine.com/AR10K00697
Please send them on to forum[at]nomachine[dot]com making sure you reference your topic.
March 13, 2015 at 09:32 #6603angelus1969ParticipantThis sounds very much like the report I have filed some days ago, but here it concerns 2 Linux (Xubuntu) boxes. The version is the same, earlier versions didn’t have this problem. In the meantime I have found that it works (for awhile) if I restart the nxserver service on the server. Of course this is not a solution, but a temporary patch (I hope).
March 27, 2015 at 14:26 #6751BritgirlKeymaster@angelus1969, your issue should be dealt with separately (send us both client and server side logs)
June 5, 2015 at 09:14 #7387esotericbyteParticipantI am having the same problem and will collect and submit the log for mac shortly.
But NoMachine version may be different.
Windows 8.1 (client) to MacOS 10.10.3 (used remotely)
Windows 8.1 has a 4k display UHD (4 HD screens tiled) but I also tried it with it set to HD and still did not work.
Mac has an HD screen… HD being 1080p
I have included then windows log fines so far but even after shutting down the server in windows management services it would not let me compress the complete set of files.
Attachments:
June 5, 2015 at 09:15 #7390BritgirlKeymasterMay I invite everyone to update their NoMachine installations on both the Windows and Mac hosts? Version 4.6.3 was released a few days back and fixes a number of issues.
June 8, 2015 at 11:36 #7395esotericbyteParticipantNot this one. I have run the utility and am running the current version which is the only one I’ve installed.
Connecting to mac allows cursor movement and keyboard input like synergy .. but not as nicely because of the big empty black window on my PC screen.
Goal is to use Xcode on my mac mini remotely.
If that works with NoMachine, then I’ll also use it on a linux server I’d prefer to set up in the basement or something.
June 8, 2015 at 12:32 #7405BritgirlKeymasterThe logs are from the client. What we need are the logs from the server side, and additionally the .nx directory client side. Please follow the instructions in the article https://www.nomachine.com/AR07K00677. They will possibly be too large to attach here, so you will need to send them to forum[at]nomachine[dot]com.
Thanks
June 11, 2015 at 11:47 #7431esotericbyteParticipantThe windows .nx dir in my user folder was small.
will update with mac server records too
June 12, 2015 at 08:24 #7451esotericbyteParticipantFor mac I’ve created a combined file for server logs and user dir .nx
i did not have time to double check the instructions .. concerned that I’ve not sent configs??
I did not exclude anything and it’s small because there was no recordings / data cache. I did not purge any of the logs because the number and duration of uses has not been great. In fact I do not think I saw them where they were predicted to be by the collection kb article
In some ways this is not shocking because the screen does not have any data on it.
I just had a mac os and or development tools update. I reproduced the problem again following this. I’ve also rebooted windows.
Thanks much for your help ! It would be fantastic if this was a simple to use, and reliable remote access solution!
Attachments:
June 12, 2015 at 14:19 #7469fra81ModeratorLogs show that the server is trying to use the H.264 codec even if it is not available. You should be OK with the workaround of disabling H.264 forcedly. Click on the NoMachine tray icon on the server (on the Mac), then on “Show the server status” -> “Server preferences” -> “Performance” -> “Use a specific display encoding” and select VP8.
We are not able to reproduce this problem in our labs, even when H.264 is not available. So would you be willing to help us in identifying the problem, we would need to gather more logs. Attached is a debug library with verbose logging enabled. It should be placed on server side as per following instructions:
1) sudo /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –shutdown
2) untar and place the attached library in the /Applications/NoMachine.app/Contents/Frameworks/lib directory (make a backup copy of the original)
3) sudo /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –startup
4) reproduce and send us server side logsAttachments:
June 15, 2015 at 09:44 #7476esotericbyteParticipantNo problem. I will collect better logs first, since making it work will create large cache… easier for me in the long run.
Also, that way when I try the fix there will be better logs.
It could be there are simlinks left around to a lib that was removed.
-
AuthorPosts
Closed because the user did not provide further feedback. Please notify us if you confirm that it is resolved or open a new topic if you have the same problem.