Hikvision - Manual playback scrolling freezes at anything above 1792 kb/s bitrate during daylight hours

[Stuart J]

Hi All

Apologies in advance as the details below could be a long (tedious) read for the ‘only moderately’ interested but my aim was to include sufficient detail to work with initially.

I would be very grateful to anyone who can spare the time to read this and offer any help please – Many thanks :-0)

Summary of problem and observations (NI-I2/8P + 4 x ColorVu 2347s)

Whilst the low light colour capability of these ColorVu cameras is impressive, I have been disappointed with the definition/resolution since installation in late May.

This has been exacerbated in part by the system’s refusal to work at anything above a bitrate of 1792 kb/s whilst retaining the ability to speed-scroll the playback time bar while simultaneously viewing the screen recorded video footage; I refer to this as 'freezing' throughout.

Even if the bitrate is increased to only the next level up of 2048kb/s (let alone the 8192kb’s value that I would prefer), the screen ‘freezes’ BUT this only happens during hours of daylight; the problem totally disappears during hours of darkness!

Description, testing and observations

I am unable to use the system (DS-7608NI-I2/8P and 4 x DS-2CD2347G1-LU ColorVu 4MP 4mm) above a bitrate of 1792 kb/s without the screen display together with top OSD of time and date freezing when mouse-scrolling the playback footage, however the lower scroll bar time ‘keeps up’ with the left mouse buttoned time bar scrolled movement. To clarify, it is only when speed scrolling (depressed left mouse button whilst moving across the blue time bar) that the display freezes. As soon as the left mouse button is released, the display instantly catches up and shows the correct scene and both OSD and blue time bar details match exactly.

However, all is well during hours of darkness when the system works happily with 8192kb/s and it is only when dawn/daylight approaches that it reverts such that subsequent playback of the footage freezes once again when attempting to mouse-scroll the time bar of footage recorded during hours of daylight.

Cam04 bitrate was increased in stages after 19:00hrs 15/11/2020 from 1792kb/s. Following each increase, the recorded footage was viewed (via mouse-scrolling the time line) and the bitrate was finally set at 8192kb/s. No ‘freezing’ was noted either up to or including this setting and all was well. NB It was dark at this time.

All the night-recorded footage was speed-viewed the next morning. All was good until ca dawn/daylight was breaking when all footage from 06:59hrs froze when mouse-scrolling the time bar (N.B. camera west-facing).

The test was conducted on the camera where the night time ‘residual ambient’ lighting (west-facing camera and hidden from street lighting) is so low that it triggers the supplement LED warm white lights (no IR on the 2347 cams). However, previous experience has also shown this ‘freezing’ behaviour to be common across all four cameras (the other three cameras use only ambient daylight and street lighting as the latter is sufficient such that the cameras’ supplemental LED lights are not triggered).

Observations from the first 22hrs of system behaviour identified a potential relationship between the lux level (and/or daylight colour temperature?) and the system’s ability to provide useful playback information when simultaneously scrolling the time bar. To clarify, the playback was ‘frozen’ from 06:59hrs until 16:34hrs at which point, it began to ‘unfreeze’, albeit in a jerky and broken fashion initially (but became consistently smooth by 16:46hrs showing 2 second increments), some minutes prior to the supplement LED lighting being triggered at 16:50hrs.

The test settings were allowed to continue to run but essentially, almost identical results were obtained for the following day where ‘unfreezing’ began at 16:46hrs (referenced above) and continued perfectly until dawn at 06:56 17/11/2020 when the footage became frozen once more.

I have tried various permutations of bitrate, video quality and frame rate settings throughout the daylight hours but have had no success

Discussion/thoughts

The DS-7608NI-I2/8P appears on paper to have sufficient bandwidth (80Mb/s Incoming and 256Mb/s Outgoing) to cope with the load from these four DS-2CD2347G1-LU ColorVu units so I am not thinking that bandwidth capacity is responsible. That said, this is my first experience with CCTV and unfortunately I am at the low end of a steep learning curve.

One positive from this - running at the increased bitrate over the last two days has however demonstrated a slightly improved video quality, albeit at the expense of not being able to conveniently speed scan the footage.

This following fact may or may not be relevant but whilst I have rebooted the system several times over the past few months and also following firmware updates, I have not conducted a factory reset and I have not noted this requirement in Hikvision documentation although there have been references to the need for this elsewhere.

Hardware and settings

NVR: DS-7608NI-I2/8P

Cameras: 4 x DS-2CD2347G1-LU ColorVu 4MP 4mm

HDD: 4TB Western Digital WDPURZ

4K monitor

I currently have all cameras set to 2560x1440 (4MP), Variable Bitrate, Highest Video Quality and Full Frame fps which during the day is ca 25. This value is ‘maintained’ on two of the cameras whereas the remaining two ‘adjust/modulate’ down to ca 12fps during hours of darkness which I think is due to subtle differences in the amount of night time street lighting available to each camera (facing NW, NE and SE).

