Troubleshooting
Solutions to the problems people actually run into.
Start here
| Symptom | Go to |
|---|---|
| The web page will not open | The page will not open |
| Everything is greyed out | I only have read-only access |
| A scoreboard is missing from the list | A scoreboard does not appear |
| A scoreboard is there but shows no contest data | A scoreboard appears but sends nothing |
| A mat is enabled and still records nothing | Reading the alert for that mat |
| A mat that worked at the last event is not being recorded | Was it away for more than a month? |
| A JudoManager server has an amber dot and no SELECT button | A JudoManager server is amber |
| Nothing is reaching the platform | Nothing is going online |
| The Video CutterV2 is not cutting | The CutterV2 finds no contests |
| A time or time-zone warning | Time warnings |
| Queue numbers keep growing | Queue Status |
| Graphics or FairReplay receiving nothing | UDP sending by channel |
| Two mats claiming the same number | Duplicate mat |
| Data appearing twice online | Everything is duplicated |
The page will not open
First: is the service running? Open JudoNet Monitor. If it says STOPPED, press START SERVICE.
This is by far the most common cause, especially after the PC has restarted — JudoNet does not start with Windows and nothing warns you that it is not running.
If the service is running:
- The address is
http://localhost:5220—http, nothttps, and port 5220. An old bookmark with a different address will not work. - Use Open In Browser in the Monitor rather than typing it. That also signs you in.
- From another PC, replace
localhostwith the JudoNet PC's name or address, and expect read-only access.
I only have read-only access
You can see everything and change nothing: switches, buttons and settings are greyed out.
That is the normal state when the page was not opened with the Open In Browser button — for example when you typed the address on another PC.
To get full access, someone with access to the JudoNet PC presses Copy Access Token to Clipboard in JudoNet Monitor and sends you the token; you paste it under Access Token in the left-hand menu. Full detail in access tokens.
If you had access yesterday and not today, the token has almost certainly rotated — they last five days, and a new one is also issued whenever the database is backed up and cleared. Ask for the current one.
A scoreboard does not appear
Work through these in order.
1. Is it switched on and on the right network?
Obvious, but check it first. The scoreboard PC must be on the same local network as JudoNet, by cable.
2. Is broadcast traffic being blocked?
Scoreboards announce themselves by UDP broadcast on port 8888 — a message sent to every machine on the local network at once, with no reply expected. Many managed switches and virtually all guest Wi-Fi networks block exactly that kind of message.
This is the usual cause when a scoreboard is definitely on, definitely reachable, and simply never appears. It is a network configuration problem, not a JudoNet problem.
3. Is the firewall allowing JudoNet?
JudoNet adds its own firewall rules on startup, but only when it has administrator rights. Check that rules named _JudoNet UDP 8888, _JudoNet UDP 18918, _JudoNet UDP 123 and _JudoNet NT Access exist in Windows Defender Firewall.
4. Was it removed from the list?
A scoreboard that stops announcing itself is dropped after about a minute. Within a month that is harmless: it keeps its settings, and comes back enabled and relaying as soon as it announces itself again. After a month away it is forgotten, and comes back disabled — see was it away for more than a month?.
Pressing Remove is not harmless. That forgets the scoreboard's settings, so when it announces itself again — often within seconds — it returns as newly discovered, and a newly discovered scoreboard is disabled. The row looks present and connected while that mat relays nothing, and no alert is raised for it. If a mat has stopped being recorded and its row otherwise looks normal, check the Enable switch first.
Remove now asks before it does that, and the message says so — but a scoreboard removed before that was added will still be sitting there disabled.
A scoreboard appears but sends nothing
The scoreboard is in the list, but the contest information stays empty.
Is it enabled?
Look at the Enable switch on that scoreboard's row. Grey means disabled, and a disabled scoreboard is watched but not recorded. Newly seen scoreboards always start disabled. Click the switch; it turns green.
This is the single most common cause, and it looks exactly like a fault.
Check the switch before you look for an alert, because a disabled scoreboard raises none. Every connection alert JudoNet can raise is suppressed for a scoreboard that is not enabled. A disabled board can be dialled with nothing accepting, given up on and dialled again indefinitely, and Alerts and Errors will stay silent about it — so finding no alert does not mean nothing is wrong.
Every newly discovered scoreboard arrives disabled, which is the state every board is in the first time it appears at a venue, so this is the ordinary case rather than an unlucky one. This is a current limitation and not a deliberate design; until it changes, the switch is the first thing to read and an empty Alerts and Errors is not an answer.
The Connection dot further along the row is a different thing: the switch is what you set, the dot is what JudoNet reports. Enabled but Connection red means you have switched it on and the connection is failing, which is the next section down. See enabled and connected are different things.
Reading the alert for that mat
If the scoreboard is enabled and still records nothing, Alerts and Errors carries the reason. Two things about it are worth knowing before you read it.
A mat has one connection message, not a list. When the cause changes, the message is replaced in place: the same line, rewritten underneath you, with its occurrence count still climbing. You will never see two connection messages stacking up for one scoreboard, so match the one that is there rather than looking for all of them.
These are not six faults you meet one at a time — they are states one mat moves between, and the wording follows it. A board that was delivering and then stopped reads:
Scoreboard 'PC-Mat7' disconnected.
If its address is then pruned as stale it has none enabled, and the same line becomes:
Scoreboard 'PC-Mat7' is not being dialled: none of its addresses are enabled. Tick one in its address list to connect it.
Ninety seconds, one line, two causes. So a message that has changed since you last looked has not been replaced by a second problem — the mat has moved.
It clears when data arrives, and only then. Not when the board reconnects, not when you change a setting, not after a while. That is the honest test of whether you have fixed it: the connection coming back is not the fix, packets arriving is.
| What has happened | What to do |
|---|---|
| It has been dialled and nothing has ever accepted a connection — not once since it appeared | Check the board is running and reachable at the address shown. On a mat that worked last week, suspect the address or the network rather than the board |
| The addresses were dialled and nothing accepted a connection | The same check, read as nothing is answering there now — this mat may have been working an hour ago. The row above is the stronger claim, that nothing has answered since JudoNet started: that one points at the address or the network, this one just as often at the board |
| It has no address left to dial — nothing is ticked and there is nothing to tick | Tick one, in that scoreboard's address list. One click. If the list is empty, the board has to announce itself again before there is anything to tick |
| No ticked address could be reached, so an unticked one is being dialled instead | Nothing, if that address is the right one — tick it and the message goes. If it is not, find out why nothing answers on the address you did tick. See an address JudoNet dials although you unticked it |
| It is connected and reachable, and no packets are arriving | Check the board itself, not the address. This is the one where everything on screen looks healthy |
| It is holding more connections than the four allowed, so it was not dialled this time | Nothing. They are closed already and it should reconnect on its own. Only if it keeps happening: restart JudoNet and report it |
| The dial failed before a connection object existed | Nothing you can fix from here. Collect the log and report it — the message says so itself |
Connected and reachable with no packets arriving is the row to watch. JudoNet says it plainly:
Scoreboard 'PC-Mat7' is reachable at ws://172.20.1.240:855/ws?user-agent=JudoNet but nothing is being read from it: the connection is open and no packets are arriving. Nothing is being stored, shown or sent on for this mat. Check the board itself rather than the address.
Everything an operator normally reads says that mat is fine — the row is there, the Connection dot is green — and nothing is being recorded. It clears itself within a second or two of packets resuming, so a brief gap mid-contest will raise it and then withdraw it without anyone acting.
"Disconnected" now means one specific thing: packets were flowing and then stopped. It is not the catch-all it used to be, so it no longer covers a board that was never reached, or one that is connected and silent. That last distinction is the easy one to get wrong — disconnected means the connection went away, and the row above it means the connection is still open with nothing coming down it. Same symptom for you, different thing to walk over and look at.
Two other alerts can appear beside the connection message rather than replacing it, both about a single address rather than the mat. One is an address JudoNet has dropped to the back of the queue, because nothing ever answered there; the other is an unticked address it has started dialling because no ticked one could be reached. Either pairing tells you something the mat-level message does not — which address, out of several, the trouble is on. See an address that has dropped to the back of the queue and an address JudoNet dials although you unticked it.
Was it away for more than a month?
A mat that worked at the last event is not being recorded, and nothing says why. If that scoreboard has not been seen for more than a month, JudoNet has forgotten what was stored for it. It came back as a newly discovered scoreboard, which means disabled.
Nothing warns, and that is what makes this one hard. The row looks present and connected, because it is — a disabled scoreboard is still dialled and still read, it simply stores and relays nothing. Two of the three things an operator reads look healthy.
The fix is one click: enable it.
This is a seasonal problem, not a daily one. A club whose mats sit unused over the summer meets it at the first event in September, not in the week a release shipped. If several mats were away that long, expect several of them to be disabled.
Is the WebSocket port right?
Discovery and the data connection are separate. JudoNet finds a scoreboard by broadcast, then opens a WebSocket to it — a connection that stays open in both directions, and the one that actually carries the packets — on the port that scoreboard announces, or on Scoreboard WebSocket Port if it announces none.
So a wrong setting no longer silences everything. It affects only boards that announce no port of their own; a board that states its port is unaffected. If every scoreboard is listed but silent, this setting is unlikely to be the cause — look at the network instead.
The port actually dialled is not shown anywhere in the interface. JudoNet writes it to the log as Connecting to ws://10.0.0.5:18855/ws when it connects, but that line is written at debug level and is not in the default log — ask support to turn on debug logging if the port in use has to be confirmed.
A scoreboard on a port of its own cannot be added by IP. Adding by IP sends a direct probe, and a probe has no announcement to read, so it uses the configured port. A board listening somewhere else will not answer — the probe simply finds nothing, which looks like a network fault. Such a board has to be found by discovery.
Is it connected to two networks?
A scoreboard on both cable and Wi-Fi announces itself on both addresses, and the connection may keep dropping and re-establishing. Disable Wi-Fi on scoreboard PCs, and make sure only one address is selected.
A JudoManager server is amber
The Status dot on a row in Live data → JudoManager Servers is amber, there is a warning triangle beside it, and the row has no SELECT button.
Amber always means one thing — JudoNet can see this server and cannot use it — and there are four reasons for it. Hover the row and JudoNet names the one that applies in a sentence; the warning triangle opens the section for it below.
Some amber rows are normal and stay amber. Every PC on the network running the JudoManager desktop appears in this table, including machines that are not yours and are none of your business. Only the server you need to select has to be green.
The server does not answer
The row's sentence names an address and says JudoNet cannot tell whether the machine is JudoManager or Judobase. The server is announcing itself on the network, JudoNet is asking it what it is on port 8888, and nothing is coming back within the second it allows.
This is the only one of the four where a blocked port is a live possibility, because it is the only one where the machine is known to have something to ask. Work through it in this order:
- Is JudoManager actually running on that PC? The announcement and the reply come from the same machine but not from the same place — a machine can keep announcing itself after the part that answers has stopped. Go to it and check the JudoManager desktop is open.
- Open the address in a browser on the JudoNet PC. Take the address from the sentence on the row and put it in a browser:
http://<address>:8888/api/system. If the browser gets a reply, JudoNet will too, and the problem is intermittent rather than blocked — carry on to step 4. If the browser times out as well, it is the network or the firewall. - Allow port 8888 through the firewall on the JudoManager machine. In Windows Defender Firewall with Advanced Security → Inbound Rules → New Rule, choose Port, then TCP and the specific port 8888, then Allow the connection, and apply it to the network profile that PC is using — usually Private or Domain at a venue. Third-party security software has its own list and has to be told separately.
- Is it slow rather than silent? JudoNet waits one second. A machine that is swapping, running a backup, or on saturated venue Wi-Fi can take longer than that and will flicker between amber and green. Take the load off it, or put it on cable.
The dot for this cause blinks slowly, because it is the only one that can come right on its own. If somebody has just restarted JudoManager on that machine, wait a few seconds before doing anything else.
The server is too old
JudoNet asks a server what it is over an interface that arrived in JudoManager 7.1.9.5. Anything older does not have it, so JudoNet never asks at all. Waiting changes nothing, and neither does any amount of firewall work — there is nothing on that machine listening to be let through.
- Find out which machine it is. The row's sentence names the version that machine is running, so you can tell it apart from the identical-looking row beside it without walking over.
- Check the rest of the venue while you are here. The Version column should read the same on every JudoManager row. The usual way this appears is one machine missed in an upgrade round, and it is worth finding all of them in one trip rather than one per contest.
- Upgrade JudoManager on that machine to 7.1.9.5 or newer.
- Restart the JudoManager service on it afterwards. The version JudoNet shows comes from what that machine announces about itself, and until the service is restarted it goes on announcing the old number — the same trap as TZ mismatch! on the same machine.
- Watch the row. JudoNet asks again on the next announcement, a few seconds later. Nothing needs restarting on the JudoNet side.
If the Version column still shows the old number after all this, step 4 has not taken effect. If it shows the new number and the row is still amber, it is a different problem now — read the row's sentence again and follow the section it names.
Its version cannot be read
The machine announces a version JudoNet cannot make sense of, so JudoNet cannot tell whether it is new enough to be asked — and it did not reply when it was asked anyway. Both halves have to be true before JudoNet says anything about it.
That combination is almost always a broken or partial JudoManager installation rather than anything on the network.
- Look at the Version column for that row. It will be empty, or show something that is not a version number. That is exactly what JudoNet received.
- Go to the machine and open JudoManager. Read the version it reports for itself and compare it with what the row shows. A machine that knows its own version but announces something else has a damaged installation; one that will not open at all has a worse one.
- Repair or reinstall JudoManager on it, then restart the JudoManager service so the next announcement carries a readable version.
- Watch the row on the next announcement. Green means it is fixed and answering.
What it turns into next tells you what is left:
- Amber with the too-old sentence — the version is readable now, and it is genuinely an old build. Go to the server is too old.
- Amber with the not-answering sentence — the version is readable now and new enough, and the reply is the part still missing. Go to the server does not answer.
A machine that announces an unreadable version but does reply is fine, and JudoNet shows it green. The unreadable version on its own costs nothing; it only matters when nothing answers either, because then it is the thing standing between you and knowing whether asking could ever have worked.
It has no competition open
The server answers, JudoNet knows exactly what it is, and it has no competition to send data to. Nothing is wrong with the machine or the network.
Selecting a server is how JudoNet is told which competition is running, so a server with nothing open has nothing to be selected for. On a setup morning most of the hall is in this state, which is why it is amber and not an alert.
- Check you are looking at the right machine. Several rows look alike; use the Name column, which is that PC's name.
- Open the competition in JudoManager on that machine.
- Watch the row. The Competition column fills in and the dot turns green within a few seconds. Nothing needs restarting, on that machine or on JudoNet.
- Press SELECT on it.
A competition can be open and still leave the row amber. What JudoNet needs from that server is the competition's External ID — the identifier of the competition as the online platform knows it — and a competition that exists only on that machine has none.
So if you have opened a competition and the row is still amber with the same sentence, the competition is the local kind. Open the one that came from the platform, or give this one its External ID in JudoManager. This is worth knowing before the event: it looks exactly like nobody having opened anything.
Nothing is going online
Contests are being received — you can see live data — but nothing reaches the platform.
Check, in order:
- Is a JudoManager server selected? Without one, JudoNet does not know where to send anything. Live data → JudoManager Servers.
- Are the master switches on? Store Online and Display Online do different jobs; both are off by default after a fresh install.
- Is the token valid? On the Settings page, use Test token for JudoManager, or Refresh Token. An expired token produces API failures in the alerts.
- Is the internet working? Look at the network check graph. A rising line means uploads will be slow or failing.
- Read the alerts. API failures are reported on Alerts and Errors with the reason, which is usually specific enough to act on.
The CutterV2 finds no contests
The Video CutterV2 reports Finished contests: 0 while fights are clearly finishing.
JudoNet is the CutterV2's only source of timings, so the fault is usually here.
| Check | Detail |
|---|---|
| Is JudoNet running? | The service must be started. |
| Is Store Locally on? | Contest timings come from JudoNet's own database. With it off, there is nothing to give. |
| Is the right competition selected? | The CutterV2 asks for a specific competition by its External ID. If JudoNet has a different competition selected, it correctly answers "no contests". |
| Are the contests actually finished? | Look at Contest Times. A Mode 7 of 0 means no winner was declared, so the contest never counts as finished. |
| Was the scoreboard enabled? | A disabled scoreboard produces no stored data, so its mat has no contests. |
JudoNet waits at least 30 seconds after the winner screen before publishing a contest as finished. Clips therefore appear about half a minute after a fight ends. That is normal and not a fault.
Time warnings
JudoNet's own clock
The left-hand menu says JudoNet's time is ahead or behind, or that trusted time was never established.
JudoNet corrects its own clock on startup and checks every minute, so a persistent warning means it cannot reach a time server. Check the internet connection.
Trusted startup time was not established is the more serious message: JudoNet could not reach a time server when it started, so it is using the PC's own clock and timestamps may be wrong. Fix the connection and restart the service.
Another machine says Sync Time!
JudoNet reports on the clocks of scoreboards, JudoManager servers, FairReplay Recorders and other JudoNets — but it cannot correct any of them. Somebody has to go to that machine and fix its clock.
Do this the day before if you can — but know what it does and does not affect. Contest timings come from JudoNet's clock, not from the machine's: every packet is stamped as it arrives here, so a scoreboard whose clock is minutes out still records contests at the right time and its video is cut from the right place. What a wrong clock elsewhere costs you is the warning itself, sitting on the page all day, hiding the one that means something.
The clock that does decide when contests are archived and where video is cut is JudoNet's own — the section above.
TZ mismatch!
The machine's time zone differs from JudoNet's, which is a different problem from the clock being wrong.
On a JudoManager server, correcting the time zone is not enough on its own — the JudoManager service must be restarted before the change takes effect. Until then the warning persists even though the setting looks right.
Duplicate mat
Two scoreboards claim the same mat number, and JudoNet shows a duplicate-mat warning.
JudoNet has no way to tell which is the real one, so that mat's data cannot be trusted until it is fixed. Either correct the mat setting on one of the scoreboard PCs, or remove the scoreboard that should not be there.
Do not leave this for later. Every contest recorded for that mat meanwhile is suspect.
Everything is duplicated
Contests appear twice online, or FairReplay receives every marker twice.
More than one JudoNet is running with the same switches on. Open Live data → JudoNet Services: a conflicting instance is highlighted orange with an asterisk by its name.
Only one JudoNet on the network may have Store Online, Display Online, Broadcast UDP to Graphics or Broadcast UDP to FR enabled. Switch the extras off on the others. A backup JudoNet should have Store Locally only.
Alerts that will not go away
An alert with a red circle is still happening. A green one has resolved itself and is only there for the record — dismiss it with the X.
If a red alert persists after you have fixed the cause, dismiss it and see whether it comes back. Alerts are raised when a problem is detected, and some only clear on the next check.
A scoreboard's connection alert is the exception, and this is the useful thing to know about it. It clears by itself the moment that scoreboard sends a packet — any packet, whatever the message said — and it disappears altogether if the scoreboard is removed, whether you removed it or JudoNet dropped it after a minute of silence. So a red one means JudoNet is still watching that scoreboard and has not had data from it, and dismissing it achieves nothing that arriving data would not.
That is true of every connection message, not only disconnected. Which one it carries is what tells you why — see reading the alert for that mat. In older versions it could stay red for a scoreboard that had already come back; if you see that, check the version.
Log files
Everything JudoNet does is written to disk, in far more detail than the page shows. Open Log Folder in JudoNet Monitor opens the folder directly:
C:\JudoNet\logs
| File | Contents |
|---|---|
<date>.log | The main log — one file per day. |
archive\ | Older logs, rolled over automatically. |
UdpSenderService\udp-<date>.log | The UDP broadcasts to CG - JudoGraphics and FairReplay, separated because there are so many. |
Open them with Notepad or any text editor. When reporting a problem, send the whole day's folder rather than one file.
Getting help
Have ready:
- The JudoNet version, from the top of the left-hand menu.
- What the alerts say.
- The contest code if it concerns one contest.
- The log folder for the day.
- What changed recently — a new PC, a network change, a different venue.
The Documentation link at the bottom of the left-hand menu opens this documentation.