Ok, that took quite a bit longer than I wanted, but I finally got all of the pages working now with
the new camserver. The visitorpage was giving me issues, but it's done now. I do, however, have
quite a bit of tweaking to do to make everything work smoothly. There are lots of new fields for
both the cam and visitor databases that I need to add to the edit pages, and I still need to make
some tweaks to the servers themselves.

The camrelay program is crashproof, but it's still using a LOT of memory. I've got a lingering
buffer problem that I have yet to figure out. Here's how it works. The relay program is a
webserver I wrote, albiet a very primitive one. It accepts a GET request for an image, and part
of the url is the cam number. If the cam number is currently unknown to the relay program, it
grabs the url from the database, sets up a thread, and connects and grabs an image and holds it
in a buffer. My image buffers are arranged as a linked list, with the first element in the
list being the most recently recieved image. Image 0 is always the temporary one. When a request
comes in, it grabs the first complete image, which is virutally always image 1, but sometimes
image 0. Whenever a new request comes in, it adds a connection id to a linked list of locknodes
attached to the individual image buffer, and sends the image, meanwhile setting snarfwaiting to 1
which instructs the snarf thread to go grab another image from the webcam host. As soon as that
image is complete, it's available to the client to grab, which triggers another snarf, and this
process repeats itself until new requests stop coming in.

The issue at hand here is the locknode list. That list prevents the image from being purged until
all connected clients which were receiving the image have received it, or given up. The problem here
is that a connection is likely trying to grab that image, or has quit trying, but neglected to release
its locknode. That means the image sticks around.. well... forever, even though nobody is ever
going to grab it. This makes the image buffer list just continue to grow. I've solved this problem
by simply purging any image buffers that are more than a few minutes old. Nobody is sitting around
that long waiting on an image.. however, this shouldn't be necessary, and it also points to a possible
issue of a connection thread still sitting open, which is going to also consume system resources over
time, although not as quickly as images stored in RAM would. Still, its an issue I still need to
debug more.