Firmware: (Latest firmware installed from Hikvision Portal)

NVR V4.40.016, Build 200803

Cameras V5.6.5 build 200316

Video Encoding: H.265

UI: GUI 4.0/NVR 4.0

Many thanks for your time once again

 

[JB1970]

Hi All

Apologies in advance as the details below could be a long (tedious) read for the ‘only moderately’ interested but my aim was to include sufficient detail to work with initially.

I would be very grateful to anyone who can spare the time to read this and offer any help please – Many thanks :-0)

Summary of problem and observations (NI-I2/8P + 4 x ColorVu 2347s)

Whilst the low light colour capability of these ColorVu cameras is impressive, I have been disappointed with the definition/resolution since installation in late May.

This has been exacerbated in part by the system’s refusal to work at anything above a bitrate of 1792 kb/s whilst retaining the ability to speed-scroll the playback time bar while simultaneously viewing the screen recorded video footage; I refer to this as 'freezing' throughout.

Even if the bitrate is increased to only the next level up of 2048kb/s (let alone the 8192kb’s value that I would prefer), the screen ‘freezes’ BUT this only happens during hours of daylight; the problem totally disappears during hours of darkness!

Description, testing and observations

I am unable to use the system (DS-7608NI-I2/8P and 4 x DS-2CD2347G1-LU ColorVu 4MP 4mm) above a bitrate of 1792 kb/s without the screen display together with top OSD of time and date freezing when mouse-scrolling the playback footage, however the lower scroll bar time ‘keeps up’ with the left mouse buttoned time bar scrolled movement. To clarify, it is only when speed scrolling (depressed left mouse button whilst moving across the blue time bar) that the display freezes. As soon as the left mouse button is released, the display instantly catches up and shows the correct scene and both OSD and blue time bar details match exactly.

However, all is well during hours of darkness when the system works happily with 8192kb/s and it is only when dawn/daylight approaches that it reverts such that subsequent playback of the footage freezes once again when attempting to mouse-scroll the time bar of footage recorded during hours of daylight.

Cam04 bitrate was increased in stages after 19:00hrs 15/11/2020 from 1792kb/s. Following each increase, the recorded footage was viewed (via mouse-scrolling the time line) and the bitrate was finally set at 8192kb/s. No ‘freezing’ was noted either up to or including this setting and all was well. NB It was dark at this time.

All the night-recorded footage was speed-viewed the next morning. All was good until ca dawn/daylight was breaking when all footage from 06:59hrs froze when mouse-scrolling the time bar (N.B. camera west-facing).

The test was conducted on the camera where the night time ‘residual ambient’ lighting (west-facing camera and hidden from street lighting) is so low that it triggers the supplement LED warm white lights (no IR on the 2347 cams). However, previous experience has also shown this ‘freezing’ behaviour to be common across all four cameras (the other three cameras use only ambient daylight and street lighting as the latter is sufficient such that the cameras’ supplemental LED lights are not triggered).

Observations from the first 22hrs of system behaviour identified a potential relationship between the lux level (and/or daylight colour temperature?) and the system’s ability to provide useful playback information when simultaneously scrolling the time bar. To clarify, the playback was ‘frozen’ from 06:59hrs until 16:34hrs at which point, it began to ‘unfreeze’, albeit in a jerky and broken fashion initially (but became consistently smooth by 16:46hrs showing 2 second increments), some minutes prior to the supplement LED lighting being triggered at 16:50hrs.

The test settings were allowed to continue to run but essentially, almost identical results were obtained for the following day where ‘unfreezing’ began at 16:46hrs (referenced above) and continued perfectly until dawn at 06:56 17/11/2020 when the footage became frozen once more.

I have tried various permutations of bitrate, video quality and frame rate settings throughout the daylight hours but have had no success

Discussion/thoughts

The DS-7608NI-I2/8P appears on paper to have sufficient bandwidth (80Mb/s Incoming and 256Mb/s Outgoing) to cope with the load from these four DS-2CD2347G1-LU ColorVu units so I am not thinking that bandwidth capacity is responsible. That said, this is my first experience with CCTV and unfortunately I am at the low end of a steep learning curve.

One positive from this - running at the increased bitrate over the last two days has however demonstrated a slightly improved video quality, albeit at the expense of not being able to conveniently speed scan the footage.

This following fact may or may not be relevant but whilst I have rebooted the system several times over the past few months and also following firmware updates, I have not conducted a factory reset and I have not noted this requirement in Hikvision documentation although there have been references to the need for this elsewhere.

Hardware and settings

NVR: DS-7608NI-I2/8P

Cameras: 4 x DS-2CD2347G1-LU ColorVu 4MP 4mm

HDD: 4TB Western Digital WDPURZ

4K monitor

I currently have all cameras set to 2560x1440 (4MP), Variable Bitrate, Highest Video Quality and Full Frame fps which during the day is ca 25. This value is ‘maintained’ on two of the cameras whereas the remaining two ‘adjust/modulate’ down to ca 12fps during hours of darkness which I think is due to subtle differences in the amount of night time street lighting available to each camera (facing NW, NE and SE).

