silencery

Thanks for the news. Trying now!

Now I have to find a fix for the fact that the IP setting I set the camera to (and deselect DHCP) is overridden by the NVR once I hook it up to the NVR. I assigned a class 3 IP (192.168.1.xx) but the NVR automatically overrides this setting and assigns a class 1 IP (10.1.1.xx). It does not appear to be any way to turn off the DHCP function in the NVR, as I have already deselected DHCP and given the NVR a static IP in the class 3 range (192.168.1.xx). I used the configTool to assign a static IP to all the cameras before connecting them to the NVR and that turned out to be a waste of time...

If you want to use your own subnet or dhcp server and happen to have another POE switch, you can get around this by plugging the cameras into the switch and uplink that to your standard network. The NVR will still detect the cameras even if you're using the NVR's internet port and assigning your own IP addresses.

hotneutron,

Thanks for posting this! GREAT tip. I'll have to try it out.

This works until reboot...

Yes, I had the same question. Is there a way to permanently commit the routing tables, i.e. maybe with a startup script?

how do i verify the alternate stream is being recorded? I have all cameras connected thru the dvrs poe ports.

If you're in the web administration (using internet explorer), you can go to config -> advanced -> record and make sure both main and extra stream is set to "schedule." This should ensure the alternate stream is being recorded.

And here it is for a QC804:

 

~ # cat /proc/cpuinfo

machine : hdk7108

processor : 0

cpu family : sh4

cpu type : STx7108

cut : 2.x

cpu flags : fpu icbi synco fpchg

cache type : split (harvard)

icache size : 32KiB (2-way)

dcache size : 32KiB (2-way)

address sizes : 32 bits physical

bogomips : 493.56

 

Pretty much the same. Does this tell us everything we might need to know about the hardware's channel capacity? Is there some video processing not identified by cpuinfo?

Thx for the input. From a CPU perspective, it seems the specs are the same. There is a high probability they are also using a hardware decoder card for displaying video, but i haven't had a chance to check yet.

Here's the output of /proc/cpuinfo from a QC808:

~ # cat /proc/cpuinfo

machine : hdk7108

processor : 0

cpu family : sh4

cpu type : STx7108

cut : 2.x

cpu flags : fpu icbi synco fpchg

cache type : split (harvard)

icache size : 32KiB (2-way)

dcache size : 32KiB (2-way)

address sizes : 32 bits physical

bogomips : 495.61

I suspect CPU will be the same for all 4/8/16ch models.

You might try user root, psw vizxv at the shell prompt. That got me into the WAN port on my QC804. It is probably the same going in through the LAN ports. I nosed around inside soon after I got it last fall. Found that most of the NVR behaviors are inside a single executable, making it hard to do any reverse engineering there. But the linux environment is there and might let you query the hardware configuration, especially identifying the processor, memory size, etc.

I'll PayPal anyone $20 bucks who can either absolutely report the exact model and speed of the ARM main processor, as well as the Broadcom h.264 decoder chip AND if it has any differences between the 804 808 and 8016. A bonus $20 if you prove to me that you can hack the 804 up to 8016 firmware and have it actually work. I'd love to put our conspiracy theory to an end, whether right or wrong.

 

Note, no fudging/hacking the results to make $20.

No bounty required. We can check directly. On my QC808, you can telnet in with the login posted below:

root/vizxv (thanks for this! where did you find it?)

After dropping into the console, run cat /proc/cpuinfo and the chip info will come up. I'll post my results tonight after getting home.

I think the password for the latest QC804 should be the same?