View source for Dr.Octo

(stub)

== Introduction ==
Dr.Octo is a proprietary/closed-source broadcast automation system I developed approximately 1992. It was the beginning of something I'd envisioned back in 1971, but computer technology needed to evolve a bit before it became practical.

All versions of Dr.Octo are primarily written in Perl, with significant portions also in Tcl/TK. Other languages are employed to a lesser degree where needed. The core operating system is BSD_Unix/Linux.

== Version 1.0 ==
Dr.Octo Version 1.0 ran on SunOS 4.1.3 (I think) and was essentially a demo, executing on a very small library of program material. All the basic features were there, including some that don't exist in later versions due to various limitations. I was probably its only listener, and it got me through some difficult times, as someone close to me died just after it was "finished" (could run on its own). There was a haunting classical piece in this versions' limited repertoire (can't remember the name now) that sort of hung in the air and made time stop. Or maybe I was just mourning. But whenever I think about about this version of the software, I think about that piece, and for a brief moment I'm transported back to that time. Ghost in the machine!

== Version 2.0 == 
In 1996, Dr.Octo was incarnated in Version 2.0 of necessity. It was still running on SunOS, now at the end (Version 4.1.4), and running on SparcStation hardware. The main program source(s) were massive jukeboxes of CD's containing pre-produced programming. Whereas V1.0 was essentially a solo effort both in programming and realization of a working system, V2.0 was a group effort, with fellow humans creating programming material and a result that was both listenable and durable. Program material from that effort is still being aired today, using later versions of Dr.Octo.

== Version 3.0 ==
In the 2002-2003 timeframe, Dr.Octo Version 3.0 evolved from 2.0. Still using the massive jukeboxes, the main improvement was an X-Widows GUI, a Web Interface (allowing listeners to see what was playing and interact to a limited degree), and various internal improvements that allowed more fine-grained scheduling to be done, as well as improved DJ-Assist mode (not present in Version 2 although present in Version 1). This system was in production until the fall of 2005. The version was hampered by the entire library being on CD. It wasn't quite possible to put even some of it on hard disk, as the necessary codecs just weren't there yet. The original vision remained incomplete despite the improvements. Strangely, the GUI functionality got little use, and so was discontinued in later versions... perhaps to be picked up again at some point in the future if desired.

== Development Hiatus ==
In late 2005, stuff happened, and everything broke and/or went away for reasons beyond the scope of this document. The roots of this calamity dated back to 2002, but no one knew it was coming. The programming "made the jump" to Live365, and lived there in an extremely limited form until early 2011 - about six years of essentially a state of dormancy. Actually, that incarnation is still in existence as of late 2013. It's not running Dr. Octo, of course, it's living on Live365's software, but it's tuned to sound as though it's running on Dr. Octo to the extent possible on Live365. Integration with anything substantive is thwarted by Live365's oppressive and Nazi-like adherence to the demands of the big record companies.

== Version 4.0 ==
In early 2011, Dr.Octo Version 4.0 was hatched, so to speak. An unusual case of an entire re-write from scratch (as the original code had been lost). In V4, the primary program source resides on hard disk, making it much easier and more efficient to work with than the CD carousels. The ability to insert and schedule streams as if they were static program sources was also added. This version is implemented on Ubuntu Linux, with some instances also running on Debian (and variants thereof). Due to the necessity of starting over from scratch, V4 does not (yet) have a GUI, and the Web Interface is, so far, primordial. New features such as program catching, distributor integration, Twitter integration, support for multiple program streams, and vastly improved DJ assist mode have been implemented. System V IPC features are used to deal with resource contention and control. Remote control, submission, and collaboration features are very nice to have. Integrated flow and calendar-based scheduling have been implemented, and self-service web-based spot/PSA submission and scheduling is soon to be released. This release, as well as earlier releases, is incredibly stable and capable of running for very long periods of time, and with remote collaboration and submission possible, the product remains fresh even during long periods of unattended operation. No crashes have been logged since early 2011, and the longest run-time experienced has been around 4 months and counting.

== Version 4.1 ==
Version 4.1 introduces the use of a networked RDBMS for various and nefarious reasons. The DBI interface is used, so this functionality is potentially database-flavor agnostic. In this version, data is "written through" on both legacy and RDBMS systems, so in the event of RDBMS failure, the system will trudge forward, albeit with some loss of (new) functionality.

SystemV shared memory and semaphores were integrated to support communications between a rapidly increasing number of components and handle contention for resources.

Work on this version began on the unique date of 11/12/13.

== Version 4.2 ==
A great deal of development was done during the year following version 4.1.

* This release represented code cleanup, breaking the system into smaller, less monolithic pieces.
* A function library was created.
* Startup and shutdown processes were improved and stabilized.
* An extensive logging system was added to allow extremely fine-grained control over logging.


== Version 4.3 ==
Version 4.3 

* A web server based UI was created, which focused on reporting from the RDBMS, but also allows for some control of the system.
* The web server was leveraged to provide some integration of all the pieces of the system that have developed.
* A hybrid data approach allows the system to run with nearly full functionality if RDBMS connections fail for any reason.
* Support for multiple, communicating instances was implemented but is not yet used in production.
* The rate of development steadily built from April, 2014, reaching a peak toward the end of 2014 and the release of Version 4.4

== Version 4.4 ==
A great deal of development was done during the year following version 4.1.

* Dr. Octo molted (was rehosted) onto more capacious hardware and a newer OS release during 2/2015.
** Rehosting was a pleasant experience. The RDBMS did not move.
** The changeover was transparent to listeners and to functionality.
** Mysteriously, the hourly "ding" added in version 4.3 ceased working after the molt. Cause still unknown.
* A web server based UI was created, which focused on reporting from the RDBMS, but also allows for some control of the system.
* The web server was leveraged to provide some integration of all the pieces of the system that have developed.
* A hybrid data approach allows the system to run with nearly full functionality if RDBMS connections fail for any reason.
* Artificial Intelligence concepts were added.
* The software was altered to allow it to self-modify both synchronously and asynchronously. Both modes are required as Linux doesn't fully support this implementation.
* Sections of the code that could not support self-modification were re-written. This effort is ongoing.
* Many real-time knobs, dials, and switches were added, a benefit of the work on supporting self-modification to support AI.
* Many program features, such as timechecks were added.
* Scheduling features were added, although the system continues to be 100% "scheduled" in real time.


This update was added 3/18/2015