PeteCress

On a consumables, I would ask first. I bought three Ryobi batteries (about eighty bucks each). One failed way prematurely, and I was out of luck because the warranty was based on calendar time instead of usage/charge cycles (which was very low).

Check those cameras network config, make sure they have working DNS. If one assumes that, somehow, Ping gets to an address differently than the code behind the camera's Test button this seems logical. But in fact, the problem cams all point to the Comcast cable modem/router/switch for their DNS server - as the "good" cams at home point to my Cisco router. Still, I'm going with the general idea: something mis-configured in the Comcast device that is getting in the way of the camera's Test button code. I will find a Comcast forum and try posting that idea.... and report back.

I've got seven of these things. Five of them are here at home behind an ordinary router connected to Verizon FIOS and time synch works a-ok: pool.ntp.org, port 123 Two of them are down at the New Jersey shore behind a Comcast cable modem/router/switch. Same time server address, same port... and they both throw "Failed to connect the test server" (sic) when I click the "Test" button. I can link to both cams from home. ??

It is reasonably common that NTP servers are configured not to respond to ping requests, so no response to ping is not a good indicator that the NTP server is not responding to NTP requests. Some NTP servers have limits on the polling rates, so manually testing can give a result that the NTP server is not responding, but it is not responding by design. But it all still begs the question of why the same make/model cam at home can reach pool.ntp.org while it's analog at another site cannot - even though pool.ntp.org can be pinged from the problem site.

Almost the same result. "Almost" because time.windows.com does not even work from home. I should have added that pool.ntp.org is pingable - both from the problem site and from home, whereas time.windows.com is not pingable from either site.

Bingo!... I had no idea.... Thanks.

I've got 7 of these things. Just went through the exercise of upgrading the firmware to v5.2 on all of them. All are working, but one acts differently from the other six. To wit: It's Configuration| Basic Configuration | Video/Audio | Max Bitrate does not drop a list of bit rates whereas on the other six cams that field drops a list of bit rates . Configuration | Basic Configuration | System | Time Settings lacks the "Test" button that the other six cams have One diff I can see is the cam's serial number: "DS-2CD2032-I20131130...." while the other six cams' SNs start with "DS-2CD2030-I2014...". I'm guessing this is it: just an older cam. But that begs the question of why the firmware update from the same digicap.dav file took differently. There seem to be a few other weirdnesses, but I have not taken the trouble to document them. Nothing I can't live with... but curious minds want to know...

I get this periodically - but I have not made any attempts. Just a nuisance by itself, but it is accompanied by various CAPTCHA schemes where, 9 out of ten times, the CAPTCHA is insoluable: I do the right thing, and it just keeps on throwing another CAPTCHA. Same results in both Chrome 39 and IE 11 Seems to happen in spurts. Have been unable to get in since yesterday afternoon... Tried a couple times this morning and failed. Now I just got past the Countries CAPTCHA... having failed it and another one many, many times. A problem with the board? Something with my system?

On all my cams, I have selected Constant Bit Rate - under the impression that it maximizes quality over Variable. On my HikVision cams, I have been fooling around with iFrame Interval, trying to clean up the clips. But when I went into Setup on another brand of cam (ACTi) I noticed that the iFrame setting goes away when Constant Bit Rate is selected and only shows up when Variable Bit Rate is in effect. The ACTi user's manual seens to imply (page 5) that Constant Bit Rate gives better quality than Variable only when the image is still and that, with "Large" amounts of motion or "Complex" scenes the image will be better with Variable Bit Rate. Seems to imply that iFrame interval is only relevant to Variable bit rate and that the cam is sending a complete image for each frame when it is doing Constant bit rate. Bottom line, it sounds like I should be using Variable instead of Constant bit rate for cams whose job is to record the movements of people. Have I got it right?

Sounds like we are back to there being no hard-and-fast answer and evaluating each camera/situation. The use of "Unlimited" bandwith was sloppy on my part. Instead of saying "Unlimited" I should have described a situation where: The radio link between server and cameras had a bandwidth of, say, 55 mB/s . The sum/total of all the cams running at Constant Bit Rate was, say, 35 mB/s . There was no other traffic on the link . The server mediates between people viewing and the cameras. i.e. a camera's bit rate it unrelated to the bit rate delivered by the server to the users over Internet connections. . We have almost a TB of drive space dedicated to clips and the server manages that: dropping old clips as space is required for new clips - like a dash cam in a car. This gives us several days of 5-minute clips back-to-back 24-7.... which is way more than anybody needs or wants in this application - which is basically to let windsurfers see how conditions are without calling the windsurfing shop's phone every five minutes on a windy day..... Although we *did* manage to save the hotel owner some court costs when we caught somebody in a lie vis-a-vis their injuring themselves stepping off the deck into the parking lot... -)