Firmware: (Latest firmware installed from Hikvision Portal)

NVR V4.40.016, Build 200803

Cameras V5.6.5 build 200316

Video Encoding: H.265

UI: GUI 4.0/NVR 4.0

Many thanks for your time once again

There should be no problems with your system other than configured settings.

The first thing I'd say is that the 2347's cameras default shutter speed out of the box is 1/12 second (whereas most other Hikvision cameras are 1/25 sec) so if your recording at 25 FPS that won't help and is possibly the only problem.

Your minimum shutter speed should always be faster than the number of frames per second you are recording. When you fast forward review you see the I frames. By default these are set to every 50th frame, so at 25 FPS, there will be one every two seconds. The cameras don't go down to 12FPS on a night - what you are seeing is 25FPS at 1/12 second shutter speed so effectively you're seeing every frame repeated - the shutter is exposing the sensor 12 times a second but the camera is set to 25 frames per second. So first I'd check that which you can do in Display Settings on the I series NVR via the monitor. If you have Virtual Host enabled on the NVR you can login to each cameras webpage individually and check it there also.

The other issues that come up frequently and cause problems like this are:

1 - The main stream normal and event settings being different - they should be identical with regard to frames per second and bit rate
2 - Leaving the pre alarm recording set at 5 seconds (default) when the cameras are set to record 24/7. You can change this in Recording Schedule > Advanced

 

[JB1970]

Another point to note. You should have no need to "speed scan" the footage - it's not 1990 and that NVR has moved on a bit since time lapse VCR's! You can just use smart search.

Log in to the NVR via a web browser and go to:

Configuration > Video/Audio > Display Info On Stream and check the "Enable Dual-VCA" box for each camera. You can then do a smart search for line crossing, or intrusion in any part of the image and skip everything unrelated going forward.

 

[Stuart J]

Many thanks for your reply JB, it is very much appreciated.

Probably best that I reply in your point order.

Exposure time was set at 1/25.

12FPS on a night - confusing because the information tab icon on live view (7th icon from left on the pop up menu bar-Page looking with 3 horizontal lines) for Cam01 is oscillating between 14fps and 15fps and Cam 03 is oscillating between 12fps and 13fps.

Virtual Host is enabled and Cam01 and Cam04 just checked and confirmed to be set at 25fps via web browser IE and Full Frame Rate via NVR 4.0.

Main stream normal and event settings - these are identical - NVR 4.0 as you know warns of possible difficulties if they differ.

Pre-Record is set at 5s - what value do you recommend please for 24/7? (only in bold for highlighting purposes)

Enable Dual-VCA were all set and I have been using intrusion, line crossing and Custom to great effect for some months now - superb facility.

To clarify, I only speed scan all identified 'Red' events, not the blue time bar. The reason I prefer to manually speed scan these identified VCA events is that I can view either side (pre and post) red event to quickly and conveniently examine any lead up and post activity so that nothing is missed before the system automatically 'high tails it' to the next event. By the same token, I can also manually move on where a red VCA event is of no further interest that otherwise would have been unnecessary to sit through.

Many thanks once again JB

Regards

S

 

[JB1970]

Many thanks for your reply JB, it is very much appreciated.

Probably best that I reply in your point order.

Exposure time was set at 1/25.

12FPS on a night - confusing because the information tab icon on live view (7th icon from left on the pop up menu bar-Page looking with 3 horizontal lines) for Cam01 is oscillating between 14fps and 15fps and Cam 03 is oscillating between 12fps and 13fps.

Virtual Host is enabled and Cam01 and Cam04 just checked and confirmed to be set at 25fps via web browser IE and Full Frame Rate via NVR 4.0.

Main stream normal and event settings - these are identical - NVR 4.0 as you know warns of possible difficulties if they differ.

Pre-Record is set at 5s - what value do you recommend please for 24/7? (only in bold for highlighting purposes)

Enable Dual-VCA were all set and I have been using intrusion, line crossing and Custom to great effect for some months now - superb facility.

To clarify, I only speed scan all identified 'Red' events, not the blue time bar. The reason I prefer to manually speed scan these identified VCA events is that I can view either side (pre and post) red event to quickly and conveniently examine any lead up and post activity so that nothing is missed before the system automatically 'high tails it' to the next event. By the same token, I can also manually move on where a red VCA event is of no further interest that otherwise would have been unnecessary to sit through.

Many thanks once again JB

Regards

S

Ok - good that you checked it directly on the camera as well as sometimes a change made on the NVR doesn't get actioned on the camera. In that respect double check that the video settings - fps and bitrate are showing correctly on the cameras webpage as well.

When you hover over that info icon and see 14-15fps can you confirm that it's also showing Main Stream as the stream type. It's not unusual to see it drift 1 either side of your programmed fps there but I've never seen it that far out. And I take it you're recording the main stream?

