CCTV DVR and it's software program stops communicating

videobruce

Limp Gawd
Joined
Jan 21, 2005
Messages
412
I have a CCTV DVR (Speco Tech if that matters) that uses a software program to connect to a PC. There are two basic modes; Live TV and Playback. Both functions are pretty much self explanatory.
I was having issues with the 1st unit I received (new) but that one did NOT have this issue. The 2nd one did. No changes on my end, thou I did update the F/W in my Router (running DD-WRT). I reverted back to the F/W version that was in the Router, but NO change. Problem remained.
I uninstalled the software and re-installed it, but no change. Rebooting the DVR makes no difference. I contacted the manufacture (US based support for a change), but they claim none of their units do this (of course), but they did point a finger to the PC (of course, it couldn't possibly be their fault) which I was waiting for them to do that. Except for the fact the 1st unit did NOT have this issue, it had numerous others not related.

If I just open and run the program without changing the 4 camera view, all is fine, data continues to be sent, but when I choose any specific camera, then return to the 2x2 (Quad) view the data stream just dies out and the images are frozen. If I click back to any single camera the data may return, but it usually dies out after a minute or so. Closing the program and re-opening it brings it back to square one.

I use a program called 'Bit Meter' (similar to DU Meter) to continuously monitor LAN & WAN status as to data flow in and out. This is how I determined it was a data flow issue. (I have used one or the other of these for well over a decade, great troubleshooting tool !!). The max data xfer rate is 10Mb/sec. thou it's usually around 5-6 Mb/sec.

Now, to add to the mystery; if I change to 'Playback', the problem seems to go away (AFAIK). Data flow is back and it doesn't seem to be affected my any actions I do.
I don't know if the software used a different port between Live View and Playback, I believe it's the same. That was the only area that may explain this that I could think of.

Details;
Static IP addresses !!

Win 7 Pro x64,
AMD based Gigabyte MB, FX8350 processor, 8GB of memory, wired Ethernet,
NO A/V or local Firewall programs running, no suspicious processes or services running. I use ProcessHacker (poor name choice), it's a superior substitute for Task Manager).
The program does install MS C++ 2010

Any ideas out there??
 
Last edited:
I suspect that the dvr firmware version was different between the first one and second one, and that's the root cause.
 
  • Like
Reactions: AP514
like this
I and they would of notice that. They confirmed the F/W and S/W versions when I talked with them.
These are a older, discontinued model that was replaced with a almost identical version (at least visually). How about this C++ 2010, when it comes to M$, I would first put the blame there.
What gets me is why isn't the Playback function affected? One would that would be the 1st before Live View. :confused:
 
I and they would of notice that. They confirmed the F/W and S/W versions when I talked with them.
These are a older, discontinued model that was replaced with a almost identical version (at least visually). How about this C++ 2010, when it comes to M$, I would first put the blame there.
What gets me is why isn't the Playback function affected? One would that would be the 1st before Live View. :confused:
I've rarely seen any company in the last 30 years that has the type of attention to detail to confirm firmware versions are the same--especially if it is an 'updated' product. More than likely there's something in the 'updated' product that changed that broke it all. So now you can continue the upgrade domino effect to use this DVR or demand that they give you an older one or fix yours and get it back to you. I've actually resorted to ebay to find old working units for some of my security workflows.
 
The F/W number also has the date in it so I know it's the same. I also remember seeing it on their website. It ended in "20200513"

Could it be something flaky with that M$ C++ 2010 that it snuck in there w/o notice??
 
The F/W number also has the date in it so I know it's the same. I also remember seeing it on their website. It ended in "20200513"

Could it be something flaky with that M$ C++ 2010 that it snuck in there w/o notice??
So if it's not the hardware and you think it's something that's new on the software, I guess the only thing left to do is rebuild it all from scratch. :(
 
No, I never implied it wasn't the hardware, just the opposite which is why I sent the 2nd one back for exchange.
I don't know what you mean by "rebuilding from scratch"? Other than replacing the DVR. :confused:
 
No, I never implied it wasn't the hardware, just the opposite which is why I sent the 2nd one back for exchange.
I don't know what you mean by "rebuilding from scratch"? Other than replacing the DVR. :confused:
Rebuild your win7 system and install the dvr software from scratch.
 
  • Like
Reactions: AP514
like this
If it was the O/S, then why did the 1st DVR NOT have the problem??
Look, there's a potential problem with anything that changed. Hardware change=suspect, windows since it always changes=suspect. If you're convinced the hardware isn't the issue, it's the software. If you think the software isn't the issue, it's the hardware. It really all boils down to this no matter how you slice it. Why doesn't matter as many times you'll never know 'why'.
 
I was convinced it was the hardware since as I stated above, the 1st unit didn't have the problem. AFA the O/S maybe, but that major surgery is a very last resort.
 
I was convinced it was the hardware since as I stated above, the 1st unit didn't have the problem. AFA the O/S maybe, but that major surgery is a very last resort.
And you can't get another unit like the first one, so you'll need to start over for the second unit or have them swap it again if you're convinced it's bad.
 
I have already sent the 2nd unit back for an exchange. I will see how that is or should I say what is wrong with it. Both units have crashed, the 1st one three times, twice with resetting the clock back to 2016.
 
Well it's not, the 3rd unit now drops the connection with the Router after 20-30 seconds after rebooting. It's done it 4 or 5 times. And the connection never returns. The activity LED's on the Ethernet port on the DVR both show active (and I have changed the cable).
The question is; is there anyway that a Router would reject or 'time out' a active device either with a static IP or a DHCP address?? Or for that matter the device itself? There are no conflicts that I know of, this isn't a huge Network, usually5 or 6 devices active at a time. :eek:
 
If the router has the mac of the old dvr stored, then yes. I would reboot the router (and the dvr) if you haven't.
 
Is there enough room on the hard drive? Do both units have the same amount of RAM?
 
Long story short, it isn't the Router, it's the O/S. I tried the software on my W7 Laptop and it appears all is well. I even tried a different network card.
So off to a different sub forum with the problem.

I would still love to know why this device doesn't show in the routers active client list. :mad::rolleyes:
 
Not really on the cause, just narrowed it down to the O/S which probably will be impossible to find. I do have a recent image I plan on restoring it back to.
 
I didn't respond to your post. Exactly what do you mean "speed & duplex"?? Where?
You said the devices in question was connected via ethernet. I was asking about the speed/duplex setting of the NICs. In modern systems these should both be set to auto. Most vendors will allow hardcoding these values in their drivers because there is a contingent of old school folks that recall some early compatibility issue with autodetect and insist on hardcoding these values even though the spec dictates auto. I've seen more issue than I can count when these idiots hardcode to the point where I got one our SEs fired over it after he would not stop causing problems despite being warned repeatedly.
 
Back
Top