Plex Media Center for OS X Leopard

OK, so you’d like to build from source and contribute to the project. Git (and GitHub) make this really easy, and give you powers far beyond what non-distributed version control systems like Subversion provide.

The problem with Subversion and CVS in open source projects is that they’re like a walled fortress, and you’re either on the inside or the outside. If you’re a “member” you’re given commit access, and then you can develop on your own branches, checkpoint your work, etc. However, life isn’t so good on the outside. You essentially work without a version control system! You can pull in updates as they get committed to the repository (hoping they merge cleanly with your code), but in terms of keeping order to your local changes and check-pointing them, you’re shit out of luck.

Distributed version control systems like Git essentially democratize the process, giving everyone first-class revision control capabilities. GitHub takes this a step further and puts the “official” people making releases of a project on the *exact* same footing as everyone else with an Internet connection. With a click of a button, you can fork an existing project, work on it with a bunch of your friends, and then request a pull from the parent project. Check out the fork tree for the Ruby on Rails source.

I’ve used quite a few revision control systems (CVS, Perforce, Subversion, and Clearcase — ick), and Git is the only one that both got me excited and fundamentally changed the way I work.

There are two basic ways to start. You can fork my repository on GitHub, or you can simply clone it. I recommend the former because that way you get instant offsite backup of your work.

First steps:

• Download and install MacPorts.
• Download and install XCode. I use the new 3.1 version that’s part of the iPhone SDK.

Now install Git (which pulls in quite a bit of stuff with it). Why you need to manually specify gawk is beyond me. If you’re uncomfortable with the Terminal, you probably want to do some calisthenics or a shot at this point.

$ sudo port install gawk git-core +svn

Let’s get your Git environment set up. Skip the “color” configuration if you don’t like color highlighting.

$ git config --global user.name "Barkley Dawg"
$ git config --global user.email "barkley@woof.com"
$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto
$ git config --global core.excludesfile ~/.gitignore

Edit the ~/.gitignore file and add the following to it:

.DS_Store
*.o
*.lo
.libs
*.la

$ git clone git://github.com/elan/xbmc-fork.git

At this point you’ll need to wait a while, during which time you probably want to have MacPorts install the rest of the dependencies:

$ sudo port install libsdl libsdl_image libsdl_mixer glew fribidi
            freetype python24 mysql5 lzo libmad pcre
            fontconfig py-pyobjc

(Note that for SAMBA, you should follow the instructions here).

Now sit back and relax, or do shots of tequila while your machine crunches away. When it’s done, you can make yourself a branch to work on. I’m currently working on the v0.5 branch for releases, so you can create yourself a tracking branch starting from there to work from, and check it out:

$ git branch --track my-branch origin/v0.5
$ git checkout my-branch

Now we’ll build the code and run it. You can also do this inside XCode, of course.

$ xcodebuild -parallelizeTargets -configuration Debug
$ export XBMC_HOME=/Path/To/OSXBMC.app/Contents/Resources/XBMC
$ ./build/Debug/XBMC

Time to write some code! If you want to merge in the latest changes to the branch, you can issue a pull:

$ git pull origin/v0.5

In order to push to the remote repository, you’ll need to tell it which local branch to push. This next operation will only work if you did fork my repository (in which case you would likely add my v0.5 branch as a remote).

$ git push origin my-branch  # First time.
$ git push origin            # Subsequent times.

So now you’re set. You can do development on one or more branches locally, push them to GitHub, get updates from my branch (or other people’s branches!) and when the code is ready to be integrated, simply issue a pull request on the GitHub site.

I haven’t really even covered all the different cool things you can do with Git, but hopefully this will serve as a reasonable primer. Notice I never talked about “commit access” — why is that? Well, if you’re doing the occasional one-off patch or experiment, you really don’t need it, and you get all the benefits of version control and offsite backup without it. If you’re starting to get more involved and you want commit access because I’m slowing you down with my pokey pulls, just ask for it and I’ll give it to you, provided you’re not a raging psychopath. That’s the funny thing about Git; commit access doesn’t stand in the way of getting stuff done. And remember, using Git means you never have to say you’re sorry!

Some great Git resources:

• This is a brilliant video of Linus talking about Git at Google. Really hilarious, if only to watch him call lots of people stupid in a way only he can get away with.
• I can’t recommend this booklet on Git enough. The nine bucks is more than worth it.
• A nice cheat-sheet for the common commands and their usage.

Please let me know if any of the above doesn’t work for you. We’ll be moving these instructions somewhere more permanent once I know they’re correct. Also, I’ll post most Git tips over time. I’ve been especially loving the bash autocompletion.

It *totally* slipped my mind to mention in the release notes, but we have new support forums here. Come on in, make yourself an account, say hello. Many, many thanks to Isaac (a.k.a. iordonez) for setting them up.

Alright, it’s been way too long since the last release! I apologize. Profusely. I’ve been busy getting the code moved over to Github and taking care of some other related things. It might seem like all I’ve been doing is drinking beer, but I assure you, that’s far from the truth. Really.

I’m going to write another post tomorrow detailing how totally awesome git and GitHub are, with some detailed instructions on how you can contribute to the project as a developer. For now, I’ll leave you with a link to the tagged source for this release.

Clearly we still have some rebranding/renaming to do; for now, imagine OSXBMC as standing for “OS X Barkley’s Media Center” or “OS X Bad-ass Media Center”.

Here is what’s new in this release:

• NEW : Support for Aliases.
• FIX: Listing directories with broken symlinks is wonky (things went missing).
• FIX : Timezone off-by-one issue (really fixed this time!)
• FIX : Mouse cursor sometimes shows up. I double-doggy dare it to show up now!
• NEW: libdvdcss is included, which should help with DVD playing (thanks, tokyovigilante!)

Also, I’ve updated to the latest Linux code, which has lots of good stuff as well. Vulkanr has made some great progress on getting libcdio into shape (with the help of davilla), and as a result, support for media on optical disks should be along shortly.

Here are the links (torrent, HTTP) to the release. Since a lot has changed since the last one, I’m sure I probably screwed something up.

Here’s your dose of Barkley; he’s swimming around in some salt water pools and watching Anna take a dive (and probably wondering why it looks like she only has one leg).

A few days ago, there was a heated internal email discussion going on amongst the XBMC team members. The topic: whether or not to kick me and the other OS X people off the team. There was an actual vote taking place, with retractions, explanations, concessions. One of the OS X people got called a rather offensive name.

I watched this all with a calm sense of detachment. Why? Because I’m totally over it.

When I started porting XBMC to OS X, and then joined up with our little ragtag team of like-minded individuals, the goals were simple: To take what we considered to be the best media center in existence, and make it run on the Mac. The second goal was to make it stable. The third goal was to integrate it fully into the Mac ecosystem. And the fourth goal was to make it even better than it already was.

What became clear to me watching this vote is that these goals can no longer be met as members of Team XBMC. That’s why I voted in favor of kicking us all off the team. I simply do not have the stamina, patience, or desire, to deal with all the drama surrounding our union. I will not go into details here, for the sake of professionalism, and it must be said that I still have a great deal of respect for nearly all of the XBMC team.

Having covered that, where to from here?

We will continue to work on XBMC for the Mac. We are forking the code (it will be hosted on Github). We will still keep roughly in sync with the Linux code, and of course the XBMC team is welcome to merge our changes back into their tree.

The biggest change here is that we will no longer be operating under the restrictions imposed by the team. We can clean up and simplify the settings as we see fit. We can remove features that don’t work right (sometimes, less is more). We can add whatever new features our users are asking for, in the manner of our choosing.

We will be announcing new support forums shortly, and we will be posting details on the Github repository.

Also, we’re definitely looking for talented graphic designers with an eye for typography to work on a top-notch Mac-themed skin.

If you’d like to join us, we’d love to have you. And by “join”, I mean “work with us”. There will be no formal team, nor will there be any getting voted off the team. Think of projects like Mono, Wine, or Linux as models.

It’s an exciting time, and there is a lot more to discuss. Peace out.

EDIT: I’ve closed comments for this thread. It’s time to get some work done.

Just to dispel any rumors or myths to the contrary, we are - of course - planning on checking our changes back into the Linux branch of XBMC, just as we’ve done with all previous releases.

Trying to release a stable and polished product to our beloved OS X community while the Linux XBMC code churns like an Amish farmer making butter ain’t easy. I’ve been burned in the past trying to get some changes checked in and then finding that I had to update more of my local tree than I wanted to as a result.

In addition, posting comments here about violating licenses, harassing our team every few hours on IRC, and sending accusatory emails are really not the best way to get on our Christmas list. Contrary to popular belief, we do this for fun, and the less fun it becomes, the less likely we are to continue doing it.

In the longer term, we’re looking into solutions to this which will likely involve either creating an OS X branch in SVN, or creating a GIT repository somewhere where you can get access to more realtime source updates.

Until then, please, be kind and patient as we work to resolve a few more issues in the betas and then get our changes back in SVN.

As some of you have accurately pointed out, we’ve slipped past the release date listed for 0.5. Before the comparisons with Windows Vista start arising, let me assure you that we’re working hard on it, and have one or two minor things to finish up before releasing. We’re thinking about doing a couple of beta releases before the final 0.5, just to ensure the greatest success.

Stay tuned…

Mark McCall from AutomatedHome was kind enough to interview me about the direction of XBMC for OS X. I know what you’re all thinking, I should stop wasting time and just get back to coding, and you’re absolutely right. I’m totally ashamed of myself. But if it brings new users to our beloved media centre (notice my annoying British spelling), then perhaps it’s for the better.

I’ve read about a few ways of doing this, but this evening it occurred to me that using iTunesFS might be really easy and work quite well. Sure enough, load it up, add the new share and you’re browsing and playing your iTunes library.

The only thing I haven’t figured out is how to share this new FUSE filesystem via SMB. It appears that you have to set the allow_other option, but I had no luck getting this to work via sysctl. If you can figure it out, post a comment!

We’ve gotten over 1200 responses on the survey, and I wanted to start by just thanking everyone for taking the time to complete it (and cullman for suggesting the idea and writing the survey)! We learned a lot, and will use this information as we move towards 1.0, in terms of features and bug-fixes.

First of all, let’s look at the demographics. Here are the top five countries; I’m amazed at how many people are in Sweden (unless Pike was busy clicking).

While we sweat away perfecting the Apple Remote/Universal Remote code, please help us out by taking our short survey. We’re trying to get a better sense of our community, which will help us prioritize features and schedule things better in general.

I wish I could say that one lucky respondent to the survey will win an all expenses trip to Maui, where he or she will be forced to work cleaning our house for a week. In reality all you’ll get will be our eternal gratitude. Thank you all in advance!