If you're recording 24/7 then you can set the pre record to 0 seconds as it's only needed when you're recording motion only and there's no need to be buffering the video that you're already recording, and the post record can be at 5 (or 10) seconds (gives you enough time to click Normal before it skips to the next) - the event will still be there and will still play the 5 seconds leading up to it during smart playback.

On your last point the way I prefer to view the smart events... I set the playback to skip non related video and let it skip from marker to marker. You'll still get the 5 seconds leading up to the trigger and if at that point I see the trigger is something I want to watch, I just click to Normal playback. Once I've seen all I want of that event I click Smart again and it jumps to the next event so there's never any need for the fast forward. It's much easier to toggle between Smart and Normal this way while reviewing events. If I want to replay a second time, while still in Normal I click the skip button to jump 30 seconds back.

With all the above in mind, have you always had these issues? Are you confident that your cabling is terminated correctly and to a high standard? Apologies for asking that but without knowing your experience I don't want to overlook the obvious. A number of years ago I started as PM with a new company and went to visit a large city wide IP installation that the company was on with, connecting various tower blocks CCTV systems to a central control room via long range wireless bridges. During commissioning we were having all sorts of issues with dropped connections and awful performance. When I went to the immaculately dressed equipment racks I discovered that the lead engineer had crimped every connection the same - Blu/Whi, Blu, Ora/Whi, Ora, Grn/Whi, Grn, Brn/Whi, Brn....He thought as long as they were wired the same at each end it didn't matter!

 

[Stuart J]

Hi JB, thank you very much for your reply once again - brilliant :-0)

Earlier this morning (daylight 09:29hrs) I set all cameras to 2048kb/s then left them for a while to collect data. When later reviewed, I was pleasantly surprised to see that all was well with no freezing so I then increased Cam02 and Cam04 to 3072kb/s. However Cam02 and Cam04 were not having any of that with freezing occurring immediately. I then set all four cameras to 2048kb/s and as at 12:35hrs when recordings were reviewed again, all was well so I am leaving at that setting until at least after dusk to see if anything happens although the previous tests showed that they can handle 8192kb/s at night so I am not expecting a problem; just to recap it is only daylight when they freeze at the higher bitrate.

Fps and bitrate are showing correctly on the cameras webpage as at 12:53hrs (25fps and 2048kb/s). I have frame rate set to Full Frame on NVR 4.0 which I note is not present on the web, the max here is 25 tops. Do you think that the Full Frame which can be seen on occasions to be higher than 25 is also responsible for the fps automatically modulating down to ca 12fps and 14fps on Cam01 and Cam03 during hours of darkness in an attempt to adhere to an internally set Hikvision algorithm?

Now this brings me to an observation which I find strange (as a novice) and that is on the live view parameter box where fps, bitrate, H.265 etc is displayed, the bitrate on any of the cameras change wildly every second (much like the frequency of the tick tock of a clock).

I have taken a video of Cam02 information parameters a short while ago and the following contains the second by second display in "Kbps":
3880, 237,3885, 286,4015 and 4022; (please see attached still of 546Kbps whilst set at 2048kb/s). This is a typical data set and common to all four camera displays. It can be seen that in this short 6 second series, the minimum was 237kbs and the maximum was 4022 and this is with a setting this morning of 2048kb/s. For it to wildly fluctuate to this degree appears odd to me. Just to quantify, this is controlling from the setting of 2048 to (plus) +96% and (minus) -88%. I think that the effect of this can also be seen when zooming (digitally) onto a dark surface where the pixellation/noise (wavy random shapes) also 'dance'. I zoomed on the test footage of a few days ago when it was set at 8192kb/s and that phenomena had all but disappeared.

The following hopefully answers your questions from yesterday evening:

Fps and bitrate are showing correctly on the cameras webpage: Addressed above but repeated here for completeness. Yes, all fps and bitrate values are set as per NVR 4.0 with the subtle difference that the web browser table tops out at 25 whereas the NVR 4.0 has the additional Full Frame increased setting above the 25fps value.

Stream Type; Yes it is showing the Main Stream that I am recording.

Set the pre record to 0 seconds - Brilliant, thank you, I will do that.

Set the playback to skip non related video and let it skip from marker to marker - I will give that a try, thank you. Because Smart, unlike Normal and Custom, will not allow more than one camera view, I quite often switch to Normal when wanting to view two cameras simultaneously on playback which is very handy and then revert to Smart when done.

Have you always had these issues? Sadly yes and if there is a problem with the NVR in contrast to it being a configuration issue, I would naturally want that to be rectified under warranty.

Are you confident that your cabling is terminated correctly and to a high standard? Absolutely no need for apologies :-0)
Short answer is yes I am confident. I used Duct grade (not easy to use) UTP Cat 6 full copper (not CCA) throughout, together with pass-through type RJ45 connectors (absolute dream to use) and attempted to adhere to no less than 7 bend radii when installing the cables. Absolutely no cabling is visible whatsoever from the outside with the 1273ZJ-140 lantern brackets housing every mm. I finally checked all cable runs with the RJ45 LED integrity tester and then used the waterproof connectors as provided by Hikvision on every camera .

