[ERR] Could not start server: listen tcp :8089: bind: Only one usage of each socket address

Channels DVR Server Troubleshooting
#1

After an upgrade this morning, the Channels DVR server failed to start so Channels DVR could not be accessed at all. I was in office all day so I couldn't do anything about it. The good news is that it was still doing its thing (recording as scheduled), it's just that we couldn't connect to it (no web access even on the computer itself at 127.0.0.1:8089, and no client access).

2024/10/02 06:02:31.426643 [SYS] Created database snapshot: backup-20241002.100231
2024/10/02 06:02:31.426643 [SYS] Removing old backup backup-20240911.135656
2024/10/02 06:02:31.493049 [SYS] Shutting down for upgrade from v2024.09.26.2019 to v2024.10.01.1128
2024/10/02 06:02:32.032635 [SYS] Bonjour service stopped.
2024/10/02 06:02:32.132278 [DVR] Recording engine stopped.
2024/10/02 06:02:33.638434 [SYS] Goodbye.
2024/10/02 06:02:33.655916 [SYS] Starting Channels DVR v2024.10.01.1128 (windows-x86_64 pid:22672) in C:\ProgramData\ChannelsDVR\data
2024/10/02 06:02:33.787498 [ERR] Could not start server: listen tcp :8089: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Logs have been submitted as 4a9100de-ddc8-4513-93f6-3b757142934a .

As soon as I got back from the office, I fixed it by restarting the whole computer. Killing Channels DVR alone and trying to restart it didn't work.

This already happened not too long ago and I didn't think much of it at the time. I figured it was just a random hiccup with Windows.

But now that's twice so maybe there's something going on?

#2

Are you running any sort of firewall? We’ve seen them act badly and cause symptoms such as this before.

#3

No firewall other than what comes in Windows 11.
Any settings I should check?

#4

Nope, that’s the only thing I’ve seen before that would cause it.

#5

No problem. Thank you for looking into it.

From now on, I will make sure that updates are done only when I'm present at the computer so that I can make sure it restarts properly. :slightly_smiling_face:

#6

The way I read that error message is that some other service/program has already bound itself to TCP/8089, which is why Channels cannot bind to that port. It would also explain why the server continued to operate in the background, but no client could connect.

You may want to check the task viewer and/or service manager to see what else is running. (Of course, that would only be helpful when you encounter this problem again. Normally I would suggest checking netstat to see which processes have bound which port, but I don't know what the Windows equivalent is.)

1 Like
#7

Thanks for the tip, @racameron.

According to Microsoft Copilot:

On Windows, the equivalent of the netstat command is the Get-NetTCPConnection cmdlet in PowerShell. This cmdlet provides similar network statistics and can be used to view active TCP connections, listening ports, and more.

So if I encounter this situation again, I will give it a try. :slightly_smiling_face:

#8

Not sure about Win 11, but I use netstat all the time on my Win 10 Pro.
Just open an admin command prompt and type netstat -?

C:\windows\system32>netstat -?

Displays protocol statistics and current TCP/IP network connections.

NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [-x] [-y] [interval]

  -a            Displays all connections and listening ports.
  -b            Displays the executable involved in creating each connection or
                listening port. In some cases well-known executables host
                multiple independent components, and in these cases the
                sequence of components involved in creating the connection
                or listening port is displayed. In this case the executable
                name is in [] at the bottom, on top is the component it called,
                and so forth until TCP/IP was reached. Note that this option
                can be time-consuming and will fail unless you have sufficient
                permissions.
  -e            Displays Ethernet statistics. This may be combined with the -s
                option.
  -f            Displays Fully Qualified Domain Names (FQDN) for foreign
                addresses.
  -n            Displays addresses and port numbers in numerical form.
  -o            Displays the owning process ID associated with each connection.
  -p proto      Shows connections for the protocol specified by proto; proto
                may be any of: TCP, UDP, TCPv6, or UDPv6.  If used with the -s
                option to display per-protocol statistics, proto may be any of:
                IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
  -q            Displays all connections, listening ports, and bound
                nonlistening TCP ports. Bound nonlistening ports may or may not
                be associated with an active connection.
  -r            Displays the routing table.
  -s            Displays per-protocol statistics.  By default, statistics are
                shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
                the -p option may be used to specify a subset of the default.
  -t            Displays the current connection offload state.
  -x            Displays NetworkDirect connections, listeners, and shared
                endpoints.
  -y            Displays the TCP connection template for all connections.
                Cannot be combined with the other options.
  interval      Redisplays selected statistics, pausing interval seconds
                between each display.  Press CTRL+C to stop redisplaying
                statistics.  If omitted, netstat will print the current
                configuration information once.
1 Like
#9

You are right, the command netstat also works in Windows 11. :slight_smile:

1 Like
#10

Being able to run a command and knowing what the output means are radically different things. Also, this can be even more important, as BSD and GNU versions of the same tools can be quite different; who knows what extra crap MS added in ...