Down with forked-daad, up with mt-daapd

I have a page that is a popular destination for music lovers out there.  It's my post on running forked-daapd on CentOS.  It was a great little post at the time, and was needed.  It was the daapd server at the time that had the most recent activity in development, so it was the one I opted to use.

It was rather ugly to get installed, frankly.  It had so many dependencies to other libraries, all in an attempt to make it "easier to code".  But it definitely helped me realize something : all of you open-source wookies out there seem to think, "hey, a  new library!  I should get in front of this bleeding edge so that all of my L337 friends think I'm the bomb!"

Frankly, I hate you punks.

Why the hell should I have to install 5 different libraries for each package only to have those libraries used ONLY by that package?  That's ridiculous, and frankly, I'm not gonna put up with that crap any more.

No more packages that require any more than one  obscure library, or it's on my hitlist.  Perhaps you will understand if I explain this with the forked-daapd server setup.  It required a recompile of sqlite3, antlr3, and a number of other packages that only forked-daapd needed.  I went through the hoops once.  BUT, every time I updated the system and the sqlite package was updated, or some other dependency was updated, I had to recompile every damn piece of the puzzle, and sometimes they wouldn't even compile any longer!  I am NOT going to release packages for something old, and something that was causing a pain for me.

So, I went back to the older mt-daapd service.  Wary of what I might have to install, I threw the source down and fired off the compiler.  It needed a few things.... but they were all provided by the distribution!  After not having my wife iTunes be able to play the networked data, I had it up and running fairly quickly!

For all of those who are trying to use forked-daapd..... just give up and go with mt-daapd .  It works just as well!

How An Apple a Day Keeps the Anger Away

I am not an Apple fanboy.  I DO enjoy their hardware - the time they put into the fit and finish makes it almost worth the cost of getting around their stupid "come to us for everything" mentality.  Don't get me wrong, OS X has been a great system, but I absolutely love the mechanics of the open source world.  Give me a nice XFCE interface any day of the week, and I will be a happy camper.  I view it this way - yes, you can re-compile most applications to run on Mac (macports, etc), but that can be a REAL pain.

A few weeks ago, I had the thought of getting rid of the Mac, and going with a cheaper Toshiba with Linux running on it.  It would be just as effective, plus I'd be completely back in the open source world.  There was just one problem.

I also own an iPod.

Reality set in when I thought, "I haven't synced this iPod in two years!  I should update the songs on it, and this is a good chance at doing this completely open source."

I have a large music collection running on a server.  It's not a Windows server, nor is it a Mac.  It's Linux.  That has the majority of my music on it, not the Mac, or the Windows desktop that my wife uses.  My problem is that I had certain criteria I needed to meet :

• I didn't want to copy music files all over the place to do it - so the iPod sync had to be done on the server.
• I wasn't going to install Mac OS X onto the server, as it doesn't even run a graphical interface.
• It HAD to be compatible with my iPod.

This set me off on a rather long, laborious search.  I started off with rhythmbox (everyone pointed that way).  Unfortunately, it requires a GUI.  That was nixed fairly quickly.

I then looked for Banshee - which wasn't available in the specific CentOS instance I used.  That one was out.

There was a software package called "gtkgpod".  It required a GUI.  But that triggered a look at a library the same group released, called "libgpod".  A library.  How nice.  Just a note for anyone looking at using that library, their API document was terrible.  It was great at showing minor python plugins.  That was about it.  I searched for examples all over the place, and after hours of not finding anyone who had implemented the API but gtkpod, I threw my hands in the air in frustration (trust me, all five fingers were up), and installed the required graphical binaries.  I didn't fire up the GUI on it (no monitor hooked up), but I did use X Forwarding..... and it didn't do much for me.

I went back to the source for libgpod, and built some software examples from their test code.  I had things that could finally do what I needed (or so I thought).  I altered my code to fit my needs, and fired it off.  It took four hours to sync some songs to the iPod.  But, it finished!

I ran over to the server, disconnected the iPod, and.....

.... it said "0 songs".

What?  I plugged it back in, and ran my test cases against the iPod again.... it said I had 783 songs on it, and identified all of them.

Thoroughly frustrated, I started searching for firmware hacks.... nothing for mine (iPod Nano 4G) that was considered "ready" for the world.  I didn't want to play with "bleeding edge" code right now, I have too many other irons in the fire.

Then, I saw a random post somewhere about a software package called "rePear".  It was actually kind of tough to find the "source" for it.  I finally found their home page (download links were not up to snuff, but I was desperate at this point).  I kept poking around and finally found the source on SourceForge.  I had to ignore the links that said "win32" - even though I was working with Linux.  All the way down in there, in code from 25 February 2009, I found a tar ball.  I quickly grabbed it, downloaded it, and read the usage.  Ugh!  I had to copy python scripts to the iPod root device!

At this point, I thought, "what can it hurt?"  I dropped the python files into there, and ran "repear.py config" (first setup requires this), manually cp'd the music (and play lists) onto the iPod, and then ran "repear.py freeze".  I waited for it to finish, synced the filesystems (sync;sync;sync), and ejected the iPod.  I ran over with my fingers crossed.

And I finish typing this listening to music from the iPod I synced music to without iTunes.  Hallelujah!

Paint Reproduction

Well, here we go again.  It's all about that base.  (Painter time!)  As an FYI, for the uninformed, here are the criteria for reproducing a paint color if there is transparency involved.

• Air pressure and the nozzle size - these variables control how much paint and how quickly it's thrown onto whatever you are painting
• Viscosity of the paint - viscosity is how "thick" the paint is - it's a result of how much paint thinner you are using, and if you get it too thick, you get blobs of paint, which is BAD, but not enough and you don't get any coverage
• Primer - if you are using the candy paints or tri-coat systems, your paint is going to be transparent, and in that case, the color of the primer underneath it all has a direct impact on the resulting look
• Base Color - when you buy the paint, you must be aware that the brand of the paint is critical - if it's not the same, the base coat is going to be a different color, resulting in a different finish
• Top and Clear Coats - you should probably be aware that "clear" coats are not always "clear" - they can come with color tints, which do effect the end look, and a top coat is designed to change the end look through tinting

With so many variables, it's hard to reproduce a paint color without knowing a few variables.

So, when I heard back that the new painter couldn't reproduce the paint color, that was some bad news.  He couldn't make the color work right.

Let me translate that.

I have to take the headlight units back to the original painter.  He hasn't taken my phone calls, yet.  I could be doing this on my own, and it could be an expensive learning curve.  Here's hoping.