Docs

Picture quality on slow links and the connection details

How a remote session adapts to a slow or busy link, why text stays readable and the picture sharpens when the screen is still, what the connection details and Copy diagnostics tell you, and what to do when the relay cannot connect.

Remote sessions run over whatever link the customer has: office fibre, a congested broadband line, hotel Wi-Fi. The picture adapts to the link by itself within seconds, keeps text readable while it does, and sharpens as soon as the screen stops changing. The connection details show what the session is doing and why.

How the picture adapts

The device watches how quickly your viewer receives each frame. When the link slows down or gets busy:

  1. The bit rate comes down first, so frames keep arriving instead of queueing up behind each other. A frame that would arrive too late is dropped rather than shown late, so the picture stays current.
  2. Then the frame rate: the picture updates less often, but each update is as sharp as before.
  3. Only then the resolution, on a link that really is slow. Small text scaled down is hard to read however sharp it is, so the resolution stays full size for as long as the link can carry a readable picture.

When the link recovers, the session climbs back to full quality within about ten seconds. Your own keystrokes and clicks are never held up by the picture.

Sharp when the screen is still

Fast changes, such as scrolling or a video, are sent quickly at a lower quality. When the screen then stays still for a moment, the device sends that picture again at full sharpness, usually within a second, so text you are reading is crisp. Typing and a blinking cursor do not count as a busy link.

The readable minimum

The session holds a minimum quality that keeps text readable. It goes below it only when the link has been measured to be slower than that, and comes back up to it as soon as the evidence lapses. The connection details then say Held at the readable minimum.

The device uses the graphics card to encode the picture where it can, and falls back to the processor when it cannot. In the browser viewer your pointer is drawn on your own computer, so it moves smoothly whatever the link is doing.

Picture quality and frame rate settings

Picture quality in the viewer's Picture and display menu (the Screen menu in the desktop viewer) sets what you prefer: Faster, Balanced or Sharper, with an optional Frame rate limit for slow lines. The session never goes above what you set; the link decides how far below. See Remote control.

The connection details

Connection details on the browser viewer's toolbar shows how the session is doing. On a wide screen the button itself says how far behind the picture is.

The browser viewer's toolbar with the route, frame rate, bit rate and round trip
The browser viewer's toolbar with the route, frame rate, bit rate and round trip
Row What it tells you
Route Direct, peer to peer or Through the relay.
Round trip, frame rate, bit rate, resolution and encoder The link and the picture as they are now.
Quality What is setting the quality: the connection (with the target), Held at the readable minimum, Limited by your quality setting, Limited by the device's encoder, or Starting up.
Viewer delay How long a frame waits in your browser between arriving and being shown, typical and worst over the last ten seconds.
End to end (estimate) From the moment the device captured the screen to the moment you saw it.
Freezes Times the picture stood still while the device's screen moved on. A still screen sends nothing and is not a freeze.

The desktop viewer's stats line says the same in short: frames a second, bit rate, round trip, how long frames take to reach the screen, and the route, ending with what is setting the quality.

When the picture falls behind for several seconds, the session's history says so, for example The viewer fell behind ... in the browser, so a complaint about a slow session can be checked afterwards.

Copy diagnostics

Copy diagnostics, in both viewers, copies every figure with where each came from, the device's capture and encode times, and the relay addresses in use. Paste it into a ticket when a session is slow. All figures are rounded to what a person can read.

The relay

A session that cannot connect directly goes through the relay on your Tenvara server. When the viewer and the device both use that relay, the relay passes the traffic between them itself, so a router in front of your server never has to send it back in. Settings > Remote access, the Relay tab, shows this as Relay to relay: Handled in process, with Test relay to relay for administrators to check it.

Relay to relay, handled in process, with Test relay to relay
Relay to relay, handled in process, with Test relay to relay

If a relayed session still cannot connect, the browser viewer says The relay could not connect the two ends, and the desktop viewer says the same. That points at your server rather than the customer's network, and Copy diagnostics names the two relay addresses for whoever looks after the server. The Relay tab also tests each way into the relay from your browser and from the server. See Remote control.

Was this page helpful?

Thanks for the feedback.