How to ensure support for currently unknown camera?

New user, testing v8.0.2.0 on Debian GNU/Linux Trixie amd64.

I have a H.view TV-CA4810 IP camera that has been unused for a very long time because it needed some weird Chinese Android application to control it. Considering throwing it away but did some research that led me to AgentDVR.

The TV-CA4810 is an Ethernet/WiFi PTZ camera with external 5V 2A power. I've connected it to my workstation using Ethernet.

Since this model is not listed in the Network Camera Wizard I have tried several existing models but so far not discovered a perfect match.

Is there some way to contribute to, or manually add, model definitions for achieving perfect support?

These are the results for the H.view models I've tested:

unlisted, TV-CB6010, TV-IP1011, TV-IP1311, TV-ip1312: ONVIF

rtsp://192.168.1.25:554/onvif1

Video good, but lost completely after between 2 and 20 seconds. Shows the "Connecting" animation. Never recovers and the Power icon doesn't always stop the "Connecting" animation. Likewise page refresh doesn't recover it. Using the device General settings power can be toggled and usually the camera video does recover. When video doesn't recover the only solution I've found so far is to delete the device and re-add it.

On the network side it is extremely noisy trying to contact remote servers. I wondered if the lost video might be due to it cycling whilst trying to contact them, but the DHCP cycle time is five minutes.

The RTSP communications look like this:

25261 12:32:29.338310470 192.168.1.1 192.168.1.25 TCP 74 58054 → 554 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=1657952568 TSecr=0 WS=1024 25262 12:32:29.338898865 192.168.1.25 192.168.1.1 TCP 74 554 → 58054 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM TSval=199158 TSecr=1657952568 WS=4 25263 12:32:29.338949099 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=1 Ack=1 Win=64512 Len=0 TSval=1657952569 TSecr=199158 25264 12:32:29.339033287 192.168.1.1 192.168.1.25 RTSP 151 OPTIONS rtsp://192.168.1.25:554/onvif1 RTSP/1.0 25265 12:32:29.339671616 192.168.1.25 192.168.1.1 TCP 66 554 → 58054 [ACK] Seq=1 Ack=86 Win=14480 Len=0 TSval=199158 TSecr=1657952569 25266 12:32:29.348982562 192.168.1.25 192.168.1.1 RTSP 194 Reply: RTSP/1.0 200 OK 25267 12:32:29.349009332 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=86 Ack=129 Win=64512 Len=0 TSval=1657952579 TSecr=199159 25268 12:32:29.349261245 192.168.1.1 192.168.1.25 RTSP 177 DESCRIBE rtsp://192.168.1.25:554/onvif1 RTSP/1.0 25269 12:32:29.350383853 192.168.1.25 192.168.1.1 RTSP/SDP 567 Reply: RTSP/1.0 200 OK 25270 12:32:29.350717019 192.168.1.1 192.168.1.25 RTSP 204 SETUP rtsp://192.168.1.25:554/onvif1/track1 RTSP/1.0 25271 12:32:29.352678593 192.168.1.25 192.168.1.1 RTSP 212 Reply: RTSP/1.0 200 OK 25272 12:32:29.352955282 192.168.1.1 192.168.1.25 RTSP 223 SETUP rtsp://192.168.1.25:554/onvif1/track2 RTSP/1.0 25273 12:32:29.355259770 192.168.1.25 192.168.1.1 RTSP 212 Reply: RTSP/1.0 200 OK 25274 12:32:29.355524487 192.168.1.1 192.168.1.25 RTSP 186 PLAY rtsp://192.168.1.25:554/onvif1 RTSP/1.0 25275 12:32:29.391779561 192.168.1.25 192.168.1.1 TCP 66 554 → 58054 [ACK] Seq=922 Ack=612 Win=14480 Len=0 TSval=199164 TSecr=1657952585 25276 12:32:30.085715942 192.168.1.25 192.168.1.1 RTSP 263 Reply: RTSP/1.0 200 OK 25277 12:32:30.129801030 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=1119 Win=64512 Len=0 TSval=1657953360 TSecr=199233 25278 12:32:30.214378391 192.168.1.25 192.168.1.1 TCP 242 Interleaved channel 0x02, 172 bytes 25279 12:32:30.214393009 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=1295 Win=64512 Len=0 TSval=1657953444 TSecr=199246 25280 12:32:30.215008555 192.168.1.25 192.168.1.1 TCP 1514 Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes, In 25281 12:32:30.215008635 192.168.1.25 192.168.1.1 TCP 202 Interleaved channel 0x02, 172 bytes 25282 12:32:30.215018914 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=2743 Win=67584 Len=0 TSval=1657953445 TSecr=199246 25283 12:32:30.215022832 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=2879 Win=70656 Len=0 TSval=1657953445 TSecr=199246 25284 12:32:30.215356388 192.168.1.25 192.168.1.1 TCP 1514 Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes, In 25285 12:32:30.215362139 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=4327 Win=73728 Len=0 TSval=1657953445 TSecr=199246 25286 12:32:30.215568977 192.168.1.25 192.168.1.1 TCP 378 Interleaved channel 0x02, 172 bytesInterleaved channel 0x02, 172 bytes 25287 12:32:30.215574237 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=4639 Win=75776 Len=0 TSval=1657953445 TSecr=199246 25288 12:32:30.216065500 192.168.1.25 192.168.1.1 TCP 594 Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes 25289 12:32:30.216070980 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=5167 Win=75776 Len=0 TSval=1657953446 TSecr=199246 25290 12:32:30.216615242 192.168.1.25 192.168.1.1 TCP 594 Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes, Interleaved channel 0x02, 172 bytes 25291 12:32:30.216620712 192.168.1.1 192.168.1.25 TCP 66 58054 → 554 [ACK] Seq=612 Ack=5695 Win=75776 Len=0 TSval=1657953446 TSecr=199246 25292 12:32:30.218728531 192.168.1.25 192.168.1.1 TCP 91 Interleaved channel 0x00, 21 bytes 

