#zoneminder

Yeah :/ not sure if it was on the outside or inside ... It's cleared now, so it's either become complete vapour inside due to heat, or it was on the outside... I'm betting it's the former..

If it does it again tomorrow morning I will pull the camera down and clean/dry it and add a bit of dielectric grease to the cable seal...

Bhaal: did your cam come with one of those little baggies of pellets or whatever in them

my cams came with them wire tied to the inside, presumably to absorb moisture before it has the chance to form on the lens cover

roasted: It would have but that was before I gutted the camera and replaced it with a Pi ...

The cat5 cable is thicker than the original cable so it shouldn't have leaked, but will check it tomorrow anyhow...

*ping*

*BOOM*

shakalaka

http://i.imgur.com/Z2CoX0t.jpg << BOOMer

rexd666: status?

iconnor_: copy paste, build, find next missing function, copy paste, build, rinse and repeat

Did I mention it wll take me a while

do it faster!

we really need some better debug tools for onvif.

ic0n you done much work on the ONVIF code?

I'm getting into it now. Taking a break from h264

I've noticed a couple issues causing some ONVIF compliant cameras not being picked up. One of them is the way Accept headers are being added to requests. Instead of doing Accept: soap/xml, application/soap, it'll add a separate Accept header for each one. I had a quick root through and I think it's a Perl HTTP module causing it, so not much we can do afaik

I'll make a couple GitHub issues instead of whining here :D

I appreciate your thoughts. I am just coming up to speed on it.

I have a compliant camera that our code doesn't work on that is complaining about uri format....

I am comparing what we send to what ODM sends and they are very different

For the initial UDP probe to get the device service address?

yup

Ah, I haven't looked at the differences in that part yet. I've noticed tho that ODM and ZM perform the profile discovery process quite differently tho

first off odm just asks for the NetworkVideoDisplay... whereas we ask for NetworkVideoTransmitter and Device...

Hmm, I wonder how much of this stuff is down to differences across ONVIF versions

ODM is definitely doing stuff right tho, never had any problems with that picking up devices and getting info from them

aha... my camera responds if I don't ask for Device in the ProbeType.

which is weird because it should responds if it matches any of them...

All the onvif specification documentation can be found here: http://www.onvif.org/Documents/Specifications.aspx

An ONVIF compliant device shall include the device management service port type, i.e.

tds:Device, in the <d:Types> declaration.

The following example shows how the type is encoded in the SOAP Hello body:

<d:Types>tds:Device</d:Types>.

The Hello message may include additional types.

I'm sure we all just dieing to read it (cough, cough)

Somewhere in there it should tell us what we should be sending to the camera in the initial query

And I'm sure that has changed through the different versions of Onvif

I think to handle the variety of ONVIF implementations out there on different cams, we need to start adding fallbacks throughout the ONVIF discovery process

agreed

Sending NetworkVideoTransmitter didn't work? Let's try NetworkVideoDisplay etc.

Sending just NetworkVideoTransmitter worked. Sending just Device did not.

For example, to discover service endpoints (Media service - for video profiles) ZM uses the GetServices operation, with Capabilities set to true. A few cameras don't support that operation, but they do support the GetCapabilities operation which returns nearly the exact same info - ODM has this same fallback

My current project will likely require me to fix some of these issues so once I learn Perl I can start hoying some of that functionality in :)

The existing Onvif code is a very bad example to try to learn Perl with. That particular code is very hard to follow. Take a shot at it, but be advised that we have kicked around the idea to replace it with an equivalent C++ onvif library (I forget the name if it), but only if it actually works better than what we have.

also ONVIF server impl, in cameras have all sorts of nuances - won't auth if timestamp is off, won't respond to old SOAP formats and what not

I've found the recent NodeJS libs to be quite updated and good for ONVIF profile S

yeah I'm perusing it. Going to steal any and all ideas.

Yeah, the auth nonce in the onvif spec is generated from the time so the clock in the camera has to be set.

it's not that simple. I have a camera who's time is set and it doesn't work. I'm wondering if I set it to UTC if it would work...

The time is just one part of it. See the onvif spec

its really just a bloody mess

Ok, I like how the nodejs just has a pre-defined probe string...

I find hacking simpler with nodeJS

right

the code is less complex

none of this building up an xml structure crap

exatly

Before I realized that my Onvif PTZ camera blindly ignored any authentication I sent to it, I had written PTZ authentication which generated the proper stuff..... I got suscpicious when my code worked the very first time (it never does), and thats when I discovered the stupid camera ignores the authentication ....and I've since learned that a lot of the cheap chinese cameras are like that

Bahaha :D

And they just ask for NetworkVideoTransmitter, so to start with, I am going to do that to our code.

are you looking at https://github.com/agsh/onvif?

yup

k

Cheers for the heads up btw knnniggett. After browsing through that ONVIF code I can't say I was looking forward to learning Perl.

The ONVIF code in ZM is particularly daunting

I purposely embedded a bad nonce into the url, and the camera panned and tilted just fine. A polite "wtf" message to the ebay seller was not replied to

knnniggett: I think some onvif fixes will justify the release of 1.30.1

No wonder there are botnets of 1.2million IP cameras out there

JoeAlamo: That particular code really makes me feel stupid.... I get about 2 levels deep and I get completely lost, every damn time.

I'm note familiar with nodejs at all, so I'd need some to kickstart that idea if it is viable for zoneminder

s/note/not/

I would hate to intorduce yet another language to our codebase.

yes not unless we remove one

As far as ZM goes, given its existing tech stack, doesn't make sense to add NJS

copy ideas/translate

node has its own install dependencies and bloat

doing all of that _only_ for onvif is not useful

in future if someone rewrites the backend (replace PHP with Node+someJS) then it makes a lot of sense

Phil wrote up a small wrapper for the UI using expressJS and Node for oz - incredibly easy to extend and I've imported the onvif code and am tinkering - it fits in very naturally there