Lead engineer had crimped every connection the same - Blu/Whi, Blu, Ora/Whi, Ora, Grn/Whi, Grn, Brn/Whi, Brn.... :-0) :-0) :-0) Oh dear.
Mine are all Or/Wh, Or, Gr/Wh, Blu, Blu/Wh, Gr, Br/Wh, Br (left to right with tab uppermost).

Lastly, do you think there would be any mileage in a factory reset of the NVR as referenced in my first 'penning' is this really necessary after every firmware upgrade because I have not seen that requirement stated by Hikvision? I must admit that I am somewhat reluctant to reset as it conjures hassle unless of course I am misinterpreting what is involved and the impact regarding reconfiguring the system.

So JB, where do you think I am with this as it appears to be a strange one. For the system to be intolerant of 8192kbs during daylight hours and then miraculously accepting this setting at dusk and happily running with it until dawn when it refuses once again, is a real head scratcher.

Many thanks once again.

Regards

S

 

[JB1970]

There's no difference between full frame and 25fps - as you've already found it only appears on the NVR local menu as opposed to the web menu. It's completely normal for the variable bit rate to fluctuate like that. The I frames are set bey default to every 50th frame. At 25fps every 2 seconds that bitrate will "burst" as it shows that I frame (full frame) whereas those in between are only showing the comparative differences in the image, hence they are much smaller. The displayed bit rate will reflect the amount of motion in the image along with noise being interpreted as motion (as it's changing the pixels)

CAT6 - OK. I never understand why people install CAT6 rather than just good quality branded CAT5E. CAT5E is good for Gigabit or 1000 Mbps while in general mode you cannot set a camera to higher than about 16 Mbps. Overkill really and you're far more likely to make a bad crimp.

You may be at the point of trying a factory default. It's not usually necessary but it's the quickest way to get back to an out of the box state on everything. If I were going that route I'd default the cameras also. I'd probably try patching the cameras direct to the NVR rather than on the installed cables to prove that it's not a cabling issue and I'd maybe try switching the hard disk with a spare to prove that it's not that.

 

[Stuart J]

Thank you, much appreciated; good to know that the fluctuation is normal.

The Cat 6 seemed a good idea at the time, it was reasonably priced, was full copper and not copper coated aluminium but the duct grade was a bad move although at the time, I had future plans to install a camera remotely at some time in the near future so I reasoned that duct grade was the way to go - wrong :-0).

I was probably fortunate in only making one bad crimp but at least they all tested well to the point of installing the waterproof connectors.

The common denominator is daylight to which I keep returning. If either cabling or HDD were the problem, I am struggling to understand why darkness would 'cure' this transient but persistent freezing problem until dawn the following day, at which point, it would revert to freezing again.

Many thanks once again for all your advice and time JB, I will continue to 'play' although camera patching will wait until the weather is more conducive :-0).

Take it easy.

Regards

S

 

[fullboogie]

The only thing that comes to mind re: the daytime issue is that you're pushing a lot more info in daylight hours - movement, shadows, clouds, people, etc. Nighttime is usually kicked into black and white with very little of the above motions. What all this means I don't know, but maybe something to consider in your investigation?

 

[Stuart J]

fb - Thank you for your input. :-0)

Re night time, I keep the 2347s in full colour and make use of its technology and light-gathering ability of the F1.0 lens. There is only one camera that is affected by insufficient street lighting and so the soft white LED supplement lights automatically switch to illuminate its FOV adequately (15% setting equates to ca 1w extra).

Just on that point for anyone interested, the 2347s consume a nominal 4w each during the day and this figure drops to ca 3.2w to 3.4w at night (for the specific configuration and siting of these cameras). For the camera that is hidden from street lighting, the POE screen shows that the total camera power consumption is 4.2w-4.3w with the LEDs on; on average, there is ca 105w of unused NVR powering capacity remaining for additional cameras both day and night. For completeness, the power consumed by the NI-I2/8P with 4TB40 PURZ HDD and 4 x 2347 ColorVu units is 37.5(4)w.

The duty of two of the four cameras is to monitor 'still' areas with negligible movement with the exception of the occasional bird, squirrel or cat etc so the change in activity load/processing between night and day I would have thought is small. Now the question of the impact due to the change in processing requirement when daylight is introduced is an unknown and I would be very interested to know if this has been quantified somewhere and put into bandwidth terms.

At this moment in time, I just do not know if the culprit is a
a) a limitation of the equipment to work in the daylight at the quoted bandwidth settings for the DS-2CD2347G1-LU ColorVu 4MP 4mm cameras or
b) a configuration issue or
c) a fault.

If it was c) fault with the finger pointing at the cameras, it would have to be in all four cameras as they all react that way and as such, it is statistically unlikely.

This would then point to the NVR DS-7608NI-I2/8P with its single 4TB WD40PURZ HDD (but not necessarily). However, the kit works flawlessly at night, where the other two cameras can handle a reasonable amount of night time traffic and pedestrian activity without issue and all at 8192kb/s (which is possibly double the actual suggested setting by some).

