Changes to the "new" netcam code to improve error handling

Introduction

Discussion and ideas for improving the error handling in the netcam module are continuing under the NetcamRetryErrorDiscussion page. This topic is to provide a patchfile to implement at least some of the points discussed there.

Background

The initial release of the rewritten netcam code included some philosophies of ("was inspired by") the previous version. One of these was the idea that only a streaming camera required a separate thread - for the non-streaming version, the "main" thread could just go and fetch the picture directly. That seemed to be a good idea - keep things simple, don't go starting up another thread if you didn't need to. However, as we begin to discuss error handling and recovery strategies, we have a big problem. If the "main thread" (the one executing netcam_next, which is the "motion_loop" thread) has to wait for an extended time (more than a few hundred milliseconds) to connect to the netcam, or for the netcam to respond, this means we are unable to return to the "main motion loop" to take care of all the other motion activities. The solution to this problem, of course, is to always start up a camera-handling thread, so that when "waits" or "retries" are required, they are within that completely separate thread; netcam_next can always return quickly to the "main motion loop".

A separate, and somewhat unrelated problem, is what netcam_next should return to the main motion loop. This is particularly important in the case of errors / troubles. This subject is still under active discussion on the NetcamRetryErrorDiscussion page, and this patch will attempt to implement whatever the current thinking from that discussion indicates.

Description of Patch

• Changes handling of non-streaming camera to include a separate thread.
• Changes the value returned from netcam_next to the motion main loop to indicate the status of the image returned.
• Many changes to the comments, and some enhancement to the logic, to begin the implementation of points agreed on the NetcamRetryErrorDiscussion page.
• Implements the triple-buffering scheme proposed by PeterHolik (but not the "Without Locking" portion of his proposal).
• Changes to motion.c, motion.h and video.c (provided by KennethLavrsen) to help in handling missing frames.
• The patch is "self-contained", i.e. it does not require any other patch.

Installation of Patch

To install this patch, download the attached file into the motion source directory and execute the command:

gzip -dc motion-3.2.2_snap10-netcam_errors_{version}.patch.gz | patch

Change History of Patch

• 8 Aug 2005 First release - only small changes to miscellaneous error handling. Much more to come.
• 9 Aug 2005 Version 2 - fixed netcam routines to return a +ve error code when no new image is available. Fixed part of the problem with the Toshiba camera showing connect errors. Fixed the 'connect' to properly time-out.

Discussion and Comments

---

Since I have not yet integrated NetcamWithoutLocking it is probably easier both for you and me if you include the NetcamWithoutLocking in this patch and cancel the NetcamWithoutLocking.

-- KennethLavrsen - 08 Aug 2005

---

When I use anoher Motion machine as "webcam" and stop it - Motion correctly starts copying old image and then shows grey image.

But when I restart the "netcam" machine - Motion seems to never recover. The grey image continues.

-- KennethLavrsen - 10 Aug 2005

---

All of this is integrated into my sources and will be released in 3.2.2_snap12.

-- KennethLavrsen - 10 Aug 2005

---