Suppose bandwidth were unlimited. Would you change the recommendation?

That was a good thread for me. Thanks. My takeaways from the first read: - There is no simple hard-and-fast answer to CBR-vs-VBR - Which works better depends, in part, on the make/model of the camera

3 identical cams, identical setups as far as I can see, connected to the same POE switch, and being served up by Blue Iris. One is working a-ok. Other two are showing very slow frame rates - sometimes zero with frozen video streams - albeit higher bit rates. Direct connections to the problem cams seems to support the idea that it's the cams and not something weird with BI. Only diff I can come up with is that the "Good" cam's Cat5e cable is fairly short - maybe eight feet max while the others' are more like 50' and a substantial part of that is excess and is coiled into 2 loops about 8" across and secured with wire ties. Before I drive 200 miles round trip.... could this be the problem? viz: http://tinyurl.com/kf4pbd2 Where "East" and "South" are the problem cams and "West" is the "Good" cam. FWIW, the BI presentation of the cams is at http://ExtremeSurfCam.DynDNS.org

Bit the bullet, drove down today, and found multiple issues: At the server site, I found a bad RJ45 connection on the back of the server PC. Swapped out the Cat5, and we went up to 34 MB/s on the test. Put the old Cat5 back, wiggling the connector.... and it stayed at 34. Probably should have done some cleaning, but the stuff was back at the cam site. . Back at the cam site I took down the POE switch, slathered all the RJ45 ports with cleaner then with some other goop... let it all dry, re-plugged, and now we have 55/55 Up/Down on the test. . Also back at the cam site, I noticed that the guy who re-mounted the Nano had left the mast twisted so that it aimed about 45 degrees out on the bay instead of along the shoreline at the server site. Straightened it out and noted a couple of dB improvement in "Aim Antenna", but no diff in LAN SpeedTest. . One cam still was not working after all this. It came up on a NetScan, but refused connection. Took it down, took it home with me, and now it's working A-OK. I've been through this with a couple of EdiMax cams.... they give trouble, then work after being brought home. Ultimately, both EdiMax's failed altogether and it looked like a boiled-over capacitor in each case. Maybe this HikVision cam is on the way out too... time will tell. Seems like all my overthinking and theorizing was for naught and that sSMith's observation is the winner.

Now that you have said it, that seems like a very likely cause. Historically, even inside the shack, we have had problems with router ports corroding. Somewhere along the line this year we had an episode of vandalism and somebody else re-wired the cams and the Nano.... and it looks to me like they did not replace the mastic tape I had on it around the Cat5 connection.... and I'm not too sure about the outdoor cam connections either. The presence of 4 cams while I'm running the test is probably confusing matters (6 MB/s uploading, 35 down...) but I have to wonder if there is a chance that corrosion on the right Nano Cat5 contact could affect transmission in one direction and not the other. As far as the Comcast cable modem/switch goes, it's the same setup that was in place back in August when I was getting 55/55 so, good or bad, I don't think it's responsible for the change. As far as two-way traffic goes, even if there were a way to make the radio link one-way, I could not do it because it also supports the shop owner's Internet access. I'm going to drive down there today or tomorrow and start re-plugging/swapping wires, adding mastic to any outdoor connections missing same, and probably spray some of RadioShack's magic goop on the contacts.

Maybe a bit busy, but I'm trying to keep it to one page: http://tinyurl.com/mkfmvcx Yes, I currently have no way to turn the cams on/off remotely.... the POE switch is just plugged in and that's it. Edit 2014 11-09 11:34: Several contributors to the Ubiquity forum say that the Ubiquity speed test is not reflective of real-world speed - partially because it uses UDP instead of TCP and therefore does not reflect packet loss. They recommended a separate utility and I'll download it and how it's results match up with LAN SpeedTest's. I am starting to suspect a particular run of cable and will try to prove that by swapping connections around so that the PC running the test gets a direct path to the server with no middlemen and no cams online.

Any thoughts on why the Ubiquiti speed test gives pretty good (50-55 MB/s) speeds and LAN SpeedTest gives such a low write speed?