This then leaves (unless I am mistaken) a question mark over the firmware and only Hikvision could address this?

I would be very interested to know if any forum members with 2347 cameras experience the same freezing issue and at what bitrate settings?

Many thanks fb.

Regards

S

 

[fullboogie]

Stuart, I've read many threads about similar problems that were caused by wiring and/or termination problems. Insufficient connections provide marginal bandwidth during hours of low activity or night, but show themselves as problematic during the day. It may not be a power issue but a throughput issue. Again, I've not experienced this so I'm only passing along the info. That's where I was going with my post above.

Can you pull a camera down, bring it inside, and reproduce the freezing issues with a premade cable? Or do some experimentation that somewhat duplicates what the cameras experience when mounted outside in an effort to reproduce the problems? I hope I'm not sending you down a rabbit hole.

 

[Stuart J]

Hi fb, very interesting and thank you for your reply and emphasising your point - Insufficient connections/marginal bandwidth - duly noted, thank you.

Regarding my second paragraph which addressed power consumption, the main purpose of including it was for those possibly contemplating a similar set up to mine which hopefully quantified both the running costs but more importantly, how much NVR POE remained for additional cameras (even a 'hungry' PTZ - -please, please Santa!).

Yes, weather permitting, I am able to remove a camera for testing and place it on an internal window sill facing outwards to 'grab' as much daylight as possible which would duplicate in-situ recording. It would certainly confirm or exclude the cabling as faulty within minutes if the camera was tolerant of the higher bitrate setting.

However, the system will record perfectly at 8192kb/s both day and night and will play back perfectly BUT it will only allow speed scrolling of the night time footage at this high bitrate, NOT the daytime daylight footage; if there is no manual intervention (i.e speed scrolling), it will play back perfectly if left alone.

It would be prudent if I reiterate and summarise the issue and observations for all readers, in the hope that they have not lost the will to live by now!

1/ System recordings made during daylight and night time hours at low bitrate (2048kb/s max) play back perfectly.
It also maintains the ability to manually speed scroll the time bar without the screen freezing (i.e. The OSD maintains synchronicity with the time bar).

2/ System recordings made during daylight and night time hours at normal to higher bitrate (8192kb/s) also play back perfectly.
However, whilst night time footage play back will allow speed scrolling, daylight footage will not and will freeze the screen until the left mouse button is released. At this point, both OSD instantly catches up with the time bar parameters and playback resumes perfectly until speed scrolling is once again attempted.

To summarise, if this 'quirky' behaviour is due to the integrity of my connections, then it applies equally to all four cable runs despite the fact that they have passed the electronic connection integrity testing of all 8 strands following final crimping. The only positive that I could take away from this as being the fault would be that at least I was consistent :-0).

Many thanks once again fb, I very much appreciate your views - I just need to watch out for those rabbit holes now :-0))).

Take it easy.

Regards

S

​

 

[fullboogie]

I do think I misread your post and misunderstood the nature of your problem - I thought it was a live viewing/recording issue. Apologies.

One final note - I too confirmed all connections with a magic gizmo. I had a bad connection that showed as good, as that gizmo only shows continuity. Good luck!

 

[JB1970]

As @fullboogie has said your continuity test will only tell you that all pins are connected - it won't measure skew, near end crosstalk, far end crosstalk etc, etc as a cable certifier would (they're a steal - you can get a decent one for circa £7.5K!). I did the C & G qualifications for fibre optic and copper cable installation years ago. Unlike a continuity tester, when you certify a cable link it checks multiple parameters against the standard and gives a simple pass or fail - if it fails and there's nothing obvious, you install a new cable point to point - you can't improve the readings. As well as maximum radius of bends etc, there needs to be no more than 13mm of "untwist" at the termination points.

In one of my earlier points I talked about CAT6, as it's really not ideal to be crimping standard RJ45 connectors directly to it, as the plastic barrier separating the cores will lead to the pairs potentially being crushed together and causing a near short. It should ideally be kroned into a jack/faceplate and patched from there. So don't rule out the cables being an issue. I'm not saying that is the issue but it's a possibility. Have you tried disconnecting all but one camera and running through them, to see if the fault remains with only one connected, or whether it gets worse as you add the other three? Or you could just stop the recording on three of the cameras. If the issue remains when only one camera is connected, a relatively easy way to check it would be to run a temporary long CAT5E patch between the NVR and that camera.

I have the I series NVR with the same firmware as you, the same model color vu with the same firmware as you and eight other cameras (2 x 2mp, 3 x 4 mp, 3 x 8mp) on my system - all recording at 25fps H265 (20fps for the 8mp) and there's no issue. That lot totals only 71 meg incoming bandwidth out of 160 available (80 on your 8 channel) so the equipment you have is certainly up to the task.

