Hi Jason

As far as I know the motion server:8081 is a common garden variety tcp one. ie it is a single connection between client and server. When you have more than one client you are actually running more than one socket instance on the server. From two clients you would of course have different source IP addresses.

You are thinking about a broadcast protocol? ie just putting packets out on the wire and running a service on each client to "capture" what is needed. There are quite a few video standards that do that kind of thing, but motion by itself I think would need a buffer program. vlc might be able to do it, don't know for sure.

I use to have the "teleport" problem when I ran a 6 IP (net) camera system on a pair of P3/900's about 5 years ago. That was actually a mixture of the boxes being CPU bound, a narrow disk drive channel and having a lot of packet collisions on the WiFi links. I ended up nice-ing the lesser needed processes, running RAID0 and tuning the WiFi environment better. It never completely fixed things, but it got a whole lot better.

The trick as always is to discover where the bottleneck lies. You can do the maths to a degree and its also about looking about system loading. (eg top) At 30fps you can make some guesses about the individual sizes of jpegs. My home system for example runs between 200 and 400Kbytes per image as saved, but the web server (with a lower jpg quality) is about 100K per. That means at 30fps I might be doing 100 Mbits/sec MJPEG streaming down the USB cable. If motion was capturing every frame as movement I'd also see that 100MBit/sec on the Ethernet since I use NFS and some mjpeg-streamer boxes. The 8081 web server stuff is actually quiet glacially slow here. I set webcam_maxrate to 1! If you are doing 30fps at maybe 100Kbytes per image you are using somewhere around 30 Mbits/sec on the Ethernet.

The numbers may sound daunting, but it's real easy to work through it.

Cheers Bob

On 24/11/12 14:15, Jason Sauders wrote:
So, it seems as if I suck. Remember how I said I have 3 thread files open and one is for the wireless cam that we use when we go away? Yeah, evidently that one had 8082 in the settings, so for whatever reason it was seeing thread3 8082 and saying unable to connect, despite the fact thread2 8082 was existent. Switched thread3 to 8083 and thread2 to 8082 and it works great now. Durp durp. I KNEW it'd be something simple.

I have another question though semi off topic to this particular issue. I see in the settings that I can independently control the fps that's coming through the webcam url to keep that lower than the actual recorded stream. That makes me wonder with something. For a while with a previous issue I was trying to figure out why Motion was recording my feeds with skipped frames. If I would be outside walking around, you'd see me jumping forward about 3-5 steps every 2 seconds. It was as if I was continually teleporting. I realized that it was due to the fact that my Linux server downstairs which runs Motion also has an LCD monitor hooked up to it. I full screen Firefox and let it run the mjpg stream so when I'm in the basement I have an active live visual of what's going on outside. The problem was it was duplicating the streams. One live for me to see in the browser, and one for Motion to record. My actual camera was getting stressed due to duplicating two 30 fps streams and that's why Motion was receiving choppy feeds. Once I turned off the browser (or switched to a 2 fps stream... my camera has 4 preset streams built in that I can customize) the issue went away entirely.

That little story above leads me into the next question. When I'm viewing the webcam stream using ip.address.of.server:8081, is the camera still duplicating streams? I.e. is it doing one stream to the browser and one stream to Motion like it was before when I was using the direct mjpg stream in the browser?

Reason I ask is I'm just wondering if Motion somehow has the capability to "forward" the singular stream it's recording from to the browser without duplicating it, or if it actually does have to duplicate it since it's two locations receiving the feed.

This seems exceptionally confusing to put into words, but while we were on the topic of this newly solved durp-durp mystery I figured I'd throw it in here and see what you guys say.

Thanks again for your quick responses. Sorry the solution was a bit of a face palm on my part.