Rui CarmoI’m going to keep it short and simple: It doesn’t actually work.
The reasons why, however, are interesting and worth noting, for the DS411j is otherwise a pretty nice and capable machine, hampered only by its miserly 128MB of RAM. Which, it should be noted, I’ve had no issues with whatsoever for both ordinary (i.e., hands off) and extraordinary (i.e., running a mixture of tmux rdiff-backup, Python app servers and odd hacks, including an ARM toolchain and my custom nodejs build).
AirVideo Server runs perfectly well on general-purpose Linux boxes (as well as on Windows and OSX), largely due to most of the clever bits of it (i.e., the app server that talks to your iPhone and deals with streaming and port mapping) being done in Java. Which is not unreasonable, especially given that it adroitly manages a set of optimized binaries (ffmpeg, for one) that do most of the heavy lifting.
InMethod are gratious enough to provide a set of alpha packages for running it in unsupported platforms as well as the tweaked sources for their ffmpeg package, so all is generally well and good, but running it on an ARM platform (even a jaunty 1.2GHz one) is a challenge due to the Java requirement, so I held off until this weekend to have a go1.
As it turns out, getting Java to run on an ARM machine is way easier than I expected (and, as a bonus, I got a handy little extra for my toolchest): JamVM is a portable and compact Java VM that seems to run just about anywhere, and there was a ready-built package for the DS411j available via optware (which, incidentally, was the very first thing I installed on the DS411j when I got it running).
As it turned out the prebuilt version (1.5.3) didn’t fully support the Java reflection APIs, but grabbing and building the next version was hardly a problem (although the bleeding edge one is a tougher nut to crack).
Now, as to why it won’t run… AirVideo Server is unbelievably aggressive while scanning media and generating thumbnails, for it uses that thumbnail generation pass to scan media and ascertain formats and metadata - it’s an all-in-one operation, and rightfully so, but (and here’s the catch) it generates too much CPU load by launching what appear to be dozens of parallel threads (each with an ffmpeg instance - or at least a pipe to one - in tow), which completely overwhelms the machine.
Not in terms of peak CPU load (I was able to edit files and monitor load on it via a terminal session), but of RAM and overall performance - for AirVideo Server quickly exhausted the VM’s allocated RAM in thread heap alone, and also times out when it can’t retrieve a thumbnail inside of 60 seconds.
Which it can’t, not when trying for a handful at a time.
Were it to be more measured during the actual processing (and, if I may add, if the thumbnail cache actually worked), it might seemingly have done just fine, for (and here’s the clever bit) I had no notion of using it to transcode media (my desktop machine does that just fine, thank you) - I just wanted the streaming bits, which would otherwise (apparently) have worked.
So I’m now doing a dinky little web front-end for my iOS devices that grabs suitably transcoded files from a (tweaked) Python daemon, and that’s that. But I’m already using JamVM to run a bunch of odds and ends I’d otherwise not be able to run on the DS411j (like yuicompressor and a few other Java tools), and that, at least, was a good enough outcome.