First, I should announce that I finally fixed the the problem I introduced during last month’s big FATE rework in which the stdout/stderr blobs were not making it all the way into the MySQL database. I don’t know how that escaped notice during my initial testing. It works again, and after only 3 evenings of analysis and debugging.

Moving right along, I have also made good on my intention to move FATE’s test database format from a pickled Python blob to an SQLite database. You can download the current database of test specs at:

http://fate.multimedia.cx/fate-tests.sqlite.bz2

Run the file through bunzip2, install SQLite, either through your system’s package manager or from sqlite.org, and run:

  $ sqlite3 fate-tests.sqlite

Be sure to use ‘sqlite3’ vs. ‘sqlite’; the latter invokes v2 of the program.

First things first, study the schema:

sqlite> .schema
CREATE TABLE test_spec
        (
          id INTEGER,
          short_name TEXT,
          command TEXT,
          description TEXT,
          expected_status INTEGER,
          expected_stdout TEXT,
          timeout_seconds INTEGER,
          active INTEGER
        );

And then formulate queries. As an example, get a list of all the tests (short name and command) that are presently disabled:

sqlite>
  SELECT short_name, command 
  FROM test_spec 
  WHERE active=0;

You should find that the list matches up with the red boxes in the master FATE test list.

I hope some people find this useful.

Apparently, I won’t have to revise the entire architecture of FATE in order to test FFmpeg on ARM via the Beagle Board. I have been reading some stuff about how ARM will release chips suitable for netbook devices, and how Canonical has signed on to make sure that at least one Linux distribution runs competently on said devices.

I’m excited about this for 2 reasons: I like netbooks (whereas no conventional laptop has ever managed to interest me) and because I retain an innate fascination with alternate (i.e., non-x86) CPU architectures, architectures that are often difficult to work with due to unavailability of hardware and appropriate tools.

When I started this FATE journey, the easiest approach for getting build results from a build client up to the FATE server was to use the direct MySQL protocol:

This is not an accepted way to do things in this day and age. It is more common to funnel the data via HTTP to the server. I resisted this at first because the direct database protocol method was working fine. But it seems that Python’s MySQLdb module is not portable to as many platforms as I would like to see FATE run on. At the same time, 8 months of FATE experience has shown the direct db protocol to be the weakest link of the whole endeavor. If connection is lost during the database operation, the whole script bails out with a Python exception and must be restarted manually. I realize that reading the MySQLdb-python documentation would probably allow me to deal gracefully with such failures and allow the script to continue. Another, more hackish solution would be to put the script in an infinite loop via the shell so that it would restart after a failure.

Here’s the thing: So what if I could handle the failure gracefully from within the Python script? What do I do then? Continue reading →

I recently learned of a low-cost, ARM-based board called the Beagle Board. I have been entertaining the idea of purchasing one for testing FFmpeg via FATE. It wouldn’t fit into the current FATE paradigm, though. I envision that another machine would have to cross compile the ARM binary and then tell the Beagle Board to execute the series of tests using the binary.