Some clever fellow has made an ABI wrapper for FFmpeg
. About time! pyglet uses
it now in the media_redesign branch, merge into trunk coming soon.
Media PC notes
Got my Mac Mini delivered on Wednesday, this is my new TV computer (replacing a
barely-functional laptop incapable of playing back 720p video). Overall am very
pleased with how it's working out. Some things...
* The Front Row interface is pretty good, but is a bit laggy and tricky to use
with long lists of files. The trick is to make sure TV shows are sorted into
separate "Season" directories. It would be nice if it remembered your
place within a playlist. I suspect Leopard will bring many improvements -- at
least those present in Apple TV.
* Harmony universal remote can do the work of the tiny Apple remote, but it's
not as responsive (even after adjusting timings), and not at all useable for long
lists of files. I can live with the impurity of two remotes (the Harmony is
still replacing 6).
* The DivX QuickTime component from divx.com is rubbish: it can't playback
fullscreen smoothly, crashes often and is slow to load files (a real problem as
Front Row tries to show previews while you're scrolling through the list).
Removing it was a hassle and required a reboot. I'm now using Perian
works well as both VNC client and server, for controlling the mini from
my laptop. Not fast enough to display animations (or movies!), but good for
* Remote iTunes
is the best implementation of several applications that do similar things, but
is still too slow to be useable. The source is available but is all in
AppleScript. Someone with free time needs to Cocoaify this and have it cache
* Bought a 500GB WD My Book Essentials external USB2 drive. No complaints,
very fast and silent.
* All you people who think a media PC needs to timeshift TV are obviously from
countries where broadcast TV has something worth timeshifting (or watching). I'm
regretting even buying an ordinary TV tuner, it's barely used (maybe when Idol
starts up again... ;-) )
Summary of grievances
The last three days have been non-stop trouble for me and computing. Rather
than throw the whole lot out the window (it is, after all, hard garbage week),
I'll just whinge about everything in one big go here.
**Grievance number 1: Gentoo**
So it's my fault for using Gentoo and not falling into line with Ubuntu like the
rest of you drones, but still. There's some systemic fault in my portage tree
now so that any time a package is upgraded, the symlink from */usr/lib* to
*/usr/lib64* is lost, and all permissions on /usr/lib64 are lost. I figured this
one out only moments before Ubuntising myself a few weeks ago, but the other day
it manifested itself in a new way.
Toby and I puzzled over why no 32-bit apps would start up... the only error
message would be "command not found", and ldd wouldn't recognise them
as executables. I finally figured out that the symlink from */lib/ld-linux.so.2*
to */lib32/ld-linux.so.2* had been removed (again, by some package upgrade). On
the plus side, I did learn lots about how executables are started up. [For
example, the */lib/ld-linux.so.2* path is hardcoded into every 32 bit
application. The 64 bit apps on this computer are hardcoded to look at
**Grievance number 2: setuptools**
Richard found the time to address some long-standing pyglet issues on Mac OS X
(issue #8 was submitted last year!). When I tried out his changes, there was no
effect, and I immediately thought, "Ho ho, silly Richard, these fixes do
I then spent the next several hours trying to fix them myself, to no avail. It
was *almost* as if none of my changes were being applied. Ridiculous! I had
triple checked sys.path, and had printed out pyglet._ _ file _ _ from an
Never trust the interactive prompt. Printing pyglet._ _ file _ _ from the unit
test showed that it was using an installed release of pyglet from the
site-packages directory. This is despite my having a "." in
After an appalling amount of time, I traced the problem to a single function
within site.py. On entry to the function, sys.path was correct, but after
returning it was borked, despite the function only ever *appending* to the path
(my PYTHONPATH was ending up somewhere near the middle, after site-packages).
Worst implementation of anything, ever. site.py calls "exec" on any
line in a package.pth file (this is supposed to be a text file) that starts with
Worst abuse of a bad implementation of anything, ever. easy-install.pth uses
that exec to insert malicious code into site.py, reordering sys.path so that its
own packages are always listed first.
This in itself would not have caused a problem, except that somehow the
site-packages directory itself ended up in easy-install.pth, ensuring that
anything in site-packages overrides my own PYTHONPATH. Damn you to hell,
setuptools. You are the spawn of something greasy. I wish many painful deaths
**Grievance number 3: Safari**
pyglet.org is getting some fancy new features to show off project screenshots
and snippets from the mailing list. To avoid having to change the HTML on the
server (risky, especially with our quota problems), it uses some simple AJAX
(yes, there's even some X) to do the rendering client-side.
This was a breeze (I love XML-DOM in its many incarnations) and was working in
Firefox in no time.
I then spent 6 hours trying to get it working in Safari. The DOM was being
updated correctly (Safari has a nifty DOM viewer like Firefox), the text was
being added, but nothing was being styled, and images weren't appearing.
As it turns out, (though I've yet to find any related experiences on the web),
Safari has a special "act like a retard" mode when content is served as
XHTML. Now, I know that XHTML is tricksy and technical and it's not what you
think and etc etc. BUT. There were no errors. The DOM was being updated. The
XHTML after being updated was correct. It was just that Safari wasn't updating
its visual model.
Changing the filename to .html (the DOCTYPE is still XHTML, as IE requires this,
and it still has the <?xml... prologue, because I like it) fixed everything.
**Grievance number 4: Internet Explorer**
Yes, this one's predictable. Actually the changes required to the same code
were fairly minor (you must set the element class with *.className*, not
*setAttribute*, and tables require a tbody). Thankfully there's enough suckers
out there also doing IE development that Googling my problems turned up the
answers pretty quickly.
**Grievance number 5: Gentoo again**
So I booted back from Windows into Gentoo and my fonts look weird. Um, the
boldface is **really** bold, and the subpixel antialiasing looks backwards (I can
see the reds and blues). I turned off subpixel antialiasing, and can live with
the bold fonts; but really, why does everything happen to me?!
First public release! New-look website! Hooray! http://www.pyglet.org/
to the first proposal for pyglet, with Richard asking where he buys one.
Windows permissions woes
pyglet is almost ready for dress rehearsal, just dry-cleaning its jacket and
organising a hair dresser for the big event.
I've been having some fun writing the Windows installer for pyglet. I'm using
WIX to create the MSI from an XML description, which is filled in from a template
by a Python script. The installer is smart enough to detect more than one
version of Python installed, and asks the user which one to install pyglet in.
Unfortunately, due to limitations in the MSI model there's no way to install
pyglet in more than one Python directory (as Windows will note that it's already
installed once). "Power" users who need to do this will need to
install from source.
The big mystery that had me stumped for hours yesterday and this morning was why
the generated XML would fail with error 2755 ("System cannot read from the
device"), whereas my hand-written mockup worked fine. Copying and pasting
the working XML over the generated XML still didn't work. In fact, copying the
working MSI into the directory where the non-working one was located caused the
same error in the working file.
As it turns out, the directory I had been generating the MSI in was missing some
permissions. You can only see these permissions by disabling "simple file
sharing" (though I am not using the network). According to the
"Advanced Security Settings" for the directory, my user has Full
Control (inherited from its parent). It turns out that "Everyone"
needs Full Control over the directory in order to install the MSI from it. These
bits are set (I believe) when creating a folder from Explorer, but not when using
"os.makedirs" or cygwin's "mkdir".
I will admit that I've never taken the time to read up on the Windows
permissions model, as I've always managed to get what I want by clicking on
buttons that are shaped right; still, this seems like wrong, unexplainable
behaviour (until someone explains it to me).