pyTivo on Western Digital MyBook World Edition
Sep 10th, 2008 by dmess0r
I had this idea the other day that I could hack my Western Digital MyBook World Edition (mybook), install pyTivo, and setup an all-inclusive storage and HMO/GoBack platform for my Series3. BitTorrent from my workstation to a CIFS share on the mybook, and then stream from the mybook to the series3.
So here we go, torrent from the workstation, save on mybook, and stream onto series3? Seems like a good idea.
First I had to hack the mybook and get SSH installed to make any of this work. I used the SSH enabler hack found here:
http://www.mybook-linux.co.nr/
Next I needed to get Python and ffmpeg installed as they are dependencies of pyTivo. I quickly checked the architecture and memory available.
Linux MyBookWorld 2.6.17.14 #1 PREEMPT Mon Mar 26 12:36:33 BST 2007 armv5tejl GNU/Linux
Now this processor is decent, but not blazingly fast so I decided to grab binaries rather than compile from source. Believe it or not the mybook came preinstalled with gcc and binutils. Mind-bending no?
So I setup Optware and installed python25 and ffmpeg via ipkg.
[root@MyBookWorld ~]# python -V
Python 2.5.2
So far so good.
[root@MyBookWorld ~]# ffmpeg -version
FFmpeg version UNKNOWN, Copyright (c) 2000-2008 Fabrice Bellard, et al.
configuration: –enable-cross-compile –cross-prefix=/home/slug/optware/gumstix1151/toolchain/gumstix-buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-uclibc- –arch=arm –disable-encoder=snow –disable-decoder=snow –enable-shared –disable-static –enable-gpl –enable-postproc –prefix=/opt
libavutil version: 49.6.0
libavcodec version: 51.54.0
libavformat version: 52.13.0
libavdevice version: 52.0.0
built on Apr 15 2008 23:06:38, gcc: 3.4.5
FFmpeg UNKNOWN
libavutil 3212800
libavcodec 3356160
libavformat 3411200
libavdevice 3407872
Next I tested ffmpeg to make sure it was able to transcode properly.
[root@MyBookWorld tmp]# ffmpeg -i test.mp4 test.mp2
FFmpeg version UNKNOWN, Copyright (c) 2000-2008 Fabrice Bellard, et al.
configuration: –enable-cross-compile –cross-prefix=/home/slug/optware/gumstix1151/toolchain/gumstix-buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-uclibc- –arch=arm –disable-encoder=snow –disable-decoder=snow –enable-shared –disable-static –enable-gpl –enable-postproc –prefix=/opt
libavutil version: 49.6.0
libavcodec version: 51.54.0
libavformat version: 52.13.0
libavdevice version: 52.0.0
built on Apr 15 2008 23:06:38, gcc: 3.4.5
Illegal instruction
Shit. Illegal instruction. This means that the binary is probably attempting to use a register which undoubtedly doesn’t exist, OR it is making a call to a processor extension which isn’t present. I know that ffmpeg(1) makes significant usage of processor extensions such as MMX MMX2 SSE and SSE2, and this binary package was clearly built without the necessary –disable flags. Unless you explicitly compile ffmpeg without those extensions, they will be used.
Processor : ARM926EJ-Sid(wb) rev 5 (v5l)
BogoMIPS : 99.73
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 4
I line length : 32
I sets : 256
D size : 32768
D assoc : 4
D line length : 32
D sets : 256
Hardware : Oxsemi NAS
Revision : 0000
Serial : 0000000000000000
Groan, okay so I rebuilt ffmpeg without any of the CPU extensions because clearly this processor doesn’t have a single extension of which ffmpeg makes use. I should be good to go right?
Wrong.
Moral of the story:
The ARM926EJ-Sid(wb) rev 5 (v5l) is so slow that conversion of 15 seconds of Audio and Video using ffmpeg took more than 5 minutes to complete. Some people have said that the disk access is the bottleneck, but this simply isn’t the case. vmstat(1) during conversion revealed that disk I/O was well underutilized. The load average was well over 4 during conversion. If you had the bright idea to use pyTivo on your Western Digital MyBook World Edition, think again.