EADDRINUSE crash after several hours

[acortelyou]

I'm tracking a reliable crash after several hours of operation with the error message below.
I've enabled debug logging going forward and will do some more investigation after collecting more info.

2024/11/18 01:58:37	stdout	}
2024/11/18 01:58:37	stdout	  address: �[32m'0.0.0.0'�[39m
2024/11/18 01:58:37	stdout	  syscall: �[32m'bind'�[39m,
2024/11/18 01:58:37	stdout	  code: �[32m'EADDRINUSE'�[39m,
2024/11/18 01:58:37	stdout	  errno: �[33m-98�[39m,
2024/11/18 01:58:37	stdout	�[90m    at process.processTicksAndRejections (node:internal/process/task_queues:91:21)�[39m {
2024/11/18 01:58:37	stdout	�[90m    at node:dgram:366:14�[39m
2024/11/18 01:58:37	stdout	Emitted 'error' event on Socket instance at:
2024/11/18 01:58:37	stdout	�[90m    at process.processTicksAndRejections (node:internal/process/task_queues:91:21)�[39m
2024/11/18 01:58:37	stdout	�[90m    at node:dgram:364:20�[39m
2024/11/18 01:58:37	stdout	Error: bind EADDRINUSE 0.0.0.0
2024/11/18 01:58:37	stdout	
2024/11/18 01:58:37	stdout	      ^
2024/11/18 01:58:37	stdout	      throw er; // Unhandled 'error' event
2024/11/18 01:58:37	stdout	node:events:496
2024/11/17 19:20:33	stdout	03:20:33.512 INFO  PROXY: 9554 --> 192.168.1.237:554
2024/11/17 19:20:33	stdout	03:20:33.510 INFO  PROXY: 9080 --> 192.168.1.237:80
2024/11/17 19:20:33	stdout	03:20:33.509 INFO  SERVER: Camera6 - HTTP listening on 192.168.1.153:9081
2024/11/17 19:20:33	stdout	03:20:33.509 INFO  
2024/11/17 19:20:33	stdout	03:20:33.509 INFO  SERVER: Camera5 - HTTP listening on 192.168.1.196:9081
2024/11/17 19:20:33	stdout	03:20:33.509 INFO  
2024/11/17 19:20:33	stdout	03:20:33.508 INFO  SERVER: Camera4 - HTTP listening on 192.168.1.186:9081
2024/11/17 19:20:33	stdout	03:20:33.508 INFO  
2024/11/17 19:20:33	stdout	03:20:33.507 INFO  SERVER: Camera3 - HTTP listening on 192.168.1.139:9081
2024/11/17 19:20:33	stdout	03:20:33.507 INFO  
2024/11/17 19:20:33	stdout	03:20:33.490 INFO  SERVER: Camera2 - HTTP listening on 192.168.1.216:9081
2024/11/17 19:20:33	stdout	03:20:33.490 INFO  
2024/11/17 19:20:33	stdout	03:20:31.486 INFO  CONFIG: Updated /onvif.yaml

[acortelyou]

Fwiw I added snapshot ports and turned on debug logging and it hasn't happened since. It was crashing every 2-3 hours before. 🤷‍♂️

[p10tyr]

Its quite possible Unify was asking for a snapshot and crashing the proxy. I will try and look into the logs a bit more.

[p10tyr]

I will make snapshot ports a requirement in the config file.. the addr in use is common with adapters that need different port numbers used despite virtual IP's working.

[acortelyou]

It took longer but it happened again. Debug logging yielded no further insight. I suspect the issue is that all of my streams are coming from a single eight channel NVR: The tcp-proxy used in this project has a "unique key" buffer implementation that assumes you aren't making multiple proxies to the same IP/port.

I find myself wondering:

1. is tcp-proxy actually required? could GetStreamUriResponse just provide the original stream and snapshot uri?

2. are the extra IPs actually required? could we just listen on multiple ports instead?

3. since I'm already using go2rtc to inject h264 metadata (aspect ratio fix), multiplex the camera streams and it already supports a multitude of sources, could you lend your insight from this project towards making go2rtc's onvif server compatible with unifi protect?

Thank you for your project here, it's serving as a valuable proof-of-concept for a scenario I had long given up on, and if the concepts here are folded into go2rtc that would be very powerful and widely appreciated.

[balgerion]

I have same issue - its crashing everyday with log :

for test im running config with only two cameras now and its the same situation (crash everyday or twice)

[p10tyr]

I have been busy with a few other things.

But @acortelyou - it is quite possible all it needs is the UUID and not a separate MAC. I just went off the info on the og repo. Skimming the ONVIF specs they don't talk about MACs anywhere.. but I know they use a UDP Broadcast that replies from the virtual MAC with the IP address... so if we don#t need the MACs .. I'll bin them off

@balgerion I wonder if the snapshot issue could be something to do with file in use.. if it were dotnet we would have a much nicer stack trace 😄 the EADDRINUSE 0.0.0.0 does suggest port or IP in use on the main interface.. maybe its something else on the IP stack failing.