Watching the traffic also reveals how amateur the programmers were/are. After its DHCP ACK it immediately attempts DNS queries to 114.114.114.114 and 8.8.8.8 for these (note the unnecessary capitalisation!):

90 12:03:26.650685230 192.168.1.25 114.114.114.114 DNS 78 Standard query 0xb73e A p2p1.CLoUdlINkS.Cn
91 12:03:26.650685360 192.168.1.25 8.8.8.8 DNS 80 Standard query 0x9915 A p2p4.cLOUd-Links.neT
92 12:03:26.651062811 192.168.1.25 114.114.114.114 DNS 78 Standard query 0x3896 A P2P2.clouDLInKs.CN
93 12:03:26.651352714 192.168.1.25 8.8.8.8 DNS 80 Standard query 0xd17a A P2P3.CLouD-lInKS.nET
94 12:03:26.651684257 192.168.1.25 114.114.114.114 DNS 78 Standard query 0x6cf4 A p2p5.CLoUdlInKS.Cn
95 12:03:26.652045587 192.168.1.25 8.8.8.8 DNS 78 Standard query 0x9a86 A P2p6.clouDLInkS.cN
96 12:03:26.652530984 192.168.1.25 114.114.114.114 DNS 78 Standard query 0x0fbb A P2P7.Cloudlinks.cN
97 12:03:26.652815246 192.168.1.25 8.8.8.8 DNS 78 Standard query 0x1e5c A P2P8.cloUDLiNKs.cN
98 12:03:26.653238935 192.168.1.25 114.114.114.114 DNS 78 Standard query 0xa518 A P2p9.clOuDLinks.Cn
99 12:03:26.653515453 192.168.1.25 8.8.8.8 DNS 79 Standard query 0x3758 A P2p10.CloudLinks.Cn

Then in desperation it tries querying for www.google.com and www.baidu.com and then sends several UDP broadcasts to port 7721 with the payload "this is a test" at the same time as sending UDP packets to 47.91.77.247 and then tries switching to TCP to that same address. When that fails it attempts additional TCP to 121.43.181.184 and 123.206.9.74 and then tries to ping 8.8.8.8 and 114.114.114.114 four times.

When all that fails repeatedly it does a DHCP Release after about five minutes and then starts discovery again.