How GLOTV works

The GLOTV system consists of a set of programs:

This is the daemon that listens on sockets, opens the video capture device, and sends data to its clients. It is a hybrid between a single-threaded "select loop" and a forking server. For supply-driven streams, i.e. live video, it handles all clients in the same thread, maintaining a separate queue of output buffers for each client. Whenever new data is available from the capture device, a new buffer is created and references to it are pushed onto all the client queues. If a client queue becomes full it will drop new buffers, and after 5 seconds it will be cleared completely (mainly to reduce the error messages). For demand-driven streams (regular files), a subprocess is forked off that simply goes into a blocking read/write loop that sends data to the client socket.
This is the X11 user interface, built with the Perl/Tk toolkit. It can run either in normal desktop mode where traditional Tk widgets are manipulated with the mouse, or it can be run in "kiosk" mode where it grabs the keyboard focus and reads commands from a separate subprogram. Currently only two such subprograms are available, input-lirc (see below) and input-xboxir which is deprecated except for debugging purposes.
The back-end client program that connects to glotvd. It can request a live stream, a file, or a channel change. Then it pipes the data to another program (the default is /bin/cat). When given the --record=CHANNEL option, it waits until the appropriate time, then invokes a new glotv client that forces a channel change, and then it repeatedly calls glotvrecord which writes the data stream to disk. Each invocation of glotvrecord writes a new file (a segment). The original stream is reconstructed by concatenating all the segments. If no segmenting is wanted it can be disabled by setting the segment size limit to 0 in the configuration file.
This is a command-line script that takes time and channel specifications and turns them into "at" jobs. It invokes "at" in the UTC timezone to avoid unexpected results, after first having converted its arguments (given in the local timezone) into standard UTC-based unix time coordinates. It also does some straightforward defaulting of dates etc. On the night of the transition from DST to winter time it will interpret local times between 2:00 and 3:00 as referring to winter time. So if you want to start a recording during the other 2:00-3:00 interval, you will have to run glotvschedule with TZ set to a non-DST timezone (isn't DST fun?). Note: if you start a recording at 1:59 you can specify +31 to stop 31 minutes later, so the stopping times are not problematic in the same way.
This is a very simple C program that handles the file writing during recording. It waits until the programmed start time has been reached, and then keeps writing standard input to a file until either the stop time is reached or until it is close to exceeding the maximum segment size. It could have been implemented as a subroutine in the glotv script, but was written in C as a separate program to minimize the impact recording may have on the system load on the client machine (which may or may not be the same as the server machine).
This is a Perl/Tk program that reads input events from the LIRC subsystem, and translates it into text commands that are printed on standard output. It is intended as an interface to remote controls until LIRC can be replaced with something better. This program is optional if you're not running xglotv in "kiosk" mode.

Two more programs are used to implement the web interface:

The CGI script that handles the HTML form for scheduling recordings.
A simple C program for running "glotvschedule" setuid. Called by the CGI script.