HikVision DS-2CD2032-I cams, TrendNet 8-port POE switch. A pair of Ubiquiti Loco radios link the site to the server about .6 miles away. So much for the cable theory..... -) Thanks for saving me the trip. Just ran "LAN Speed Test" from a PC on the site against the server .6 miles away, and maybe I have something: back on 8/11 the same test showed 55/55 MBps Write/Read, but just now it's only showing 7/38 Write/Read. Clearly a significant diff, and now that I'm spending some more time staring at the frame rates, I see that the problem cam moves around. Right now "Parking Lot" is down to 5 FPS and the other three are ticking along at 20. OTOH, Ubiquiti's "Speed Test" built in to the radios shows 57/57 Mbps, and re-running LAN SpeedTest immediately afterward shows the same 7/38 speeds. OTOOH, when I add up BI's idea of each cam's bitrate, I get 1,411 KB/s which I think comes out to 12 Mbps.... The difference in the two tests aside, I guess I will spend some more time monitoring the radio link's speed and see if I can find a correlation between 55/55/Good Performance and sub-10/sub-55/Problems.

This probably means I am missing something, but it seems to me like there is a need for shutter speeds higher than 1/30th of a second - and the concurrent higher ISO values. Not needing high frame rates, I can see: chews up bandwidth and motion is not enhanced. But, for surveillence, it seems like shutter speeds of 1/60th, 1/120th and even 1/250th would be useful for identification of moving targets. And, at night, higher ISO would really help. So... what am I missing?

Got a couple of 150-watt motion-triggered floods and when they are on and I force the cam into daylight mode the image becomes about 3 times better as color kicks in. So if I could get it to switch over automagically when those floods come on it would give much better clips. I`ve got Sensivity =High and Switch Time minimized, but no luck. Anybody been here?

Looking at http://ExtremeSurfCam.DynDNS.org, "Beach - East", note the awning. Beneath that awning are gear lockers that occasionally get their locks snipped off and stolen from. The owner put in motion-triggered floods on the same pole that the cam is on but, of course, if the awning is left deployed at night, there is no view of the gear lockers beneath it. I'm thinking the path of least resistance is another motion-triggered flood mounted just under where the awning attaches to the building plus a "Stealth" cam down at that level..... or maybe one below the wooden deck looking up. Problem is that the local wildlife, sometimes equipped with bolt cutters, cruises that area and will steal anything not nailed down - and a few things that are... Does anybody have a technique for deploying an el-cheapo cam so that it does not look like a camera?

I like it! Right up there with the cam some guy put in the navel of the subject in a Rigid Tools calendar.

At the consumer level, I am not seeing anything in the way of motion cams that allow recognition of a stranger. Telling the something is going down: yes. Telling what is going down: probably. Identifying somebody that I already know: maybe. But rendering an image of a stranger that could be used to pick them out of a lineup? I don't see it. - which begs the question: how about supplementing the video cam with some sort of still camera - analogous to a game cam? I am currently running 5 cams at 1280x720. Four of them are capable of more, but performance suffers with the higher rez. At 1280x720, even in daylight I can only recognize people I know. Cams at ExtremeSurfCam.DynDNS.org.

You nailed it. 4mm lenses. Thanks myiicu and buellwinkle for the distinction between Overview and Closeup. That seems tb the root of the matter. Is your 25mm a third-party add-on or did the cam come with it? I've got a spare DS-2CD2032-I and I'm thinking maybe I will swap out the 4mm for something longer once I determine placement/distance. Maybe two cams: one for the shop entrance (where the Beach-West cam is mounted already) and another for the gear lockers around the corner of the building (visible in the 4mm Beach-East cam). I'm also guessing that if I resurrect my high-school trig, I will be able to compute the fields of view by solving for the third side of a triangle with two sides the same as the viewing distance and the known angle the same as the cam's focal length. Barring that, a protractor and some string.... -) How about night vision? I am assuming that just the cam's IR is going to be futile and am lobbying for some supplemental full-time illumination at the site.

My setup for IP Cam Viewer Pro is the same except: I too have "HTTP Port" selected, but the port number I have specified is the RTSP port (1531 in my case). "81" sounds like your RTSP port, though.... . For CH.#, I have specified "1,2" instead of just "1". My money is on this diff as being the critical one. Also, in the past, I have mis-typed passwords. Sounds like yours is the default, so probability seems low for yours being wrong. I think IP Cam Viewer would benefit from a "Show Password" option. My HikVisions are model# DS-2CD2032-I