So you’re saying that the screen of the machine that you’re actually logged into goes black? Or just that the VNC viewer window goes black? If it’s the latter, which VNC viewer are you using?
I can’t recall ever hearing a report of this behavior before. There are a couple of places you could look to find more information on what is happening: One is in the Console (on the machine running Vine) and look for messages related to the display (it sounds more likely that these would be coming from the system than from Vine). In particular, you might see what pops up in the console after you issue the quit and launch commands. The second thing is if there is a crash, there should be a crash report generated in ~/Library/Logs/CrashReporter/ (~/Library/ is now a hidden folder under Lion, but you can use Go To Folder and type the path). If you find a crash report there for Vine, post it here and we’ll take a look at it.
We don’t have a donation page for Vine, but if you’re ever in the market for a nice VNC Viewer for the Mac, you could always buy copy of Vine Viewer.
Only the VNC viewer window went black. The server machine didn’t have any issues except for the VineServer.app crash.
Steps:
launched VineServer 4 beta
connected from Windows 7 with UltraVNC Viewer 1.0.8.2 using the attached configuration. I changed the Password to “abc”. I don’t use any password, so I don’t know where that data was coming from.
The config uses Tight encoding at 256 colors.
=> VNC worked fine
closed the viewer
started the viewer again
=> immediately closed itself, but server wrote attached VineServer.log
started the viewer again
=> UltraVNC viewer window showed up but was (and stayed) completely black. Mouse and Keyboard input worked. Server wrote this to the log:
2011-09-25 19:26:33.704 OSXvnc-server[6641:2023] Protocol version 3.4
2011-09-25 19:26:33.704 OSXvnc-server[6641:2023] Ignoring minor version mismatch
2011-09-25 19:26:33.801 OSXvnc-server[6641:2023] Pixel format for client 127.0.0.1:
2011-09-25 19:26:33.802 OSXvnc-server[6641:2023] 8 bpp, depth 8
2011-09-25 19:26:33.802 OSXvnc-server[6641:2023] true colour: max r 7 g 7 b 3, shift r 0 g 3 b 6
2011-09-25 19:26:33.803 OSXvnc-server[6641:2023] ENCODING: Tight for client 127.0.0.1
2011-09-25 19:26:33.803 OSXvnc-server[6641:2023] Unknown Encoding Type(ignored): 17 (11)
2011-09-25 19:26:33.804 OSXvnc-server[6641:2023] ULTRA Encoding not supported(ignored): 9 (9)
2011-09-25 19:26:33.804 OSXvnc-server[6641:2023] Using compression level 6 for client 127.0.0.1
2011-09-25 19:26:33.805 OSXvnc-server[6641:2023] Enabling Cursor Shape protocol extension for client 127.0.0.1
2011-09-25 19:26:33.805 OSXvnc-server[6641:2023] Enabling Cursor Position protocol extension for client 127.0.0.1
2011-09-25 19:26:33.806 OSXvnc-server[6641:2023] Using jpeg image quality level 6 for client 127.0.0.1
2011-09-25 19:26:33.806 OSXvnc-server[6641:2023] Unknown Encoding Type(ignored): 4294901766 (FFFF0006)
2011-09-25 19:26:33.807 OSXvnc-server[6641:2023] Enabling LastRect protocol extension for client 127.0.0.1
2011-09-25 19:26:33.807 OSXvnc-server[6641:2023] Enabling Dynamic Desktop Sizing for client 127.0.0.1
2011-09-25 19:26:33.807 OSXvnc-server[6641:2023] Unknown Encoding Type(ignored): 4294901761 (FFFF0001)
2011-09-25 19:26:33.808 OSXvnc-server[6641:2023] Unknown Encoding Type(ignored): 4294934528 (FFFF8000)
2011-09-25 19:26:33.808 OSXvnc-server[6641:2023] Unknown Encoding Type(ignored): 4294934529 (FFFF8001)
2011-09-25 19:26:33.809 OSXvnc-server[6641:2023] Unknown Encoding Type(ignored): 4294934530 (FFFF8002)
2011-09-25 19:26:33.809 OSXvnc-server[6641:2023] Client Connected - Registering Screen Update Notification
OSXvnc-server(6641,0xb030b000) malloc: *** error for object 0xffebeceb: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
OSXvnc-server(6641,0xb030b000) malloc: *** error for object 0xffeff0ef: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
repeated opening/closing of viewer a few times
=> always black viewer screen
Today, I couldn’t reproduce a crash of VineServer.app, but I attached the crash report from last time. I also can’t reproduce the black viewers reliably (sometimes, it just works as expected).
Beta server is running well for me so far on Lion, tho I only installed it today. No problems in terms of reconnecting after disconnecting either
Edit: noticed an issue where occasionally after connecting from a PC (Ultra VNC viewer and Real VNC Viewer) mouse input works fine but keyboard input doesnt work
Vine Server Beta is not working so well. It closes the connection as soon as the window draws. I see the desktop for a split second and then RealVNV closes with an “Unknown Message Type” dialog. MochaVNC on my phone just gets a black screen. Another web based viewer also gets the Unknown Message error. Restarting the machine or server makes no difference. It has work a couple times.
Make sure that you have the built-in screen sharing server turned off (System Preferences > Sharing > Screen Sharing). I’ve just tested all the connection types mentioned in your post and they all work with no issues. The connections were made quickly and there were no disconnects.
10/18/11 8:37:03.386 AM OSXvnc-server: Protocol version 3.8
10/18/11 8:37:03.506 AM OSXvnc-server: Pixel format for client xxx.139.67.130:
10/18/11 8:37:03.507 AM OSXvnc-server: 8 bpp, depth 8
10/18/11 8:37:03.507 AM OSXvnc-server: true colour: max r 3 g 3 b 3, shift r 4 g 2 b 0
10/18/11 8:37:03.508 AM OSXvnc-server: Enabling Cursor Shape protocol extension for client xxx.139.67.130
10/18/11 8:37:03.508 AM OSXvnc-server: Enabling Dynamic Desktop Sizing for client xxx.139.67.130
10/18/11 8:37:03.509 AM OSXvnc-server: ENCODING: ZRLE for client 67.139.67.130
10/18/11 8:37:03.509 AM OSXvnc-server: Client Connected - Registering Screen Update Notification
10/18/11 8:37:03.541 AM OSXvnc-server: rfbProcessClientNormalMessage: read: Connection reset by peer
10/18/11 8:37:03.713 AM OSXvnc-server: rfbSendUpdateBuf: write: Bad file descriptor
10/18/11 8:37:03.725 AM OSXvnc-server: Client xxx.139.67.130 disconnected
10/18/11 8:37:03.725 AM OSXvnc-server: UnRegistering Screen Update Notification - waiting for clients
10/18/11 8:37:03.728 AM OSXvnc-server: Statistics:
10/18/11 8:37:03.729 AM OSXvnc-server: key events received 0, pointer events 1
10/18/11 8:37:03.729 AM OSXvnc-server: framebuffer updates 1, rectangles 2, bytes 171797
10/18/11 8:37:03.729 AM OSXvnc-server: Cursor Shape Updates rectangles 1, bytes 660
10/18/11 8:37:03.730 AM OSXvnc-server: ZRLE rectangles 1, bytes 171137
10/18/11 8:37:03.730 AM OSXvnc-server: raw bytes equivalent 2073612, compression ratio 12.070129
Are you running the beta on 10.6 or 10.7? It doesn’t work on 10.5 or earlier Mac OS X releases.
It seems to be working well for other people who are using it. There are a couple of reported issues, but nothing like you’ve described. As I noted, I connected to the beta running on 10.7 using RealVNC Viewer, MochaVNC, and a browser, just to check that the protocol return value was correct. There seems to be something wrong in your environment – the numbers say that it’s not an inherent problem with the beta.
This morning I tried connecting to the mac over the local network and after about 4 tries it finally did. I was using Chicken of the VNC. It was giving an unknown message error -125.
Using Vine Server 4.0Beta (1109201627) on Mac OS X Server 10.7.2.
Everything is working fine except the System Server when it is started automatically after a reboot instead of a logged in user.
The following errors are logged when I try to connect to the System Server when it was started automatically after a reboot:
11-10-21 11:02:29.241 AM OSXvnc-server: kCGErrorFailure: CGSColorProfileCreateWithColorProfileID: Cannot initialize color profile client
11-10-21 11:02:29.241 AM OSXvnc-server: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
11-10-21 11:02:29.241 AM OSXvnc-server: (ipc/send) invalid destination port: CGSNewConnection cannot get connection port
11-10-21 11:02:29.242 AM OSXvnc-server: (ipc/send) invalid destination port: CGSNewConnection cannot get connection port
11-10-21 11:02:29.242 AM OSXvnc-server: kCGErrorInvalidConnection: CGSGetRegisteredCursorDataSize: Invalid connection
11-10-21 11:02:29.244 AM OSXvnc-server: CGSLookupServerPort: _CGSSessionDeathWatchPort(gSessionPort) returns 268435459
11-10-21 11:02:29.287 AM OSXvnc-server: (ipc/send) invalid destination port: CGSNewConnection cannot get connection port
11-10-21 11:02:29.321 AM OSXvnc-server: (ipc/send) invalid destination port: CGSNewConnection cannot get connection port
11-10-21 11:02:29.327 AM OSXvnc-server: kCGErrorFailure: CGSColorProfileCreateWithColorProfileID: Cannot initialize color profile client
11-10-21 11:02:29.345 AM OSXvnc-server: kCGErrorFailure: CGSColorProfileCreateWithColorProfileID: Cannot initialize color profile client
11-10-21 11:02:29.402 AM ReportCrash: DebugSymbols was unable to start a spotlight query: spotlight is not responding or disabled.
11-10-21 11:02:29.954 AM com.apple.launchd: (VineServer[2318]) Job appears to have crashed: Bus error: 10
11-10-21 11:02:30.018 AM OSXvnc-server: 3891612: (connectAndCheck) Untrusted apps are not allowed to connect to or launch Window Server before login.
11-10-21 11:02:30.018 AM OSXvnc-server: Window Server is not available.
11-10-21 11:02:30.018 AM OSXvnc-server: Window Server is not available.
11-10-21 11:02:30.019 AM OSXvnc-server: CGSCreateEventSourceState: cannot resolve shmem.
11-10-21 11:02:30.124 AM ReportCrash: Saved crash report for OSXvnc-server[2318] version ??? (???) to /Library/Logs/DiagnosticReports/OSXvnc-server_2011-10-21-110230_localhost.crash
I’m wondering if:
11-10-21 11:02:30.018 AM OSXvnc-server: 3891612: (connectAndCheck) Untrusted apps are not allowed to connect to or launch Window Server before login.
I’m having the same problem as macona and Markus Keller on a Mac Mini running Lion Server. Connecting with RealVNC client, I get RFB protocol error: unknown message type 131. Also with the “connection reset by peer” message in the console. If I restart Vine server, I can connect correctly on the first try. It must always be reset before a connection.
If you are not testing with 10.7 Server, you probably aren’t going to track down the issue.
[quote=“clbell”]I’m having the same problem as macona and Markus Keller on a Mac Mini running Lion Server. Connecting with RealVNC client, I get RFB protocol error: unknown message type 131. Also with the “connection reset by peer” message in the console. If I restart Vine server, I can connect correctly on the first try. It must always be reset before a connection.
If you are not testing with 10.7 Server, you probably aren’t going to track down the issue.[/quote]
I have this exact same problem with regular Lion 10.7. It has come to the point that I trained myself to run “killall OSXvnc-server” in a terminal on the host instead of simply closing my VNC viewer window. This makes sure I always connect to a fresh VNC server. When I forgot to do this, or I have to reconnect after an unexpected connection drop, I first SSH to the Mac and run that command. It is less hassle than retrying in vain to connect multiple times in a row.
[quote=“clbell”]I’m having the same problem as macona and Markus Keller on a Mac Mini running Lion Server. Connecting with RealVNC client, I get RFB protocol error: unknown message type 131. Also with the “connection reset by peer” message in the console. If I restart Vine server, I can connect correctly on the first try. It must always be reset before a connection.
If you are not testing with 10.7 Server, you probably aren’t going to track down the issue.[/quote]
Same problem here. 10.7.3 on the Mac, RealVNC on the client-side.
Well, add us to the list, too. Sure, it’s beta. But it’s also been over 7 months. We’re in the process of doing an upgrade from a working 10.6.8 environment with Vine 3.1 to a 10.7 environment with 4.0… and this is going to prevent us from finishing it or we’ll have to try and find an alternative to Vine.
One interesting data point: The bug doesn’t seem to affect all clients equally. So far, I have used:
[list]
[]Linux: TigerVNC 1.1.0
[]Mac: Screen Sharing (vnc:// URL) in 10.6
[]Windows: UltraVNC 1.0.9.6.2
[]Windows: vncviewer 3.3.3 R2 (yeah, OLD)
[/list:u]So far, the only clients that appear affected by the complete inability to connect once this situation occurs are those on Windows. The other clients (Linux and Mac in my case) can connect, even if you have to try 2 or 3 times.
Well, after seeing a reference to the new multi-user features of built-in Mac OS X screen sharing in 10.7 – which had major bugs in earlier releases – I decided to give it a try in our 10.7.3 environment. OMG! Stunning. I’m not sure what the value add for Vine will be in a 10.7.x world, but for our needs we’ve now gone directly to screen sharing and aren’t looking back.
My experience with the built-in screen sharing in Lion is plain horrible. Obeying Apple’s ideal of graphical perfection, it does not allow any compression method that degrades the image in any way like JPEG or 8-bit color. This makes it sluggish on slower network connections. Logging in from a Linux or Windows VNC client is almost impossible, it requires far more attempts than with Vine server. And it exhibits the same annoying implicit command-keypress as Vine whenever I type an ‘i’ or ‘r’ in the spotlight search field.
Some Keyboard Shortcuts sent from iPad via Vine 4.0 beta are being reinterpreted as different shortcuts. Some are not working at all, or working differently depending on the application. For example Esc will unselect and close dialogs on the QWERTY keyboard, but if sent via iPad, then Esc only unselects, it won’t close dialogs. After a reboot it will close dialogs for a while but after a few edits, it ceases to work again.
Space via iPad is opening Spotlight, instead of entering a space char. Shift+Opt+d is not sending anything recognised by the host application, and Esc+Esc+Ctrl+v behaved as though Cmd V had been pressed.
Mac OS 10.7.4 If the Apple VNC is used, none of the inconsistencies are apparent, but the Apple VNC is unusable because it requires you to log out in order to reconnect a dropped server.
The behaviour changes after a reboot and relaunch, but the result is that the characters sent cannot be relied upon to mimic those of the QWERTY keyboard.
