Video Gadget doesn't work

I am trying to use the video gadget on my groov view (win server). I am connecting to HIKvision camera. Manufacturer gives the following info to connect:

http://user:password@/ISAPI/Streaming/channels/102/httpPreview

When I paste this into the URL space of my browser (Edge) it works fine, displays current snapshot.
However, when I try to use this URL within video gadget I get nothing. Test does nothing, saving and displaying shows nothing.
Does it maybe have to do with the embedded username and password in the URL? These cameras have to have a username and password. Also, my groov server and cameras are on the same physical network. Any ideas why this doesn’t work?

Which version of groov View are you using? There was an issue related to @ symbols that was fixed in 4.3a, but based on your URL it probably doesn’t apply. (Knowledge base article KB89350).

Chrome, and possibly Chrome-derived browsers like Edge, also has a new feature (or behavior?) that tries to automatically upgrade http connections to https without a fallback. (KB89328) Diagnosing this one unfortunately requires looking in your browser’s developer tools: browsers don’t tell applications why an image load failed, only that it did. If you open up your browser’s developer tools and look in the JavaScript Console after a web cam image fails to load, it should report an error. I don’t know if Edge is using that behavior yet, but it’s worth a look.

You can also try enabling groov View’s proxy option on that image: that’ll issue an image load from your groov Server, instead of from your web browser, bypassing Edge.

1 Like

So yes I am using 4.3a. So thinking about that pesky “@” symbol and reading the KB article, I realized that my actual camera password contained an @ symbol. So I tried another user name & pw that did not contain an @ within the password and guess what – it immediately started working. So sounds like 4.3a solved the @ problem when it is placed just before the IP as a divider, but NOT when it is embedded in a password. Oh, and I also did have to go to proxy mode. Thanks for your quick response.

1 Like

Yeah, that’s tricky. Per the URL spec, RFC 2396 section 3.2:

Within the authority component, the characters “;”, “:”, “@”, “?”, and “/” are reserved.

So it’s not really allowed to use an @ symbol in a password, if you’re passing it that way.

1 Like

You could try to escape the @ symbol by replacing the @ with a %40 and see if it will work.