Knowledge Base

Everyday problems you might hit while using NoldusViso, and how to work through them yourself. This page is symptom-oriented: start at the section that matches what you see and follow the steps in order — each step narrows down where the problem is.

Important note: most checks run from your own computer. A few fixes must run on the VM host — the machine that runs the NoldusViso virtual machine — and need administrator (sudo) access. Those are clearly marked; if that isn't you, hand the section to whoever runs the server.

Prerequisites

• The NoldusViso web address (domain) you normally use.
• For the connection checks: a terminal (Command Prompt, PowerShell, or a shell) on your own computer.
• For sections marked on the VM host: admin access to the machine running the NoldusViso virtual machine.

1. Reaching the application

1.1 The page never loads

You open the NoldusViso URL and the page never appears. Work through these in order.

Step 1 — Can your computer reach the application?

Replace <domain> with the URL you use for NoldusViso:

ping -c 3 <domain>

• It replies (shows a response time and an IP) → your computer can reach the server. The problem is likely elsewhere — try a private browser window, or check with whoever runs the server.
• Destination Host Unreachable → your computer cannot reach the application. Continue to step 2.

Step 2 — Can your computer reach the VM itself?

If you know the VM's IP address, test it directly:

ping -c 3 <vm-ip>

• Same Destination Host Unreachable error → you can't reach the VM at all. This is a network problem on the VM host — go to 1.3 The VM isn't on the network.
• The VM IP replies but the domain did not → the VM is up, but DNS is sending you to the wrong place. Continue to step 3.

Step 3 — Is DNS pointing at the right IP?

dig <domain>

Look at the ANSWER SECTION and the IP listed for the A record. That is where your computer goes when it looks up the domain. If that IP differs from the VM's IP, DNS is resolving to the wrong location — fix it below.

Fixing DNS for a standalone install

Runs on the VM host — needs admin access.

A standalone install answers its own domain from either the hosts file or dnsmasq. Check what's configured:

cat /etc/hosts
# or
cat /etc/dnsmasq.d/aurora-standalone.conf

There should be an entry mapping the VM IP to the domain:

• In /etc/hosts (in the first section):

  <VM-IP> <domain>          # e.g. 192.168.0.1 viso.example.com

• In /etc/dnsmasq.d/aurora-standalone.conf:

  address=/<domain>/<VM-IP>   # e.g. address=/viso.example.com/192.168.0.1

If the entry is missing or points at the wrong IP, correct it so the domain maps to the VM's IP.

1.2 It worked yesterday, but is unreachable today

If NoldusViso was reachable before and suddenly isn't — without anyone changing the setup — the most common cause is that the VM's IP address moved. When the VM gets its address from DHCP, the network can hand it a different IP after a reboot or an expired lease. DNS then still points at the old address, and the domain stops resolving to the application.

How to confirm: run the checks in 1.1 The page never loads. The telltale pattern is step 3: dig shows an IP that no longer matches the VM's current IP.

Fix (on the VM host, needs admin access):

1. Give the VM a stable address: either configure a static IP on the VM, or create a DHCP reservation for it in your network's DHCP server so it always receives the same address.
2. Update the DNS entry (hosts file or dnsmasq, as in 1.1) to that stable address.

A stable production setup should never rely on an unreserved DHCP address — this problem will keep coming back until the address is pinned.

1.3 The VM isn't on the network (VM host)

Runs on the VM host — these steps run on the host machine that runs the NoldusViso VM, and need admin (sudo) access.

Check the network bridge and interfaces:

ip addr

Confirm all three:

1. The bridge br0 is up.
2. Your physical interface (eth* / eno* / enp* / enx*) is bound to the bridge — it should show master br0.
3. The VM's virtual interface (vnet*) is bound to the bridge — it should also show master br0.

If the physical interface isn't on the bridge: the netplan configuration (/etc/netplan/10-aurora-bridge.yaml) lists the interfaces under br0. Edit it so the interface named there is the one you actually use, then apply with sudo netplan apply (network connectivity may briefly drop).

If the VM's virtual interface isn't on the bridge: bind it manually — replace * with the number next to your vnet interface:

ip link set vnet* master br0

On reboot this should be picked up automatically. If it isn't, verify the VM's network configuration in virt-manager: open the VM, select "Show virtual hardware details", select the NIC entry, and confirm the Network source is a Bridge device named br0 with device model virtio.

2. Audio and video problems

2.1 A Dante microphone sounds distorted, with a higher or lower pitch

A pitch shift and distortion on a Dante microphone usually means the channel count is mismatched — the microphone is configured with fewer or more channels than are actually being published on the network.

Fix: make sure the number of transmitted streams over the single AES67 multicast stream equals the number of channels set on the device in the device management page — see Manage devices.

2.2 Live video won't start

If pages load but live video never starts, the usual suspects are on the network path:

• Use the domain, never an IP or localhost — live video (WebRTC) only works through the proper domain URL.
• Check the browser and network — try a private window, another browser, or another computer on the same network to narrow it down.

Note for admins: video signaling rides the standard HTTPS port (443, over WSS). Port 6088 is deliberately not opened on the host — opening it is never the fix. If video fails for everyone, verify that 443 is reachable from the client network.

3. Recordings and playback

3.1 Recordings play out of sync, or run longer or shorter than expected

If only some cameras in a recording are out of sync — or a recording's duration doesn't match how long you actually recorded — the cause is almost always camera clocks that disagree.

Recording timestamps come from each camera's own clock. If the cameras don't agree on the current time, their tracks won't line up.

What to check, in the device configuration:

• How closely the cameras are synchronized.
• Which NTP server each camera is pointed at.

Make sure all cameras use the same NTP server. The exact time doesn't matter — only that every camera agrees on what time it is.

Background: NoldusViso ships an NTP time server for cameras on the local network. Point every camera's NTP setting at the NoldusViso server address so they all share one clock.

Links

• Test Your Setup
• Manage devices
• System requirements
• FAQ