DKtucson

on another generic dvr from another vendor where there was no spelling out of a particular rtsp port I tried the 3 ports reserved for the dvr with every permutation of http--mms--rtsp as well as trying different syntax and it wouldn't launch--there must be very specific syntax in some dvrs or some just don't play well

Not likely but you can try..most dvrs have a http port--mobile port--mobile monitor and rtsp but it all depends on the maker

Samir---I get the rtsp port number from the network or netservices screen--depending on the menus

Samir--I don't have any insight to particular brands or models but it does appear the functionality differs--your mileage may vary as they say on the car commercials. It worked well for me in a very generic $50 straight from china D1 dvr Guangzho Eagleyes maker--but trying it on a $1000 Dahua HD-SDI model it keeps looping me for a login/password even though I'm using an admin account credentials and it will not run

The syntax looks correct..unless the functionality between DVRs differs slightly or versions/platforms of VLC

is that an extra space between rtsp :// and not rtsp:// ?

I do not get a secondary login/pasword prompt on my dvr access..putting it in the string just brings up the specified channel

correct--as an example [rtsp://192.168.1.10:554/user=admin&password=12345&channel=1&stream=0.sdp?real_stream--rtp-caching=100]

--without the [ ] brackets

replace the ip address with your applicable one or your DDNS host name

replace the port 554 with your RTSP port from your dvr menu screens

replace the admin with your username

replace the 12345 with your password

change the channel= number to the camera number you wish to view

and yes it is all run together with the ampersands

I think a lot of us have run into this: The run of the mill chinese dvrs will use phone apps like Asee or VMeye etc and only offer web based viewing on IE via Active X plugins. Newer browsers like IE11 and Linux/Mac don't like to play that game and some folks get real edgy when they get as popup saying do you want to install this plugin from Shanghei.

As an alternative install VLC. Go the the Media command and Open Network Stream.

Put the following in the address field "rtsp://192.168.XX.XX:your_rtsp_port/user=username&password=your_password&channel=1&stream=0.sdp?real_stream--rtp-caching=100"

Obviously change address if your net is different or put in your dyndns/no-ip DDNS domain name. put in your rtsp port from the DVR settings. The username & password for dvr access and the channel number. If you go through and launch it each time you change the channel number it will create a "playlist" of your previously viewed cameras for easy switching.

I see a big problem with the XSS exploit--google cars drove in my neighborhood 5 years ago..I've since moved (maybe) and my router was in AZ now in Calif but the bad guys rely on 5 year old google coordinants and jack the house I USED to live in (sorry new owners).--LOL

Good points on the replies-- I checked in on the script XSS and inputting my mac address it came up blank so I'm good so far.

Agreed on the "big target" point. As I was discussing with the guy on facebook that my local casino probably doesn't have accessible cameras from the outside world--truly "closed circuit" as they have a room full of guys manning joystick ptz controllers etc.

I do a lot of my own webstuff..I host my own websites on a nix box..I maintain a FTP server so motion still from my clients are saved locally in case they get jacked--I run a terminal server for my sisters quickbooks. But I can't see going through the hassle of a dns server for the perceived piece of mind of avoiding a service provider

Recently No-Ip.com had an outage caused by MS seizing their domains due to some users abuse (malware/bootleg software). I had a back & forth with a person on a Facebook thread that we are all basically idiots for using public or 3rd party DDNS services so clients can view their cameras.

His stance was that someone could use a "man in the middle" attack and garner the login credentials & have camera access/ "case" their home using their cameras.

Well..my counter was that if someone was away from home, using a hotspot that was spoofed and someone was nabbing info they would have no idea of where the house was located per se..just views of a front door/patio slider, inside of garage etc etc.

Any IP geolocator will not show the actual home traced back from an IP address--you'd need a court order from the ISP for that.

This twit was basically saying we're all rank amatuers & should be running our own DDNS servers. Aside from this spot outage, No-ip has been rock solid and I can get 30 domain names for 2 years for $15...thats .03 cents a month for redirect names I can give to my clients.

Reality check..if someone is going to compromise a system it's more likely going to be a paintball gun from a distance then a crowbar session.

aha.. the plot thickens..the friend has 2 systems--one at his home (vmeye china dvr) and a pc based unit at his office running TimHillOne... the home ISP is Simply Bits..the Office is Cox so the cinese DVR is not the culprit. The pc based unit uses dyndns.org addy and was used at the house until we upgraded that location to the hd-sdi system.

The pc based dvr was never an issue with bandwith when in use at the house.

Mixing of terminology--when the client emailed me initially he stated that the isp was saying he's way over his bandwith he asked if the fault could be with "the dvr"--I assumed the new chinese dvr as this is the "new kid on the block" and would be suspect of any new quirky behavior .

Likely his wifi was hacked

Thanks everyone for the replies.. there is no cloud storage..just view. The Xmeye service is the DVR vendors own DDNS. It takes the serial number of the unit/ip address and makes it available for remote viewing in either IE or android/i-phone app VMeye Super. The house is currently vacant--the owner is a friend of mine here in Tucson, AZ and he avoids the summer heat by going to a vacation condo in San Diego for the summer. No one at the house-- no Roku TV running, no torrents seeding or other stuff.

My question and answer from the vendor SECTEC in china:

is it constantly consuming bandwith even though no computer or smartphone is requesting data?

No ，it will not if without any request data

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now, if someone was doing a browser view and asked to record locally--then it would be uploading data stream to the cloud and back down to that remote viewer of course.

The dvr is set to record only on motion event

If "cloud enable" is unchecked it's not accessible at all remotely

I'll have my friend call cox internet & see if thats uploaded or downloaded data--good call. I called my ISP and they were of an opinion that no way would a dvr gobble up the much bandwith--likely someone has his wifi password and is streaming video /netflix etc

I have an email in to them about 30 mins ago to check that..they took the wife's laptop and that had 2 bookmarks-- a "local view" at 192.168.XX.XX and a remote view at the xmeye website

Thanks Shockwave...my thought is, even if they were viewing it all the time their wireless provider would have cut them off--they would be receiving 545gb on their phone/mobile plan--yikes!!

Hello,

I recently setup a home DVR with HD-SDI cameras and a DVR from China. The DVR uses xmeye/VMeye cloud service for remote view either by IE web browser or smartphone app. Cox is the internet provider and they gave my client a tap on the shoulder that their monthly bandwith usage was 545GB (lordy). The are away from home, no house sitter or teenagers streaming movies etc. I have a full D1 dvr also of generic chinese make but uses dyndns.org addy for access--I also have a gob of stuff running (terminal server for quickbooks, ftp server , wife has netflix etc) and we use about 80gb a month.

Correct me if I'm wrong, but unless someone is connecting to the cameras for viewing in either a browser or smartphone then it really shouldn't be gobbling up 1's & 0's

Hello folks,

I setup a Dahua DVR for hd-sdi cameras and have 3 HD's installed 2 1tb drives and a 2 TB drive (Total of 4tb). HD1 is a 1tb , HD2 is the 2nd 1 TB and HD3 is the 2 TB. I have them all in one HD "group"--just to make sure I'm correct in my thinking ALL drives should be set to "read/write" if I want to start recording on one drive--then when that drive fills it goes on to the next--fills that one up--then on to the 2 tb drive--fills that up and then starts to overwrite the 1st 1tb drive. Am I correct in that assumption? If a drive is set to "redundant" that means it's a raid mirror to make sure footage recorded on one is backed up on another.

Am I correct in that assumption / understanding?

@sunnykim--The card is an 8 chip card from china with generic WDM drivers--the software is from another vendor so my guess would be if hardware couldn't keep up the software would kick out an error and not oblige the hardware by dropping frames.. but I could be wrong...

she hired an engineer to argue that a toilet at full bore flow couldn't consume that much water--if it was a "slab leak" or a main on her side of the meter it would have washed out her yard. No neighbors with pools that got a refill from her tap--best guess is a faulty meter--but a few months after the cams were in it caught a drive-by shooting so shes glad they were up

Thanks again.. yeah the eating up of the hd is a bit of concern..here's that situation: the gal who I built the system for leaves town for the summer and the dvr pc is left running--a while back she came home to a $3000 water bill so she wanted cameras. With her being gone she wants a bottomless pit of recordings. The 8 cams average 5gb a day--thats 200 days for a 1TB drive so it covers her absence..but if the files grow we don't want to come up short.. the alternative is to slap a bigger drive in

thanks Kawboy..I think I recall a pre-record doo-dah field in the setup screens

Hello,

here's the situation:

PC based DVR running H264Webcam (TimHillOne).8 camera system 30fps each channel. What will occur is that lets say you are looking at a street scene. The recording will start with a person in the middle of the frame, rather than catch them from the point at which they entered...to the non picky observer--hey we caught the guy on frame. To the OCD customer, "where did he come from? from what direction did they enter the property? what else is the system missing?"--those are the nagging questions.

Any ideas of what may be a setting I'm missing to cover these "jerky voids"?

most likely a bot spamming any forum with "car seats" in the mention

Hi Andy,

Thanks for the response. The cameras are all supplied with RG59 Siamese wire--coax with a tandem run of 18/2 for power. There were a lot of big screen displays (sports bar/dance videos) and those have cat5 to supply them , which are also kinda fubar'd (they cut the ends to be maliscious is my guess).

The layout , if you can picture it , is a large single story rectangular building and the 2 offices are kitty-corner from each other. Following the gang of wires from the one office they go out the wall, up a large pipe to the roofline. Then along the roofline they re-enter the building and run along the back of the bandstand and are visible bundled together. They pass through a wall above a drop-ceiling in a small storage room and then route down to the other termination point in the other office next to the small storage room. It would make sense that the T-connection/splitter would be in the vicinity of the drop-ceiling in the small storage room--this is where we see a cluster of cams ( Stotrage room, office, lobby , bar 1 bar2 , front steps, dj booth) So it would be a relatively short run for the majority of cams.

The client is out $$ due to the vacancy and is fighting the apparent fact that the cameras tested so far are toast. We verified the 24VAC coming from the power dist box. We ran a short length of 18/2 to the nearby desk and also have a short length of test coax with BNC at both ends and 2 cams tested the same--dark blue muddy grain blobs is all we see. He's looking at it as "How can they all be bad at once?" and not accounting for the fact that they may have been failing one by one over the years--plus we had not taken ALL of them down yet and tested as such.. some may very well still work on the short cable. I'm feeling that this is a 2-pronged problem--a cabling issue and a cam issue as well and BOTH need to be addressed.