01304 827609 info@use-ip.co.uk Find us

Video loss problems?

Ok, I dropped by the office, here’s a couple pics. I will have to look up a network connectivity log for the nvr, not sure where that is. But for now…
Looks like we’re getting closer to the root cause.
 
These are the logs I exported, the LAN had an extension of pcap, I changed to text because I couldnt upload here.
Please give me your thoughts.
 

Attachments

  • 20230109083349logBack.txt
    169.1 KB · Views: 113
  • LAN1_20230109083728.txt
    20.3 KB · Views: 186
I think DSP Chan 3 is Channel D4 and is dropping a lot of packets, is that the problem one?

Screenshot 2023-01-09 at 16.24.23.png

Can you get events from the network side?
 
The 4 channels I'm using all have the video loss issues. One doesn't seem to be any worse than the other. Channel 1 is Hikvision, 2 Dahua. 3 Dahua, 4 Hikvision.

Events from the network side, is this from the router end?
 
The 4 channels I'm using all have the video loss issues. One doesn't seem to be any worse than the other. Channel 1 is Hikvision, 2 Dahua. 3 Dahua, 4 Hikvision.

Events from the network side, is this from the router end?
From the NVR end, I think the pictures you sent yesterday tell some of the story.

When will the network cables to the cameras and NVR be checked?
 
@hurri10209 mark the cables before disconnecting them from the back of the NVR, make sure they are reconnected to the same port.
 
@hurri10209 mark the cables before disconnecting them from the back of the NVR, make sure they are reconnected to the same port.
They’re already flagged. I put the call in for the test, waiting on a call back with a schedule. I’ll update once I have a schedule.

Am I correct assuming the internal network is except since the data loss is occurring at the nvr (excluding the possibility of an IP conflict)
 
Am I correct assuming the internal network is except since the data loss is occurring at the nvr (excluding the possibility of an IP conflict)
The NVR IP subnet 192.168.254.nnn is private to the NVR. Did that answer your question?

I hope the network cables will have a thorough physical check as well. They should give you a report for each cable.

when you have access to the router I’d like to check if you have a fixed / static ipv4 address for the NVR. let me know the router make model and version.

David
 
The NVR IP subnet 192.168.254.nnn is private to the NVR. Did that answer your question?

I hope the network cables will have a thorough physical check as well. They should give you a report for each cable.

when you have access to the router I’d like to check if you have a fixed / static ipv4 address for the NVR. let me know the router make model and version.

David
I know the NVR is set to dhcp, subnet for the router is 192.168.1.xx, The ip cameras are assigned a 192.168.254.xx from the nvr. I can discount the LAN for the night if you think that will be helpful while waiting on the line test. I can also assign the NVR a static address.

The lines are all new, I’ve inspected the ends, replaced a few (had another guy helping and he didn’t get enough jacket), they do give me a report for each line, they also inspect the ends prior to testing. I will make sure I get a copy of the test data. I pulled the cabeling about 4 weeks ago, we don’t have any pest problems , it was a pretty easy pull (drop ceiling with steel trusses), no fluorescent fixtures and no pulls parallel to ac power. I’m confident there is no damage to the cable itself.

Thank you again, hopefully this will come to a head soon.
 
I can discount the LAN for the night
if you meant disconnect the LAN, I would leave it connected.

I’ve inspected the ends, replaced a few
has it made any difference?

The Belden cable specs you posted show solid copper conductor, I thought it was CCA?

I was just thinking about cable lengths and PoE, check the PoE power budget at the NVR. Are your PTZ's using a separate PoE supply, I think you mentioned a 60W supply for them.
 
if you meant disconnect the LAN, I would leave it connected.


has it made any difference?

The Belden cable specs you posted show solid copper conductor, I thought it was CCA?

I was just thinking about cable lengths and PoE, check the PoE power budget at the NVR. Are your PTZ's using a separate PoE supply, I think you mentioned a 60W supply for them.
No notable improvement, I did the ends on Friday afternoon, the CCA cable was a learning experience from a different install, sorry for the confusion.
NVR showed <5w per cam, the PTZ are on injectors. Total VNR capacity was ~180w remaining.
 
No notable improvement, I did the ends on Friday afternoon
It would be very unusual for 4 network cables to have a similar problem, lets see what the cable results are.