I've had some issues with frame drop on a couple of 8 megapixel models recently - and like yours it only happens dusk til dawn. I added a spare hard disk, changed the storage mode from quota to group and assigned the two problem cameras to the additional disk. The issue has all but disappeared hence the reason I mentioned your hard disk.

 

[Stuart J]

Thank you fb - duly noted - never had this trouble with the old Wheatstone bridge apparatus :-0))))))

Thank you also JB, I was about to reach for Google Translate when I saw "skew, near end crosstalk, far end crosstalk etc etc" :-0))

Cable certifier - Tempting but after careful consideration, I will give the £7.5K cable certifier a rain check - payback for me could run into several life times.

"I did the C & G qualifications for fibre optic and copper cable installation years ago" - sadly a MSc. Chem. Eng. is of little use with this issue unfortunately :-0(( but I am learning all the time :-0)) and your help (and fb's), ideas and advice is very much appreciated, thank you both.

"There needs to be no more than 13mm of "untwist" at the termination points".
I had read of the need to minimise this prior to installation and was mindful of the requirement and as such, all connections made, were complied with. I have just measured an additional computer-to-hub lead that I also installed and this indeed measures 11-12mm (outer sheath end to centre of brass crimp pins.

"I talked about CAT6, as it's really not ideal to be crimping standard RJ45 connectors directly to it, as the plastic barrier separating the cores will lead to the pairs potentially being crushed together and causing a near short."
The RJ45 connectors used were for Cat 6 (not standard) with a slightly larger lead-in to house the marginally larger diameter of the outer sheath of Cat 6 and as I previously referenced, were the pass through type.

"I have the I series NVR with the same firmware as you, the same model color vu with the same firmware as you and eight other cameras (2 x 2mp, 3 x 4 mp, 3 x 8mp) on my system - all recording at 25fps H265 (20fps for the 8mp) and there's no issue."
1/ What is your bitrate setting on your ColorVu?
2/ What sort of live bitrate values are you seeing in the Information box for the ColorVu?
3/ When you say "no issue", so as to be absolutely clear, have you actually tried speed-scrolling the time bar whilst watching both the screen and the OSD and ensuring that there is no display freezing whilst moving the time bar with your mouse with left button depressed?

Tests conducted this morning (Daylight conditions)
1/All cams set to 8192kb/s - all playback is fine BUT screen and top OSD freezes BUT only when speed scrolling with mouse is attempted.
2/ All live bitrate values peaking ca 12000/13000kb/s on all cams - could a problem still exist with the cabling but still achieve these live value?
3/ Complete controlled shut down of the system for ca 1 minute and then restarted.
3/ System had retained the 8192kb/s setting so I reduced Cam01 bitrate to 3072kb/s - subsequent data recorded on Cam01 was fine BUT again, froze when speed scrolling with the mouse.
4/All cams then set down to 2048 kb/s upon which, full happiness was once again restored, providing speed scrolling capability of the time bar without any freezing whatsoever.

"Have you tried disconnecting all but one camera and running through them, to see if the fault remains with only one connected, or whether it gets worse as you add the other three?
I will try that tomorrow when I have daylight again.

"I've had some issues with frame drop on a couple of 8 megapixel models recently - and like yours it only happens dusk till dawn"
My issue is the opposite of this JB in that it only happens during daylight hours and begins at dawn and persists until dusk.

JB - Just to reiterate specifics from the above if I may:

a) What is your bitrate setting on your ColorVu cam please?

b) Have you actually tried speed-scrolling the time bar whilst watching both the screen and the OSD and ensuring that there is no display freezing whilst moving the time bar with your mouse with left button depressed?

c) Live bitrate values are peaking ca 12000/13000kb/s on all cams- could a problem still exist with the cabling even though I achieve these live values or is it not as simple and clear cut as that?

Many thanks.

Regards

S

 

[JB1970]

My issue is the opposite of this JB in that it only happens during daylight hours and begins at dawn and persists until dusk.

That was a typo of mine - I meant I also only had the issues during daylight - it stopped on a night at sunset.

a) What is your bitrate setting on your ColorVu cam please?

8196 kbps is set for all of my 4mp cameras (ColorVu's included) streaming at 25fps. It is a variable bitrate and the actual value will differ according to the I frame interval (full frame refresh), the frequency of movement in the scene and the amount of pixels that are changed between each I frame. The camera will attempt to keep the maximum bit rate below that which you set taking the compression/quantisation (quality setting) into account. However it will happily burst over that maximum if it needs to - regardless of how high you set it. Live bit rate values peak at much the same as you've mentioned 12 - 13000 kbps

b) Have you actually tried speed-scrolling the time bar whilst watching both the screen and the OSD and ensuring that there is no display freezing whilst moving the time bar with your mouse with left button depressed?

