meshO Manager

Appearance

Reaching the server: name or IP ​

Audience: Event organisers setting up admin laptops, volunteer workstations, phones and TVs to reach the Manager server.

Settings → Server lists two kinds of address for every app — Manager, Registration, Spectator, Kiosk, Info screens and Commentary — one built on the computer's name, one on its LAN IP (tagged IP in the table). Once HTTPS is on, each also has a secure version, tagged HTTPS. They reach the same server, but they are not interchangeable: which one works depends on the device and the browser. Handing the wrong one to a download laptop is the most common reason a volunteer reports "I can't reach the server."

The short version ​

DeviceWhich link to use
Phones, tablets, spectator TVsName link — mobile devices find the computer's name on their own.
Admin laptops — card download, station backup, entry deskIP link. These usually run Chrome, and Chrome won't resolve a .local name.
The server computer itselfNeither — open http://localhost:5154/manager (or the HTTP port you set, if you changed it). See HTTPS and certificates.

Rule of thumb: the name is for devices people carry; the IP is for laptops doing the work.

Every link in the Access links table has a QR code button beside its copy button. Press it and the link is shown as a QR code — point the phone's or tablet's camera at the screen and it opens the link, with nothing to type. Show the code for the link that suits the device, as in the table above: the name link for a phone, the IP link for a device that cannot find the name.

Why the name doesn't always work ​

The name link is usually the computer's name with .local on the end, such as mesho.local. (If your router gives the computer a name of its own, such as mesho.lan, the link uses that instead — see Giving the laptops a name that works.) A .local name isn't resolved by ordinary DNS. No server anywhere holds a record for it — instead the computer answers a multicast query on the local network, a mechanism called mDNS (Apple calls it Bonjour). That's why it needs no configuration at all: it works the moment both devices are on the same network.

The catch is that each device decides for itself whether to ask that way.

  • iOS, iPadOS, Android and macOS (Safari, and every other Mac app that asks the system) do mDNS natively. Phones, tablets and TVs resolve the name without you doing anything — which is exactly the audience the name link is good for. Windows 10 and later, and most Linux desktops, usually manage it too.

  • Firefox asks the operating system rather than resolving names itself, so it inherits whatever the machine can do — on a Mac or a phone, that means the name works.

  • Chrome ships its own DNS resolver and, in practice, won't resolve a .local name — treat it as never working. It sends the lookup to your router as an ordinary DNS query, no router ever holds a .local name, and Chrome reports:

    This site can't be reached
DNS_PROBE_FINISHED_NXDOMAIN

    The same machine will usually load the same address perfectly in Safari, which is a good way to confirm this is what you're hitting.

There is no Chrome setting that fixes it. Turning off Secure DNS, granting it local network access, clearing its host cache and the BuiltInDnsClientEnabled policy have all been tried, and none of them helped. Nothing in Manager can fix it either: the name it publishes is right, and the rest of the network finds it. Don't spend time renaming the computer to work around it — see the warning under Giving the laptops a name that works.

This lands hardest exactly where it hurts. Reading SportIdent cards in the browser needs the Web Serial API, which is supported by Chrome, Edge and Firefox 151+ — see Downloading cards. In practice download and station-backup laptops run Chrome, the one browser least likely to resolve the name. Give those machines the IP link. Firefox 151+ can read cards too and asks the operating system for names, so it should manage the name link — but that hasn't been tried at an event yet, and the IP link works everywhere. It stays the safe default.

Giving the laptops a name that works ​

If you'd rather not hand out IP addresses — they're easy to mistype and they can change — have your router serve the name instead. A router-served name is ordinary DNS, so every browser resolves it, Chrome included.

Most home and event routers do this from one screen:

  1. Note the server's current address from Settings → Server (shown as LAN IP under the computer name).
  2. In the router's admin page, find DHCP reservations (sometimes "static leases" or "address reservation") and add one for the server.
  3. Give the reservation a host name — mesho is a good choice.
  4. Save, then restart the server so it picks up the new address.

Devices then reach it at that name plus whatever local domain your router uses — commonly mesho.lan, mesho.home, or mesho.localdomain. Manager notices the change and the Access links table starts offering the new name on its own; you don't have to configure it anywhere in Manager.

This also pins the IP, which solves the next problem for free.

It has to be the router that's changed, not the computer. Renaming the server computer to something like mesho.localdomain looks like the same idea and doesn't work: it only changes what that machine calls itself, and no device on the network gains any way to look the name up. The address may still open on the server itself, which makes it seem fixed when it isn't — test from a second device before trusting it. The router is the thing that has to answer.

When the IP changes ​

Without a reservation, the server's address comes from DHCP and can differ from one event to the next — the links volunteers bookmarked last month may point nowhere. Two things worth knowing:

  • A DHCP reservation stops it changing. Worth doing once for a machine that's regularly the server.
  • A new IP doesn't mean redoing certificates. If you use HTTPS, Manager reissues the server certificate itself and the CA your devices already trust still covers it — you just restart the server. See If the server is renamed or its IP changes.

Troubleshooting ​

What you seeWhat it meansWhat to do
DNS_PROBE_FINISHED_NXDOMAIN in ChromeChrome won't resolve the mDNS nameUse the IP link from the Access links table, or set up a router host name (above)
The name works in Safari or Firefox but not Chrome on the same laptopSame cause — confirms it's the browser, not the networkAs above
No link works from another device, name or IPNetwork access is off, or a firewall is blockingCheck Allow access from other devices on the network in Settings → Server, then the server's firewall
The IP link loads but shows a certificate warningNormal until the device trusts meshO's CATrusting the certificate
Card download controls don't appear, even though the page loadsNot an addressing problem — Web Serial needs Chrome, Edge or Firefox 151+ and a secure contextDo you even need HTTPS?