See attached image from my older NVR, should be similar to yours. Your NVR ping test may have more functionality. You may be able to ping the cameras from your NVR, I don't know what the ping does so the results could be misleading.

I am not sure if the Microsoft Edge browser has any problems with your NVR firmware, try Google Chrome as an alternative. Better still (until you have a stable setup) do any config / viewing / playback from the NVR monitor / mouse. That way you are ruling out any bugs from win10 / 11 and other browsers. Obviously some tests will have to be done from your wired desktop. The more unknown variables we can remove from the chain the better.

I always apply "Occam's Razor" to my troubleshooting, also known as "sorting the wheat from the chaff".

Screenshot 2023-01-10 at 08.21.53.png
 
Last edited:
I attached the logs from yesterday, did you use a program to open the network log, I can see the dropped packets in the event log but certainly isn't as legible. I hope to here back from the telco today. I had more video loss reports last night to the hik0connect app than the previous night.
 

Attachments

  • LAN1_20230110085917.txt
    83 KB · Views: 204
  • 20230110083158logBack.txt
    177.9 KB · Views: 120
I attached the logs from yesterday, did you use a program to open the network log, I can see the dropped packets in the event log but certainly isn't as legible. I hope to here back from the telco today. I had more video loss reports last night to the hik0connect app than the previous night.
I think the smaller LAN1 file is html code, the other is parseable text. I used to write scripts to process these, we are not seeing the full picture here.
 

Attachments

  • Screenshot 2023-01-10 at 15.31.54.png
    Screenshot 2023-01-10 at 15.31.54.png
    314.1 KB · Views: 105
Can you export this log from the NVR?
set date time range
Major type exception
uncheck minor type box
select ones I've checked. Deselect the illegal login box.
you can check others if you think they are relevant.

Screenshot 2023-01-10 at 16.07.00.png
 
Can you export this log from the NVR?
set date time range
Major type exception
uncheck minor type box
select ones I've checked. Deselect the illegal login box.
you can check others if you think they are relevant.

View attachment 8630
I will post it in the morning, I’ll follow up with the telco people for my line test, haven’t heard back. Not sure if the logs show dropped packets for either of the panoramics (1,4) but I do receive alerts on hik-connect and on the nvr for video loss.
Sorry this seems to be a tricky one to nail down, appreciate all the assistance.

I’m sure you noticed, but the pic with lost packets seems to be every 20 minutes, I can try swapping injectors to see if that moves the packet loss from 3 to 2, won’t explain the other video loss but might point to an injector issue?
 
I’m sure you noticed, but the pic with lost packets seems to be every 20 minutes, I can try swapping injectors to see if that moves the packet loss from 3 to 2, won’t explain the other video loss but might point to an injector issue?
I am also seeing
Cameras D2, D3 and D4 are showing multiple "Extra information: Options error -- rsp t[0]q[1]r[0]c[0]" just before connection loss

Cameras D2, D3 and D4 show multiple "Extra information: TCP Recv error -- recv over rtsp data err" just before connection loss

Camera D1 has multiple "Extra information: Lost SYN -- rtsp data lost sync"

I also see multiple video and connection loss for D2 D3 D4, not so much for D1

The logs are difficult to follow, very poor data consistency.
 
Last edited:
Here's the export with only the noted selections. I also scaled back the prerecord to 0, there were some buffering errors (if I understood correctly).
 

Attachments

  • 20230111100751logBack.txt
    19.6 KB · Views: 200
  • 20230111101140logBack w-o illegal login.txt
    5.1 KB · Views: 205
Last edited:
Here's the export with only the noted selections. I also scaled back the prerecord to 0, there were some buffering errors (if I understood correctly).
As we know there is nothing new, fingers crossed the telecoms guys will show up. I would think the TCP receive errors will have knock on effects, fingers crossed this is the cables. If the cables are good I'd bring a camera down and connect it direct to the NVR.

Screenshot 2023-01-11 at 15.52.04.png
 
Just to be sure, there is no setting change to make when using the injector with a Poe NVR? Under the power usage page it displays “shorted” or “short circuit” on the cameras connected to the injector. I just assumed this was normal when using an injector.
 
Back
Top