Archive for category Technology
Hey Nikon! Thanks for nothing!
Posted by ekrunch in Rants, Technology on November 30, 2009
Looks like Nikon put out that update for the NEF Codec that I was asking for.
It officially supports W7 now, even though the 1.8.0 release worked from what I read. Still no 64-bit support for Vista / W7. So hey, thanks for nothing!
Seriously though… what’s the hold up? Are you using some 3rd party library in your code that’s not available in 64-bit or are you just too cheap and/or lazy to upgrade your development tools? Come on now, 64-bit Windows is coming. Almost all new servers are 64-bit and a significant portion of Windows 7 installations will be 64-bit. Get with the program already! NEF Codec 2.0 needs to get here and it needs to be 64-bit.
Network neutrality, are you ready for the internet without it?
Posted by ekrunch in Technology on November 21, 2009
A friend of mine over at The Systems Engineer sent me a disturbing image and I thought i’d pass it on. This is just a taste of what the internet might be like if certain people have their way. All I can say is that if you don’t know what this is about, you should pay more attention to what your government is doing …
Ready or not world… 64-bit Windows is coming!
Posted by ekrunch in Technology on October 24, 2009
Looks like 64-bit is finally going to get a decent launch for the desktop windows world. Let’s face it, Vista 64-bit didn’t go over too well. Software vendors just weren’t ready for it. I was just browsing Dell’s site and it seems that all of the new Windows 7 based installations will be 64-bit. Looks like the boys in Round Rock are going full speed ahead. This validates an article I read months ago saying that Microsoft was going to push OEMs to package 64-bit copies of Windows 7. Hopefully other vendors will follow suit and we can start down the path to more 64-bit software for the desktop PC. Although the only real benefit for most users is the higher maximum memory, it’s still nice to see the industry FINALLY progressing. (*nix systems have been 64-bit for YEARS now) It’s also nice that as 64-bit software matures, those of us who have been running it for the past few years can finally get some real 64-bit performance tuning from our application vendors. All I can say is that I hope software vendors who have been holding out on 64-bit get a clue pretty quick! Those new Dells are shipping and nothing pisses off John Q User faster than some vendor telling him that he doesn’t need 64-bit support… even if the vendor is right.
Oh and Nikon, please fix the damned NEF Codec to run with 64-bit operating systems… it’s really not that hard. Upgrade your development tools and just do it please. We Nikon D-SLR users pay a lot of our cameras and do so willingly knowing that Nikon makes some of the best products in the industry. Show us a little love and support 64-bit operating systems.
Not cuil guys, not cuil at all…
Posted by ekrunch in Rants, Technology on May 29, 2009
Here I sit, broken hearted… my photo gallery is down. I happened to click the link this morning and the gallery was down with a 500 internal server error. I hit the logs and what do I see, i’m being spidered and it’s beating my web server down. There’s a new search engine on the block called Cuil (pronounced ‘cool’), and apparently it’s not very nice to the small web server owner. They advertise themselves and brag about how many pages they crawl and such… well, thanks for killing my damned web server jackasses. Your mega crawler just blasted my web server into oblivion. Now I have a robots.txt in place and hopefully that will shut this crap down. Funny, i’ve never had problems with Googlebot or any other search engine’s crawler until now.
Another fun day on the web.
Prolific USB to Serial Adapters
Posted by ekrunch in Rants, Technology on April 30, 2009
What’s the deal with these things? It seems like no matter how hard I try, I can never get one to actually work with the device that i’m using. I’ve successfully managed to make it work with an old serial swipe card reader, but that’s about it!
It also seems like completely uninstalling the Windows drivers is an impossibility. I have three different USB to Serial adapters, all made by different vendors, all using the same Prolific PL2303 chipset. The installed drivers work for ONE of them. No amount of deleting ghosted devices or clearing USB IDs out of the registry can make the other two work correctly. I’ve even tried forcing them onto the older versions of the drivers with no luck. It’s just disaster after disaster with these things, yet it seems like everyone is using this same chip set.
Yet another piece of terrible driver software accompanied by bad hardware. Any recommendations for a good USB to Serial adapter would certainly be appreciated! If anyone is into the aquarium scene and has used one with an Aquatronica controller, that would be even more helpful. Sad irony, Aquatronica sells a PL2303 based USB to Serial adapter and i’d say success rates are abysmal. I see LOTS of people complaining about them not working. At least i’m not alone!
Adobe Flex, BlazeDS, and TIBCO EMS
Posted by ekrunch in Technology, Useful Information on March 22, 2009
I’ve searched high and low and can’t really find a good walk through on how to configure TIBCO EMS and BlazeDS. The documentation can also be a little gray on how to correctly use the JMS adapter so i’ve taken the liberty of putting together this little pictorial on how it’s done.
First things first, get yourself a fresh copy of Eclipse. For this setup, I used Eclipse Ganymede (3.4, J2EE Edition) on Windows. You’ll need the Java stuff in addition to Flex Builder because we’re going to launch our own tomcat inside of Eclipse instead of using BlazeDS Turnkey or any of those. Also, if you want to add in Java remoting later you’ll appreciate having the components already there.
Next, install the Flex plugin for Eclipse and update according. I downloaded and installed the Flex 3.3 SDK and changed my default SDK in the preferences. Once the eclipse platform is installed, updated, and configured the way you like it, let’s make a new project.
Note: Click any one of these images for the full size version.
Step 9 - Connect the project to your Tomcat server and select the blazeds.war that you downloaded from Adobe
First, let’s edit web.xml. This file should be okay out of the box. Here’s mine as a reference.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | <?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name>blaze1</display-name> <context-param> <param-name>flex.class.path</param-name> <param-value>/WEB-INF/flex/hotfixes,/WEB-INF/flex/jars</param-value> </context-param> <!-- Http Flex Session attribute and binding listener support --> <listener> <listener-class>flex.messaging.HttpFlexSession</listener-class> </listener> <!-- MessageBroker Servlet --> <servlet> <servlet-name>MessageBrokerServlet</servlet-name> <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class> <init-param> <param-name>services.configuration.file</param-name> <param-value>/WEB-INF/flex/services-config.xml</param-value> </init-param> <init-param> <param-name>flex.write.path</param-name> <param-value>/WEB-INF/flex</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>MessageBrokerServlet</servlet-name> <url-pattern>/messagebroker/*</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> <welcome-file>default.html</welcome-file> <welcome-file>default.htm</welcome-file> <welcome-file>default.jsp</welcome-file> </welcome-file-list> <!-- for WebSphere deployment, please uncomment --> <!-- <resource-ref> <description>Flex Messaging WorkManager</description> <res-ref-name>wm/MessagingWorkManager</res-ref-name> <res-type>com.ibm.websphere.asynchbeans.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> --> </web-app> |
Now let’s edit services-config.xml. Key things to note here is that i’ve disabled the inclusion of the remoting-config.xml and the proxy-config.xml since i’m not using them. I’ve also changed the default AMF channel from “my-amf” to “AmfChannel1″ and updated the endpoint URL. Everything else is pretty much the same.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 | <?xml version="1.0" encoding="UTF-8"?> <services-config> <services> <!-- <service-include file-path="remoting-config.xml" /> <service-include file-path="proxy-config.xml" /> --> <service-include file-path="messaging-config.xml" /> </services> <security> <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/> <!-- Uncomment the correct app server <login-command class="flex.messaging.security.TomcatLoginCommand" server="JBoss"> <login-command class="flex.messaging.security.JRunLoginCommand" server="JRun"/> <login-command class="flex.messaging.security.WeblogicLoginCommand" server="Weblogic"/> <login-command class="flex.messaging.security.WebSphereLoginCommand" server="WebSphere"/> --> <!-- <security-constraint id="basic-read-access"> <auth-method>Basic</auth-method> <roles> <role>guests</role> <role>accountants</role> <role>employees</role> <role>managers</role> </roles> </security-constraint> --> </security> <channels> <channel-definition id="AmfChannel1" class="mx.messaging.channels.AMFChannel"> <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/AmfChannel1" class="flex.messaging.endpoints.AMFEndpoint"/> </channel-definition> </channels> <logging> <target class="flex.messaging.log.ConsoleTarget" level="Error"> <properties> <prefix>[BlazeDS] </prefix> <includeDate>false</includeDate> <includeTime>false</includeTime> <includeLevel>false</includeLevel> <includeCategory>false</includeCategory> </properties> <filters> <pattern>Endpoint.*</pattern> <pattern>Service.*</pattern> <pattern>Configuration</pattern> </filters> </target> </logging> <system> <redeploy> <enabled>false</enabled> <!-- <watch-interval>20</watch-interval> <watch-file>{context.root}/WEB-INF/flex/services-config.xml</watch-file> <watch-file>{context.root}/WEB-INF/flex/proxy-config.xml</watch-file> <watch-file>{context.root}/WEB-INF/flex/remoting-config.xml</watch-file> <watch-file>{context.root}/WEB-INF/flex/messaging-config.xml</watch-file> <watch-file>{context.root}/WEB-INF/flex/data-management-config.xml</watch-file> <touch-file>{context.root}/WEB-INF/web.xml</touch-file> --> </redeploy> </system> </services-config> |
And last but not least, messaging-config.xml. This file is where the JMS connection is made to the TIBCO EMS server. And no, you do not have to put anything in context.xml when you’re doing it this way.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 | <?xml version="1.0" encoding="UTF-8"?> <service id="message-service" class="flex.messaging.services.MessageService"> <adapters> <adapter-definition id="actionscript" class="flex.messaging.services.messaging.adapters.ActionScriptAdapter" default="true" /> <adapter-definition id="jms" class="flex.messaging.services.messaging.adapters.JMSAdapter"/> </adapters> <default-channels> <channel ref="AmfChannel1"/> </default-channels> <destination id="jmsDest1"> <properties> <jms> <!-- topic/queue --> <destination-type>topic</destination-type> <!-- What type of message we expect --> <message-type>javax.jms.TextMessage</message-type> <!-- This is the JNDI name of the topic/queue connection factory on the server --> <connection-factory>TopicConnectionFactory</connection-factory> <!-- This is the JNDI name of the topic/queue on the server --> <destination-jndi-name>testTopic</destination-jndi-name> <!-- Keep JMS headers when the message is delivered to Flex --> <preserve-jms-headers>true</preserve-jms-headers> <!-- If we're producing on this destination, what parameters should be used --> <delivery-mode>NON_PERSISTENT</delivery-mode> <message-priority>DEFAULT_PRIORITY</message-priority> <acknowledge-mode>AUTO_ACKNOWLEDGE</acknowledge-mode> <!-- The following lines are for the JNDI connection --> <initial-context-environment> <property> <name>Context.INITIAL_CONTEXT_FACTORY</name> <value>com.tibco.tibjms.naming.TibjmsInitialContextFactory</value> </property> <property> <name>Context.PROVIDER_URL</name> <value>tcp://localhost:7222</value> </property> <property> <name>Context.SECURITY_PRINCIPAL</name> <value>admin</value> </property> <!-- Uncomment if you have a password <property> <name>Context.SECURITY_CREDENTIALS</name> <value>password</value> </property> --> </initial-context-environment> </jms> </properties> <channels> <channel ref="AmfChannel1"/> </channels> <adapter ref="jms"/> </destination> </service> |
Now we have our Tomcat instance set up, time to import some class libraries.

Step 15 - Select the TIBCO EMS 5.x library directory and select all of the .jar files (There are more than what is pictured here)

Step 18 - Click the Servers tab that appeared at the bottom, highlight the Tomcat Server and click the Debug icon
Now jump back into Eclipse and set up the application. I started with a base form, added a text area and called it a day. Here’s the code to add in the message consumer, channel configuration, and event handlers.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | <?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" applicationComplete="messageConsumer.subscribe()"> <mx:Script> <![CDATA[ // Import the required namespaces import mx.messaging.events.MessageEvent; import mx.messaging.events.ChannelEvent; import mx.messaging.messages.AsyncMessage; private function incomingMessageHandler(event:MessageEvent):void { logArea.text += (event.message.body + "\r"); } private function connectEventHandler(event:ChannelEvent):void { logArea.text += (event.channel.endpoint + " is now connected.\r"); } private function disconnectEventHandler(event:ChannelEvent):void { logArea.text += (event.channel.endpoint + " is now disconnected.\r"); } ]]> </mx:Script> <mx:TextArea id="logArea" editable="false" width="95%" height="95%"/> <mx:Consumer id="messageConsumer" destination="jmsDest1" message="incomingMessageHandler(event)" channelConnect="connectEventHandler(event)" channelDisconnect="disconnectEventHandler(event)"> <mx:channelSet> <mx:ChannelSet> <mx:channels> <mx:AMFChannel url="http://localhost:8080/blaze1/messagebroker/AmfChannel1"/> </mx:channels> </mx:ChannelSet> </mx:channelSet> </mx:Consumer> </mx:Application> |
That should do it for the code work … now for the fun stuff.

Step 26 - If everything worked, you should now be staring at the application and should have a message that the channel has connected.

Step 27 - Now send a text message to the JMS topic using your favorite JMS client and enjoy the result!
That should do it! Enjoy your new found JMS happiness. As a reference, a Channel is what the Flex application uses to communicate with BlazeDS and can be HTTP or AMF. A Destination is where you send the messages to and from. A lot of the examples i’ve found don’t show you how to declare what channel you’re talking to as it’s supposed to be handled automatically, i’ve found this to be unreliable and once I started specifying the channel everything started working flawlessly so i’m staying with it. Also, you can do multiple channels for redundancy and such, but that’s a lesson for another day.
Linksys WRT610N and IPv6
Posted by ekrunch in Personal, Rants, Technology, Useful Information on February 2, 2009
Thanks to the shoddy job that Linksys did with the WRT300N, I grudgingly purchased a new Linksys WRT610N. What a pleasant surprise! Finally another decent product from Linksys. Not that i’ve ever expected much from the bargain networking gear, but the WRT300N was very, very bad. Several of the features didn’t work consistently, new firmware was no where in sight, and the 802.11n was abysmal. The WRT300N made me regret ever upgrading from the WRT54GS, which was one of the best routers on the market and still is in the 802.11g game.
Fortunately the new WRT610N solves most of those problems. The simultaneous 2.4/5ghz radios make life really nice and performance is good. I’m now able to run all of my 802.11n gear on 5ghz while 802.11g stays on 2.4ghz. Each radio can also be restricted accordingly. Very handy. Well done Linksys. The updated features of the firmware are always welcome as well. More granular control over the system for those who need it definitely helps. And then there are those surprise features that we get from time to time.
I’ve recently started running IPv6 on my home network for the enhanced features that are offered. Things that were extensions in v4 are part of the standard in v6 and can make life nice, especially in high throughput situations. Imagine my surprise when I was updating my Ubuntu box and noticed that the WINE mirrors’ IP address was a v6 one! So apparently, the WRT610N does IPv6, it just doesn’t tell you! This is some scary stuff folks, imagine that modern operating systems come with IPv6 enabled and people go and buy this router, not knowing that their doors are now open via a whole new protocol. Granted, most home users will never know, but I seriously wonder if the firewall in the 610N has v6 support.
Let’s hope that Linksys is one step ahead of us here or a lot of users are about to get their horizons broadened when the hackers start coming in via IPv6.
For those who are unfamiliar with IPv6 and would like to know more, Ars Technica has a nice primer. Read more here.
Ahhhh, the joys of the standards compliance…
Posted by ekrunch in Rants, Technology on December 30, 2008
After managing to build a functional copy of MediaTomb for my DroboShare, I then found out that it doesn’t support the Xbox 360. Yay… the single device that I wanted to work with it. Oh well, I suppose I should have loaded up the Ubuntu based version first or something beforehand. According to the authors of MediaTomb, it is the fault of Microsoft. That I can believe. I have yet to do a protocol trace but I do know that most other UPnP media servers have a special switch that you have to flip to make it work with the Xbox 360. What a bummer… so much for the UPnP “standard”.
Building MediaTomb for the Drobo using Ubunutu
Posted by ekrunch in Technology, Useful Information on December 30, 2008
Seeing as it constantly comes up on the Drobo developer forums, I thought i’d take the time to put in some work and compile MediaTomb for the DroboShare. For those of you who don’t know, DroboShare is a NAS device that attaches to the Drobo and allows for the device to be used over the network instead of direct USB connections. The beauty of the DroboShare is that it’s an embedded Linux machine with an ARM processor and shell access. Gotta love that! The default media server on the Drobo forums is FUPPES. No offense to it’s author, but I really can’t stand using it.
It seems slow and I really dislike the interface. I also don’t like the amount of configuration that it takes to get it to work with my Xbox 360 so I decided to do MediaTomb instead.
The first part of this is going to require a working Ubuntu 8.10 installation. I use Kubuntu 8.10 as my desktop OS so I already had this part covered.
You can also use a VMware image if you don’t have a Ubuntu Linux machine around. Everything is done in a chroot environment and can be easily deleted after the software is compiled and uploaded to the DroboShare.
First, let’s create the jailed environment.
sudo mkdir -p /var/chroot/drobo
Install schroot (you can also use chroot if you’d like) and debootstrap
sudo apt-get install schroot debootstrap
Create the file /etc/schroot/chroot.d/drobo with the following contents
——– /etc/schroot/chroot.d/drobo ——–
[drobo] description=Ubunutu Intrepid for DroboApps location=/var/chroot/drobo priority=3 users=<Your Username> groups=sbuild root-groups=root
——– /etc/schroot/chroot.d/drobo ——–
Create a minimal system in the chroot jail
sudo debootstrap --variant=buildd --arch i386 intrepid /var/chroot/drobo
Create a place to extract the new downloads
sudo mkdir /var/chroot/drobo/root/code
Download the Drobo toolchain to a temporary directory
http://www.codesourcery.com/gnu_toolchains/arm/releases/2006q1-6
(Select ARM GNU/Linux, then IA32 GNU/Linux, then click Download)
Extract the Drobo toolchain
cd /var/chroot/drobo/usr/local sudo tar xfj <DownloadDir>/arm-2006q1-6-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
Download MediaTomb
Grab a copy from here : http://mediatomb.cc/pages/download#source_code
Extract the files into the chroot
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/mediatomb-0.11.0.tar.gz
Because i’m building MediaTomb, i’ll need SQLite, ZLib, expat, and a few other things … Let’s start with SQLite
Grab a copy from here : http://www.sqlite.org/download.html
I used ’sqlite-amalgamation-3.6.7.tar.gz’
Extract to the code directory
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/sqlite-amalgamation-3.6.7.tar.gz
ZLib – http://www.zlib.net/
I used ‘zlib-1.2.3.tar.gz’
Extract to the directory
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/zlib-1.2.3.tar.gz
Expat – http://sourceforge.net/projects/expat/
I used ‘expat-2.0.1.tar.gz’
Extract to the directory
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/expat-2.0.1.tar.gz
File – http://www.darwinsys.com/file/
Note : The site admin removed the 4.24 version of file so I had to get mine from here
ftp://ftp.sunfreeware.com/pub/freeware/SOURCES/file-4.24.tar.gz
I used ‘file-4.24.tar.gz’
Extract to the directory
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/file-4.24.tar.gz
TagLib – http://developer.kde.org/~wheeler/taglib.html
I used ‘taglib-1.5.tar.gz’
Extract to the directory
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/taglib-1.5.tar.gz
libexif – http://libexif.sourceforge.net
I used ‘libexif-0.6.17.tar.gz’
Extract to the directory
cd /var/chroot/drobo/root/code sudo tar xfz <DownloadDir>/libexif0.6.17.tar.gz
ffmpeg – http://ffmpeg.org
FFmpeg doesn’t really do releases so I used a snapshot from a Gentoo mirror. The filename was ‘ffmpeg-0.4.9-p20081219.tar.bz2′ and I got it from http://gentoo-distfiles.mirrors.tds.net/distfiles/ffmpeg-0.4.9-p20081219.tar.bz2
Extract to the directory
cd /var/chroot/drobo/root/code sudo tar xfj <DownloadDir>/ffmpeg-0.4.9-p20081219.tar.bz2
Create a directory for the resulting binaries.
sudo mkdir -p /var/chroot/drobo/usr/arm
Now it’s time to enter the chroot jail and start compiling!
Mount the required filesystems
sudo mount -o bind /proc /var/chroot/drobo/proc sudo cp /etc/resolv.conf /var/chroot/drobo/etc/resolv.conf
Activate the chroot
sudo schroot -c drobo -d /root
Load some extra packages
apt-get install vim
(Feel free to use whatever editor you like in place of vim)
apt-get install automake autoconf libtool autotools-dev m4
Setup some environment variables. The trick to cross-compiling is to use the system’s binaries for running autotools but tell the compiler to link against the ARM headers, libraries, and binaries. These environment variables ease the pain when building in a non-standard directory. If they’re not set, a few of the below builds will fail miserably.
Seeing as we know the CPU/Architecture of the Drobo and the version of GCC, a quick check of the docs gives us some additional command line switches to further tweak things for our processor. The Drobo is no speed demon so everything helps.
export CFLAGS="-I/usr/arm/include -march=armv5te"
export CPPFLAGS=${CFLAGS}
export LDFLAGS="-L/usr/arm/lib"
export CC=arm-none-linux-gnueabi-gcc
With that out of that way, let’s build some software! ZLib is up first
cd /root/code/zlib-1.2.3 ./configure --prefix=/usr/arm --shared make make install
Now Expat
cd /root/code/expat-2.0.1 ./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm make make install
SQLite
cd /root/code/sqlite-3.6.7 ./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm make make install
File proved to be a bit more tricky, but nothing too horid…
cd /root/code/file-4.24
Edit magic/Makefile.am
vi magic/Makefile.am
Change line 224 from
${MAGIC}: $(EXTRA_DIST) $(FILE_COMPILE)
to
${MAGIC}: $(EXTRA_DIST)
Now run the following to rebuild the build system …
aclocal autoheader autoconf libtoolize automake ./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm make make install
Libexif
cd /root/code/libexif-0.6.17 ./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm make make install
Taglib time!
cd /root/code/taglib-1.5 ./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm make make install
Hold on to your cookies … it’s time for ffmpeg. This is a seriously daunting command line but I have a feeling that this version is broken when cross compiling. Who knows what the problem is … this build works, just no Matroska.
cd /root/code/ffmpeg ./configure --cross-prefix=arm-none-linux-gnueabi- --prefix=/usr/arm --arch=arm --enable-armv5te --enable-nonfree --disable-network --disable-ipv6 --enable-pthreads --disable-zlib --disable-bzlib --disable-ffserver --disable-ffplay --disable-devices --disable-encoders --disable-muxers --enable-shared --disable-static --disable-vhook --enable-avfilter --enable-cross-compile --disable-decoder=matroska make make install
MediaTomb leaves a lot to be desired when it comes to properly detecting items in a cross-compiled environment. It also looks like some of the distributions move header files around… which of course breaks it further.
The following hack fixes it up for us to use again.
mkdir -p /usr/arm/include/ffmpeg cp -v /usr/arm/include/libavcodec/* /usr/arm/include/ffmpeg cp -v /usr/arm/include/libavutil/* /usr/arm/include/ffmpeg cp -v /usr/arm/include/libavformat/* /usr/arm/include/ffmpeg cp -v /usr/arm/include/libavdevice/* /usr/arm/include/ffmpeg cp -v /usr/arm/include/libswscale/* /usr/arm/include/ffmpeg
Last but not least … MediaTomb! Time for some build system hacking again.
Enter the code directory
cd /root/code/mediatomb-0.11.0
Hack up the configure script a little.
vi configure.ac
Change the following line numbers.
2378, 2395, 2402, 2418
On each of those lines, you’re going to see the following section
"-lavformat -lavutil"
With this version of FFmpeg, a
"-lavcodec"
is needed. Here’s how mine turned out.
Line 2378
FFMPEG_LIBS="-L$FFMPEG_SEARCH_LIBS -lavcodec -lavformat -lavutil -lz"
Line 2395
FFMPEG_LIBS="-lavcodec -lavformat -lavutil"
Line 2402
FFMPEG_LIBS="-L$SEARCH_DIR_LIBS -lavcodec -lavformat -lavutil -lz"
Line 2418
FFMPEG_LIBS="-L$SEARCH_DIR_LIBS -lavcodec -lavformat -lavutil -lz"
Now it’s autotools time again.
aclocal autoheader autoconf libtoolize automake ./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm --disable-external-transcoding --enable-ffmpeg --with-taglib-cfg=/usr/arm/bin/taglib-config --disable-libjs --disable-rpl-malloc --with-ffmpeg-lbs=/usr/arm/lib --disable-inotify --disable-mysql make make install
If all went well, you should see the following output
CONFIGURATION SUMMARY ---- sqlite3 : yes mysql : disabled libjs : disabled libmagic : yes inotify : disabled libexif : yes expat : yes id3lib : disabled taglib : yes ffmpeg : yes external transcoding : disabled libextractor : disabled
Okay, now to create the required scripts, tar it up and send it to the Drobo! I’ve attached them here as text files and also as a ZIP file all of the necessary files.
The following two files go in the
/usr/arm
directory
mediatomb-stop.sh
mediatomb-start.sh
The following file goes into the
/usr/arm/config
directory. This directory does not exist in the default MediaTomb setup, just create it and put the file in there. This is the default configuration that MediaTomb creates on first startup except that the paths have been modified to work on the DroboShare. This file will definitely need some more tweaking.
config.xml
This ZIP file contains all of the original files in their original form. Just unzip this file to /usr/arm and move the configuration file to /usr/arm/config
configs_for_mediatomb.zip
Almost home … just create the Tarball
cd /usr/arm tar cvfz ../mediatomb.tgz *
Now exit the chroot jail and upload
/var/chroot/drobo/usr/mediatomb.tgz
to the Drobo. For more information on how to add applications to the DroboShare, check out the DroboSpace site.
Just when I thought it couldn’t get any better… Wordpress strikes again!
Posted by ekrunch in Technology, Videos on November 24, 2008
Using WordPress has been a pleasant experience since the day I started this blog. It was easy to set up the first time, even easier to upgrade, and it works quite well. So just when I think “Wow, it just doesn’t get any better than WordPress 2.6″… they give me a sneak peek at WordPress 2.7!
Bravo guys, Bravo.
http://en.blog.wordpress.com/2008/11/07/if-wordpress-27-was-a-movie/























Recent Comments