No not as yet. I've only realised just now what you mean by "speed scroll" I think. I assume you're holding and dragging the timeline rather than using the x2, x4, x8 controls. I've never used the timeline in this way but will have a look to see if I can replicate the issue on mine and if so whether it is solely the ColorVu that exhibits that behaviour (I doubt it). It wouldn't surprise me if the interface does freeze when you do that, as it's still encoding 20fps from the other cameras and writing that to disk while attempting to populate the screen above the timeline with thumbnail images. I'd ignore that behaviour (for now) and solely concentrate on whether you can record the cameras at the desired frame rate (without dropped frames) and bit rate settings.

 

[JB1970]

Ok - so now I know what you're trying to achieve - review the footage at speed, by zooming the timeline to 5 minutes width and dragging it. I've taken a look at all of my nine cameras of different models and get varying results. Of the nine cameras I have, only the two 2 megapixel models will reliably allow footage to be scrolled in that manner day and night. The 4 megapixel cameras (of 5 different models) all allow it during the night but not day while the 8 megapixel models will allow it neither by day or night.

However, what you're describing is not a fault with either the camera or the NVR and by the sounds of it your system is working just fine so you can pretty much disregard all of my previous suggestions of fixes, as I thought you were losing frames! This is just a limitation on what the NVR can process simultaneously. There will be a limitation on the size of the image that it can show that way and the daytime images are exceeding that limit. As examples of this, the K series models on version 3 firmware could only display the playback thumbnails of cameras up to and including 3 megapixels (even though they will happily record 8 megapixel models at 20fps) A 4 megapixel cameras thumbnail would simply display "no resource". The I series on multiscreen will reach a point where you see "no resource" while trying to view all of the cameras main streams simultaneously.

I'd just set up the cameras for the quality, fps and bitrate that you need and use a different method for reviewing the footage. The single most important thing that system needs to achieve, is to reliably write every single catered frame to the NVR hard disk.

 

[gp116126]

I have a 7608k2 8p with 6 g1/g2 cams. I run all at max. I also use mouse scroll as described above and have one can that won't do it anytime.. I agree it would be a an nvr resource issue. To test this disconnect some cams then scroll tge ibes causing tge ussue. They should work okay as there is more NVR umph available as not all cams are running.

 

[Stuart J]

Hi JB, you are indeed an officer and a gentleman - superb, thank you so much - it is a relief to learn that there is no fault which is really good to know.

Hi gp, thank you also for your input to which I would like to respond in a moment :-0)

JB - Before I had read your latest post, I had done as you suggested and conducted a test whereby I stopped the cameras recording mid morning.
I decided to set the bitrate on all four cameras to the next level up from 2048kb/s i.e. 3072kb/s because I knew that that was the value at which the phenomena (not suspected fault any longer) would show itself and I wanted to give it a fighting chance rather than 'hitting it' with 8192kb/s .

1/ I stopped recording on Cams 01, 03, and 04 and allowed 02 to continue and save footage - the viewed footage 'refused' to mouse speed scroll despite only one camera recording.

2/ I then started recording on Cam 01 and repeated the above but obtained an identical outcome.

So as has been verified, speed scrolling 4MP ColorVu cameras will not work with bitrates set at 3072kb/s and higher without the picture and OSD freezing. However, it will work at 2048kb/s and 1792kb/s both day time and night time lighting conditions with the four 4MP units.

gp - "To test this disconnect some cams then scroll"
Whilst I accept that the 'recording cessation' method that I employed above would not necessarily be equivalent to a physical disconnection from a NVR resource viewpoint, it did prove that the system could not even cope with just one camera recording at a setting of 3072kb/s let alone several. I will however repeat sometime using the disconnection method for completeness.

However, I do also accept that just because the other three cameras were not recording at the time, processing of some kind was no doubt still being carried out by the NVR and cameras, with the latter still being on line and live and as such, resources would still be consumed. This brings me back to JB's following statement:

JB - "That lot totals only 71 meg incoming bandwidth out of 160 available (80 on your 8 channel) so the equipment you have is certainly up to the task."

Related to the disconnection method referenced above, I am reluctant to just disconnect a camera from the rear of the NVR other than after a controlled S/D of the NVR - are my concerns valid please?

On paper, your 7616 had a further 89 megs available to 'dip into' but I can only assume that it is not as simplistic as that and there are probably specific duty resource allocations made within the system that impose a limitation to where the available megs may be used; speed scrolling the time bar is not regarded as a priority.

Finally, I would like to repeat my thanks and gratitude to JB, fb and gp for their invaluable help, advice and knowledge sharing, it has put my mind at rest and if nothing else, has served to share a phenomena/idiosyncrasy of the system.

JB - "I'd ignore that behaviour (for now) and solely concentrate on whether you can record the cameras at the desired frame rate (without dropped frames) and bit rate settings."
Just to confirm, my system works fine at 8192kb/s and full frame rate (ca 25fps) with no dropped frames evident.

I totally concur with JB's final paragraph regarding single most important thing but - - - - - - - however I will very likely need counselling to ween myself away from speed scrolling :-0)))))

Take it easy gents and stay safe.

Very best wishes

Regards

S

 

[gp116126]

I think you doing too much thinking mate. Factory reset plugin one by one should work if you don't then it's a hardware issue