Error scenarios

These are some issues that you might occasionally experience when you live stream and/or take remote control of a running execution, along with our proposed solutions.

The live stream window shows Connecting..., but no connection is established

In all scenarios below, the Robot will not connect to the live streaming and remote control system, and the session will not start. The operation is retried for the maximum duration, which is approximately one minute, and then an error is displayed. Details about the failure are available in the Robot logs on the machine where the connection fails (not in job logs).

TightVNC is not installed

If TightVNC is not installed, the session cannot be started.Make sure to download and install it beforehand.Important: The Register TightVNC Server as a system service option (under TightVNC Service configuration) must not be selected. If it is, any request to start a session is ignored.

TightVNC does not have the correct version

The version we currently support is 2.8.75.

TightVNC is installed as a portable app

When TightVNC is installed as portable, the Robot is not able to detect it.

You can configure the path to the portable TightVNC by setting the UIPATH_TIGHTVNC_EXE_PATH environment variable with the full path that includes tvnserver.exe.

TightVNC is already started on the machine

When a live streaming and remote control session is finished, TightVNC is automatically closed. If you attempt to start a session, and the Robot detects that TightVNC is running, your request is ignored.

You need to close your currently opened instance of TightVNC.

Another user on the same high-density machine already has an open session

Machines running high-density robots only support one live streaming and remote control session at a time.If you try to open a session when another one is already running, your request is ignored.

In this case, you will only be able to access live streaming once the currently running process ends.

The live stream session connects after a delay

If you start a live streaming and remote control session immediately after a job is transitioned to the Running status, the Robot might not be ready to start it yet.

After a while, the Robot can handle the request and start the live streaming.

The live streaming image is lagging

This can be caused by a slow network connection between your machine and the robot one or when the screen resolution on the robot machine is large.

You see a blank screen

These are some reasons why you might see no image on your screen when you start the live stream.

The automation UI is not started

Some jobs perform certain actions prior to prompting the automation UI to open. If this happens, the live streaming session that opens is blank. This translates into the desktop being displayed for Windows Robots, and a black screen being displayed for Linux unattended robots and Automation Cloud Robots - serverless.

Try opening the session again.

You are using Linux robots

Linux unattended robots do not have the proper support for live streaming and remote control, so we do not recommend you use them for such operations.

Try using Automation Cloud Robots - serverless instead.

You are using a physical machine with no monitor connected

Live streams of processes executed on a physical machine are rendered on a physical monitor.

As such, you need to make sure that you have a monitor connected.

You have disconnected from the RDP

If you have disconnected from the remote desktop protocol (RDP), virtual machines will sometimes stop rendering the screen. This happens because, once disconnected, there is no virtual screen on which to render images.

To solve this, use the service mode robot.

A running session is disconnected

Network communication issues can cause a live streaming session to stop. If this happens, the client automatically reattempts to connect. This should be reasonably fast, but you might see the loading screen for a very short while.

If you had also enabled remote control within that session, note that you will have to re-enable it once the connection is established again. This is because, upon reconnecting, the session is opened in its live streaming state.

After a while, the session is abandoned. However, if you close the window, you can manually restart the session from Orchestrator.

You get an error message stating that another user is already connected

Only one user can access the live stream and take remote control at once. If a user is already connected, you must wait for them to disconnect.

For example, if User 2 tries to open a live stream that is already opened by User 1, they are returned an error stating that the live stream cannot be started. Once User 1 closes the live stream, User 2 will shortly be able to open it.