dexterash

I didn't state that DDWRT could be the problem (heck, it's way too stable and widely used). I wanted a log of the FTP server (and I do remember ddwrt only writes a general log, not a per-service log) Bug can be, but discovering the way the camera tries to upload and what the FTP server answers could help.

(quick) 2nd

1st part

Can you make ddwrt upload syslogs to another box? Maybe it's a thing about FTP/uploading.

64bit means lots of memory usage... A 32 MP channel, 25/30fps@1080/ch dedicated Linux NVR + server class needs just 4GB. (this just at memory level, with no talk at CPU instruction level) Also I would(just me) never run an app as a NVR that can't me monitored(watchdog) natively (mainly on Win). We can put BI on a 6000 USD chasis, KVM, battery memory backuped-RAID, redundant fans & PS, IPMI/SNMP controlled... And it just hangs at software level... What to use? A 3rd party watchdog?

Do you have a custom path setup for recordings?

But admit it you had a major flow with low bitrate I was analizing your videos for quite a time. And a question poofed my mind: how usefull is DSS(digital slow shutter) if motion is fast? Also, 6fps (as most recommend for residential), is really enough? 3rdly, WDR is also done comparing to last frames, so, at that speed, might had problems. (btw, no fbi-cia-bla bla technique can get more out of 4 coloured pixels:) Well, maybe you could optimize your surveillance? Like, you capture a wide angle, but the "entry points" in that zone are far apart from your camera, left and right.

Would add to your guide proprietary applications for mobile (like the ones offered by QSEE, HIK, Camera Kings, DAHUA, etc). Those apps work very fast and better then the IP CAM Viewer, if only one manufacturer solution is used.

At least of couple of times, since we were looking for cross-protocol solution, restreaming server(to RTMP/Flash and HTML5 to be supported by iOS) etc. Ok, in a simple strictly software way, it's a server and a client too. But not one that I would depend on.

With all due respect to your work: -why would anyone want to embed personal video surveillance into an website? -syncronizing a directory of recordings can be done by many GPL software -why would anyone stop a private surveillance video system? I wouldn't -delay it's ok, but video doesn't work as alarm systems; alarm systems are pointed at "major" events that cause problems, whileist video is a general system, usually used to identify a possible event or the person implied in the event -works with any web browser, but you have to admit it's very limited;does it work with recordings-to-disk too? a dedicated software works better -lightweight&fast, but sluggish; 1fps? 2-3 fps? I wouldn't call it a server... just an entry-level solution.

Auch, not a very nice bug. I'll check it out soon.Also, we mostly use NVRs so we're less concerned by this, but it's a good thing to know/test. I'll get back with news ASAP. Honestly, I haven't had time to fully check this release, since I was interested in other facts (more picture settings, hourly settings, playback on SD-Card enabled IPCs etc)

Only snapshots can be uploaded to FTP server. For recordings, FTP server is used as a "backup" device, and it needs a card to "temporary" store the recordings, before uploading them.

Last time I checked out BI was using the RTSP stream, which has no Motion Detection or anything like this. With all the "fuss" about Onvif, all manufacturers (with support from the SoC's/CPU manufacturers) started introducing RTSP servers in their devices. It's a good, nice thing, but this is not enough. For example, DAHUA's Onvif compat products use a JSON-HTML API for settings and motion detection (even if it's not mature, there is something done that can be used by NVR-like software manufacturers). Other low-priced (like really low priced) manufacturers have implemented an old, buggy RTSP with no API for MD. Of course, things might have changed, but for a true NVR software to work well on a PC will need dedicated libraries/protocols to decode, a powerfull GPU(acceleration included) to display MP,a good MD engine (or rely on IPCameras) and a very well implemented database with events, recordings, timings etc. It's not in the power of the CPU to decode all, mostly should be done via accelerated decoding.

You got a SD card installed?

I posted the question in a very good intent. When I first read BI switched to direct to disk I figured it will just write uncompressed/non-recompressed streams, thus the change in CPU usage. So that means people will be able to record more (8, for example) cameras. But, also, will be a caveat when you want to search through recordings. If you cannot view all 8 cameras at a time at playback (maybe with fastforward too), what happens when you will have to review 7 days of 8 camera recordings? After all, cameras are installed for the recordings(usually) review, not for recordings that no one will ever review or for viewing live. The power of the CPU gained via direct-to-disk can (and will be) lost at playback, if they will implement more than one camera playback (which i think it's a very good thing to do). Ok, you will state motion detection will do some work (I said some, since motion can give false positives; also, I'm not sure if motion it's done at camera level or at CPU level).

BI, of course

Question: has anyone tried playback of recordings? How many cameras, in sync, can be displayed and at what quality?

On what do you want to display those cameras?

Also, the normal/motion/event problem is in the camera, not in the NVR. The NVR will only decode, display and record what the cameras send. As a quick test, you should try to directly connect to the cameras and see if the stream's quality changes.

The snapshot function is active, this is why it uploads. But i can't understand why it won't upload the recordings. Maybe you could check the log of the FTP server?

None. All IP devices made by DAHUA work in the same way with all the software/hardware they release.

You have this option in the NVR's Remote Device Menu (since I don't have a NVR online now, you can test this through your own NVR and see that it has options to setup ip/port/user/pass and channel to record).

As a side note, coax can be HD-SDI too (or proprietary HDCVI) for digital compressed MegaPixel over coax, but I doubt this is the case

If you want to connect analog & IP cameras DAHUA to a unique recording device, you can: -use a Hybrid DVR+NVR (not this case, since the main recording equipment has already been bought) -use a NVR for recordings and (!)any DAHUA DVR as NVS/Video Encoder; DAHUA's NVRs have the ability to record their DVRs too (without the need of a HDD in the DVR) and, also, have the option to select which channel you want to record/display (thus the D1 resolution advertised in NVRs - the NVR can help making a bridge/upgrading existing system)

With all due respect, can you check your "Remote devices" menu to see if they are configured via ONVIF or Private protocol? Also, as a side note, the NVR (in private protocol mode) makes direct changes inside the camera. Since the camera does not support this, it will not work at all, although this could be a firmware-dependant feature.