This post has been marginally edited for grammar and to reflect new facts that have come to light since June 14th, the date of publication.

It appears that Boxee was recently acquired by Samsung, after its attempt to get another round of venture funding went poorly. This is fairly significant news in the XBMC world, even if Boxee was no longer running a variant of XBMC by the end.

There is certainly no denying that Boxee has led an interesting life since roughly 2008. If you don’t know the history, there are much better resources out there than I can provide.

The short story is, Boxee started out as the little media center company that could, spun out a fork of XBMC that was well ahead of its time, and then dropped support for that software.

They followed this up by spinning out another fork designed specifically to run on a specialized box called the Boxee Box, and then they dropped support for the Boxee Box.

Finally, they spun out an entirely new closed source box that had no basis in XBMC at all… and had such a miserable showing that they reportedly couldn’t get another round of venture funding and have now found themselves bought out by Samsung.

For a long time, many of us at XBMC were big fans of Boxee. They led the good fight against content providers on behalf of consumers. They spoke before congress in favor of unencrypted signals and consumers everywhere. They pushed XBMC semi-mainstream.

They did many things right. But as time went on, they started doing more and more things wrong. For the sake of the future and XBMC, let’s look into a few of the mistakes of Boxee, so that we can hopefully avoid them ourselves.

Product Support – Feature Iteration

Without a doubt, the biggest mistake Boxee ever made was failing to maintain support for old products.

For all that we may love to hate Microsoft, support for old products is one of the smartest, most important things they’ve ever done. Windows XP came out in 2001. It was succeeded by Windows Vista in 2007. But support for XP continues to this day, with an anticipated ending date sometime in 2014.

That’s a 13 year cycle of support for a product they only sold for roughly 6 years.That is the very definition of long term support.

To be perfectly honest, a 13 year cycle of support would have been complete overkill for a service like Boxee, as that level of support is really more intended for the business segments of commerce. But it wouldn’t have hurt to at least try to follow the basic tenants of support that Microsoft displayed. Namely:

  1. Release a product.
  2. Stop selling the product.
  3. Gradually pull back support
  4. Fully stop supporting the product when it becomes clear that the majority of users have moved on.

Apple is another company that does an excellent job following and even helping along this basic process with its line of iOS products.

First, they release a product with all the latest features, like the iPhone 4. Then they release the next iteration, the iPhone 4S, with a software update that mostly applies to the 4, but is missing some critical components for the absolute best experience. Then they release the next version, and still more components are missing. Finally, they release yet more version. The iPhone 4 will still be supported by this most recent version, but so many new, amazing features will only be supported on the newer hardware iterations that most users will sadly accept that it’s time to upgrade.

Boxee’s mistake was failing to follow through on basic product iteration. The step from the Boxee software to the Boxee hardware should not have been the only step. Instead, the Boxee Box should have had compelling features that simply could not have been available on the software platform.

For example, the software version might have been restricted to viewing Netflix in a browser, while the hardware version could have had an official, native Netflix app, which would have been totally possible, given the Intel chip being used.

The next generation of the Boxee Box could have had a tv tuner built in. The previous Boxee Box could have the TV tuner, but only via USB. The Boxee software would have had no TV tuner support at all.

etc. etc.

At the end of the day, Boxee’s job was to make money, so expecting endless support for something that didn’t generate value (the Boxee software) was a losing proposition. But failing to incentivize users to see the value in gradually upgrading to the hardware versions was just as much a losing proposition.

In the tech community, hardware and software sales absolutely depend on goodwill and word of mouth. The iPhone didn’t become the best selling smartphone ever because it was a great product. It became the best selling smartphone ever because it was the COOLEST product on the block. By sacrificing the Boxee software, Boxee sacrificed all the goodwill that came with it.

And then, absurdly, they did it all again with the Boxee Box.

Customer Service

Customer service is a very, very difficult thing for a startup company, and that’s doubly true for a startup that’s dealing with something as complex as hardware or a complete OS. Apple makes a few billion dollars a year. It can afford to hire great customer service techs all over the nation, staff a native English-speaking telephone hotline, and otherwise give customers a near infinite supply of options for tech support.

Startups, on the other hand, are often operating in the red. The majority of their money comes from venture capital funding rounds. Since they simply cannot provide one-on-one support for all the problems that might exist out there, they have to operate more efficiently than their much larger competitors.

This means they have to provide forums and other online hotspots where users can help each other. They have to provide a place that quickly and easily answers tons of frequently asked questions. Of course, they have to provide software that’s MUCH more idiot-proof than the stuff that comes from the big guys. And finally, they have to look like they are listening to the problems/complaints/concerns of their customers, who typically understand that startups often run under limited resources.

As an XBMC guy, I’m loath to ever say anything nice about Roku, but you’ve got to give them credit for a few things. First, by all accounts their software is dead simple. Second, they have a really great support page. And finally, with each new hardware iteration, they respond to the users (in particular, putting a headphones jack in the remote control was an absolute moment of brilliance).

Boxee made the simple software. And they had a pretty decent support page.

Where they failed was in giving the appearance of listening to their users. Support tickets would be closed for no apparent reason. Major complaints would go unaddressed for months. Worst of all, major complaints would go unaddressed for months, and then the carpet would be pulled out from under the feet of users as the software with the problem would suddenly no longer be supported at all.

Smart support people and community managers can do an awful lot to help the image of a software company. The recent Xbox One boondoggle could have been remessaged as “We want to be Steam for consoles with awesome winter and summer sales, but to do so, we have to lock games to accounts, so you can redownload your game at your friends house, if you just sign into their Xbox! No disc needed!” The fact that this didn’t happen says a lot about a failure in shaping the message before the “bad” part of the news got out.

Then again, console users are pretty in love with the disks they own these days, so who can say if even a perfectly shaped message could have gotten through. As the old saying goes, you can only put so much lipstick on a pig.

It’s possible the non-iterative nature of Boxee’s development philosophy was always going to screw it, no matter how well they tried to dress it up. The pig was just too ugly from the get-go.

Abandoning the Die-Hards

This one is short and sweet. Every organization has its base: the people who love the product no matter how ugly it is. In gaming, they’re called fanboys. In conservative politics, they’re called… well, we probably don’t need to go there.

The one thing you never do is abandon your base. You may try to push your base in a direction. You may try to grow a larger base that’s somewhat different than the old base. But you never abandon your base, because in doing so you automatically lose the majority of your current sales/votes/etc.

Boxee abandoned their base twice.

Frankly, it’s a miracle they still exist today, just on that fact alone.

One of the things I do as the community manager of XBMC is compare XBMC’s growth in the social networks against various competitors. I think of it as a little litmus test to see how we’re doing.

For the most part, I don’t pay a lot of attention to Twitter followers, since those can be pretty easily manipulated. Instead, the most informative number in my opinion is Facebook fans.

On August 12, 2011, Boxee had 20,000 facebook fans. XBMC had 14,800 fans. Indications were that Boxee was doing quite well.

And then, over the next five months, Boxee did not update its software, and users were becoming increasingly frustrated both by the lack of any update and by the lack of communication concerning the reason for the delay.

On December 26th, 2011, Boxee dropped its first bomb. They announced that there would only be one update of the HTPC software released, and then all support for the original, software version of Boxee would be suspended indefinitely.

On October 16th, 2012, less than a year later, Boxee officially burned another bridge, discontinuing support for the Boxee Box.

In less than 2 years since Boxee dropped support for their HTPC software base AND THEN they dropped support for their hardware base! So what happened to their users?

Let’s check the fan count after so many burnt bridges:

August 2011

  • Boxee: 20,000
  • XBMC: 14,800

June 2013 (today)

  • Boxee: 28,082
  • XBMC: 43,576

Boxee pulled the rug out from under their base twice, and still managed to pick up 8k fans. XBMC maintained a steady pace of iterative, transparent development and managed to roughly triple its Facebook fan base over the same period.

Conclusion

Boxee was, at one time, an organization ahead of its time. All indications were that it had the opportunity to really change the world for the better. In the end, it seems that the only thing that ever really held it back was its own very, VERY poorly managed development decisions.

My major hope is that people don’t look at the mismanagement of Boxee and make the unproven conclusion that media center startups based on XBMC are a dead end. I firmly believe a company that intelligently pursues the path that Boxee followed can make absolute buckets of money and at the same time can make a legion of cordcutters and cord-nevers very happy.

Perhaps with the next blog post, I’ll give my thoughts on just how to do that.


There’s a very good chance you’ve never used XBMC Profiles. Or you exclusively use them because you’ve got kids, and you’d like your kids to see a different library than the one you see. I’m going to call this the B&B* filter.

*Boobs and Bombs**

**Note: when searching for an image to attach to a story, make sure safe search is on before googling “bombs and boobs.”

I personally have never seen the need for profiles in a regular XBMC install until very recently. I don’t have kids, so I don’t need to filter out my B&B. In my world, profiles have only been useful for testing out scraper updates or messing around with test libraries and other Q/A activities.

Profiles – What are they, anyway?

XBMC ProfilesSimply put, a profile is the place where you stick most of your userdata. So if you have set up XBMC to look different with a special skin or if you’ve added video and music files to your library, that’s all stored in a profile. Most people don’t know or care about them, because one profile is all they need on their home HTPC.

The only time they’d be useful for the average user is if that user wanted to test out something or mess with a new library without screwing up their already perfect existing library. Or if the user had a roommate or significant other, and the two liked to keep their content separate. Or, as previously mentioned, for B&B filtering.

But now everything is changing, and it’s all due to the move to Android (and to some extent, the move to iOS) and the major shift to UPnP serving.

GSoC – The Great Catalyst and Related Improvements

GSOC 12 logoIn the past, instances of XBMC rarely communicated with each other unless a user had hacked together a mysql server, and those cases were few and far between.

Last summer, however, student dev alcoheca (Alasdair Campbell) substantially updated XBMC’s UPnP server as part of his GSoC project. Many of those features are now part of XBMC. While many features still need to be coded into XBMC 13 (for example, right now the server library doesn’t update when a show has been watched), the most important part, a fully visible UPnP served library, was already included in XBMC 12.

Now, as will be reported in the XBMC February Cycle announcement, dev elupus (Joakim) has added support for controlling external UPnP instances via UPnP. The upshot of this support is you can select a video on one XBMC device and make it play on another.

AirPlay without the Suck

Even an iPhone can make a great mini XBMC tablet.

Even an iPhone can make a great mini XBMC tablet.

Consider how awesome that is. Let’s say you’ve got your main HTPC in the living room. Now, you can watch a show on your XBMC tablet in the kitchen, stop the show, and then tell the very XBMC tablet you’ve been watching your show on to keep playing the show on your HTPC in the living room.

In time, your HTPC, acting as a UPnP server, will be able to serve the list to your tablet, and your tablet can then tell your HTPC (or any UPnP compatible device) to play a video from that list (or from your Youtube or Hulu addon or your tablet’s local library). And when it’s done, if it’s coming from your UPnP server, the show will be marked as watched on your entire network!

It’s basically Airplay without all the limitations that come from Apple and with all the benefits that come from having an awesome XBMC setup and a server.

 Bringing it Full Circle

Which brings us to Profiles. I don’t know about any of the other readers of this blog, but I am a major evangelist for XBMC among family and friends, which means I’ve set XBMC up for my mom, my sister, various friends, and I’m still working on figuring out a non-insane arrangement for my dad who lives out on a farm where there is no broadband.

Needless to say, as the resident tech troubleshooter for the family, I travel from house to house a lot, and I always bring with me various mobile devices, including my phone and my laptop. Whenever I can put together the money, I’ll no doubt also purchase a tablet.*

*I’d ask you to donate to the Get Nathan a Tablet fund, but the only donation links I’m hosting on this site are donation links for the XBMC Foundation. I have bigger priorities than getting Nathan a Tablet. c’est la vie. With that said, if there are any manufacturers out there who want to straight up give me a tablet, I’m not going to turn it down!

Anyway, in my house to house jaunts, I’ve discovered one thing: regardless of your mobile device, Profiles are fantastic, especially now that libraries can be shared throughout the house. Right now, I have XBMC on my laptop set to the My House profile. If I agree to babysit for my sister on Friday, I’ll bring my laptop* along and switch to the Sister’s House profile. Maybe over the weekend I’ll finally get the system totally worked out at my dad’s house. Then, I’ll switch to my Dad’s House profile. The options are only limited by the number of locations that you have to visit. You could even keep a tablet-only profile, specifically for watching local media on the tablet and pushing it to any house you like.

*Or generously donated tablet! Hint hint, hardware people!

Conclusion

Unfortunately, until UPnP serving is perfected and skins are designed to better take advantage of it, Profiles are merely a single piece in a larger puzzle. As well, the uses outlined here are really only a portion of the final plan for Profiles, as several devs have acknowledged that Profiles as they exist are missing numerous key features. Where Profiles head in the future (likely after 13 has been released), remains to be seen.

With that said, I highly recommend taking a look at one of the nightlies (or waiting for the February Cycle to end to take a look at the first monthly alpha). You can “play to” another device using XBMC right now. It’s surprisingly usable already, for being mere alpha code with hardly any UI code accompanying it. While it doesn’t support straight up screen-sharing, as Airplay Mirroring and Miracast promise to do, it goes a surprisingly long ways in turning an XBMC instance into a full remote control.

As always, the future looks bright.

This has been part of the XBMC Future Series, in which we look at code being worked on right now that has the potential to radically change XBMC. For other entries in the series, see The XBMC Mesh and An Xbox 1 Competitor.


With version 12, the XBMC foundation is persisting in its efforts to make the media center software the go-to platform for your living room. But with multiple software and hardware vendors fighting the war for your TV, XBMC faces an uphill battle to stay relevant in the space.  - Zenonas Kyprianou, The Verge

As always, the opinions expressed below are only the opinions of Nathan Betzen. They are not necessarily representative of Team XBMC or the XBMC Foundation and should not be taken as such.

More than any other tech blog outlet (aside from possibly Giga Om), The Verge has come to my notice as the site most pessimistic about the future of XBMC, as other companies/foundations continue to push their way into the living rooms of the world.

I originally thought this attitude was related to something I did wrong, like writing my earlier Boxee TV post in which I profoundly disagreed with The Verge editor Nilay Patel.

But with the above quoted paragraph, I think I’ve come to understand, a bit, the mindset at The Verge. The issue has nothing to do with me. The issue is that The Verge sees XBMC as an also-ran and a has-been. XBMC requires more effort than it is worth, and it has no massive capital reserves to leverage companies into creating apps for its eco-system or licensing content for its users. On top of that, since XBMC doesn’t come natively on any box out there, it’s more effort than buying a Roku or Apple TV. Meanwhile, the Xbox 360 has an installed userbase of something like 50 million users. I’m not sure what the userbase of the PS3 is, but I assume it is also quite large. On a smaller scale, Roku has had sales of close to 5 million players in the US to date and the 3rd generation Apple TV has sold 2.7 million devices, all on its own.

How can a non-profit media center group hope to possibly compete against Roku, Google, Apple, Microsoft, and Sony? And, perhaps more importantly, why would users continue to keep choosing XBMC over its more wealthy counterparts, given how simple those counterparts are to use?

Those are interesting and difficult questions to answer, but perhaps we could start fairly simply. We have almost no way to officially measure the active userbase of XBMC. Each install doesn’t come with any kind of tracker that we can watch to see how many people have launched XBMC recently. However, by watching our server to see how many people update default addons over the course of a month or so, we can at least set a minimum baseline to the number of XBMC-equipped boxes that have been running.

Recent estimates (prior to the release of XBMC 12 and XBMC for Android) suggest that our active userbase is somewhere in the area of a bit over 2 million. Similar estimates from only a year and a half ago suggest the number was less than 1 million. Regardless of dire predictions, major growth appears to be happening, at least so far. The question, then, is why? And will the growth continue, or will that trend tail off, as another The Verge writer wrote, “I think XBMC is great, but as you allude to there’s a big barrier to entry, and in the grander scheme of things I think XBMC will become more and more marginalized.”

Needless to say, I think XBMC has got a future in front of it, but why? Well, I’ve got a lot of reasons, but to keep things simple here are the five biggest ones.

1. Regionalization

No offense to the Xbox 360, or the PS3, or the Apple TV, or any of the other boxes out there, but they all are, in the grand scheme of things, regional devices. Each of them seeks to act as a content distributor by making deals with other content distributors, either indirectly through Netflix and Hulu, or  directly through NBC, ABC, Warner Bros, etc. But those deals work in America. And that’s it. They may try to make new deals in Europe and South America, and Asia, and Africa, and Australia, but as long as those deals don’t provide access to the content people want, then the big media center hardware makers are going to be bit players in those regions.

XBMC: An international Project

XBMC is everywhere.

XBMC is a truly international project. It has more European devs than American devs. In the last 30 days, it’s had 1.26 million visits on the main page from Europe, 787 thousand visits from the Americas, 124 thousand from Asia, and 89 thousand from Oceania. And the president of the XBMC Foundation is from New Zealand!

XBMC does not provide content. XBMC will likely never work to provide content. That’s not what we do. We make software. And the only thing we avoid even more specifically than providing content is putting any restrictions on the content that users bring to the table.

Gabe Newell has said that piracy was a service problem. An economist would likely say, instead, that content piracy is the result of a market inefficiency. When there is demand for a product in a market, and there is literally no way to acquire that product legally, then alternative means of acquisition will present themselves. In the United States, the excuses for piracy are fewer,* but elsewhere any economist will tell you that if a million people are given the choice between either pirating with next to no fear of getting caught or waiting multiple years to see the next episode, a sizable chuck of that group is going to end up pirating. The relative morality of the question is meaningless. The classic comparison of copyright violations with theft break down in such an arena. “Piracy” only puts somebody out of work if it prevents a sale. In countries outside the US, the content isn’t being offered for sale in the first place, so piracy literally does not have the power to prevent the sale. The copyright owners have beaten piracy to the punch.

*Note: I say the excuse for piracy, not the excuse for breaking DRM encryption, whose primary purpose is exclusively to prevent users who have legally purchased content from using that content as they choose. DRM has nothing to do with preventing piracy. If the two had any connection at all, DRM’d content wouldn’t appear on pirate sites immediately after release.

We at XBMC would prefer that users purchase their content whenever possible. We generally like many/most of the movies and TV shows that are currently out. Ditto a great deal of music. And we want our users to support the creation of that content. But if our users literally don’t have the means of paying for that content due to region blocks, then we aren’t going to punish them for mistakes of geography (also, creating code to enforce region locks seems stupid and pointless and a whole lot of unnecessary work to us).

In other words, until content creators stop stupidly leaving millions/billions of dollars on the table and instead actively try to sell their content via the internet to the world, a prospect that doesn’t look at all likely in the near future, XBMC is going to continue to be a major player on entire continents. It’s a dubious position we find ourselves in, but that’s often the life of someone thrust into taking advantage of market inefficiencies.

2. Platform independence and compatibility

Android on an iPad? Seems legit!

Android on an iPad Mini? Seems legit!

Quick, name the Apple movie player that runs on Android. Name the Xbox player that runs on iOS. Name the Roku channels that can be viewed in Ubuntu. What’s that? You can’t? I’m shocked.

Unlike the other set-top box (STB) manufacturers out there, XBMC isn’t selling hardware. We don’t care whether you use a PC or a tablet or an STB. And we certainly don’t care what the manufacturer’s name on the box is. The only thing we care about is that XBMC runs the same on the tablet as it does on the STB as it does on the HTPC.

Some may see this stance as some kind of weakness, I guess. We see it as one of our biggest and most important strengths. If you know how to use XBMC on one device, you know how to use it on all of them.

Beyond the standard flag waving of “we work everywhere,” there’s a bigger truth. The future of STBs is in SOCs (systems on a chip) like the ARM platform. We will always support HTPCs, but the reality is that ARM completely changes the price-point nature of the market. Instead of $200 for the cheapest HTPC (which is probably missing a bunch of necessary stuff that’s really only available at the $500 price point), you can pay $100 or $80 or $35 for essentially the same XBMC experience.

For some reason, OS developers for the ARM platform have chosen to tie major updates to hardware revisions. For example, there’s no hardware reason the iPhone 4 can’t have Siri. And trying to upgrade your Android phone to the most recent version of Android is often either impossible or an ugly nightmare.

XBMC essentially ignores all of that nonsense. Any Android device that XBMC fully supports will ALWAYS get the most recent updates and features with each new revision, until such time as the underlying processor is no longer capable of coping. For example, decoding of the upcoming h.265 codec will likely be tied to the physical hardware decoder. There’s not much you can do about that in software.

3. Windows 3.1: A lesson in OEM dominance

People forget this, but Microsoft has absolutely destroyed Apple for the past 3 decades in terms of user bases. According to the secondary source Wikipedia in 2011, “Net Applications has estimated global desktop market share of Windows 92.2%, Apple 6.36%, Linux 1.41%.” And that was in 2011! Eleven years after the massive resurgence of Apple!

How did MS accomplish this task? They worked out agreements to be the default OS for every shipped non-Apple PC in the 80s, 90s, and 00s.

In this generation of ARM embedded devices, the clear winner in the default OS battle is shaping up to be Android, which may not sound like great news for XBMC, but right now Android is a fairly terrible OS for STBs. It’s designed for touchscreen support and isn’t really put together with the home television in mind (plus there’s that whole updating issue mentioned above).

If only there was some software out there that could be installed on top of STBs running Android by hardware vendors that can act as an Android app launcher and that ALSO was designed very specifically with the living room television in mind! And if only hardware vendors were actively courting the makers of that software! And if only those hardware vendors had begun putting out press releases talking about how excited they were to use this software! Man, that’d be an exciting world!

Sorry, sarcasm alert in the previous paragraph. Since vanilla Android has mostly failed in the STB space, many hardware companies appear to be recognizing the major value of implementing XBMC for Android specific solutions. Whether that recognition takes off and turns into a Windows 3.1/95/XP situation remains to be seen, but it’s pretty hard to find any other free and easy valid competitors beyond the crappy HTML5 spec. No offense to the Smart TV Alliance, but HTML5 was the wrong horse to back.* Don’t get me wrong. I love HTML5 in my web browser. HTML5 on my TV, on the other hand, sucks.

*Mark Zuckerberg is also sad about HTML5.

4. Addons

As mentioned, XBMC has no capital reserves to leverage companies into creating addons for its service. Fortunately, XBMC doesn’t need such reserves, because our users have shaped up as absolutely incredible addon developers right now. You want to stream The Daily Show? No problem, a user figured out how to make it available on both his Comedy Central website addon and on his Hulu addon. You want to use Hulu, but you don’t live in the United States? No problem again! That same developer has enabled proxy support.

Oh, you want to listen to the theme song of Friends while you try to decide which episode to watch? I’ve got just the user-created addon for you.

You hate how XBMC looks when you first install it? Not to sound too much like a broke record, but no problem! Our users have created skins that are 100% original, and they have created skins that perfectly emulate all those other services out there, like the Xbox 360 console, only without the incessant ads.

XBMC addons are developed using the relatively simple Python language, which means you, as a potential dev, don’t need to learn complex C++ to make most addons happen. It also means that making new addons occurs quickly and frequently. At this point, XBMC addon developers have already begun to heavily out-number core XBMC devs, and there are no signs of that pace slowing.

5. The Magic of Open Source

Perhaps the most certain fact is this: XBMC is open source, and as open source software, it has nearly infinite chances at life. Many people assume Open Source means difficult or ugly or only for geeks. They fail to recognize the fact that Open Source mostly means incredibly adaptable. Consider Linux. Linux isn’t really popular because it makes great desktop OS software. It’s popular because it is THE BEST means of deploying a website. Essentially, if you spend any time online, you probably spend virtually all that time dealing with a server running Linux. It’s also the best software for your router. And also the base for Android. Linux is, literally, all around us, like love or Christmas,* because smart people have been able to take the underlying code and adapt it for use everywhere.

Here, Linux is wearing sexy Christmas outifts

Here, Linux is wearing sexy Christmas outifts.

*I feel it in my fingers! I feel it in my toes!

Even if all development on XBMC halted tomorrow, there would undoubtedly be off-shoot projects based on it springing up overnight. It’s just the nature of the beast. There are too many smart people with access to (and interest in) the code to prevent that at this point. Big companies with a lot of money invested already heavily rely on it. The mark has been set.

Conclusion

My word counter tells me I’ve hit the 2325 word count, so I’ll try to keep this brief. The problem with the quote from The Verge at the top of this article is that it’s thinking too small. The Verge keeps waiting for XBMC to put out an XBMC box. But we aren’t interesting in putting out our own XBMC box. What we’d much rather do is see HTML5 replaced with XBMC on the television you buy. We’d rather see the proprietary software on the horrible Scientific Atlanta boxes provided by your cable tv operators replaced with robust XBMC software. We’d rather see Ouya become the pre-eminent gaming platform with XBMC as its main media center software. We’d rather kick back, drink some beers at a random bistro in Austria, maybe work on a bit of code, and watch our hardware friends conquer the world for XBMC while we cheerlead.

In other words, “Is XBMC still relevant?” is essentially the wrong question.  The only worthwhile question is this: How much longer will all that other 10-foot UI software even matter? It’s a bit grandios, sure, but does anyone see any other valid competitor with the power to be ubiquitous out there?


Xbox vs Raspberry Pi - Fight!As an early adopter of all things XBMC (by necessity), I have occasionally found myself with a fair amount of old equipment that I’d love to repurpose, but don’t know how. Old component video cables and other sundries just end up in my huge box of cords. Remotes to old dvd players randomly appear and disappear. Power cables that connect to devices that I didn’t know I owned suddenly crop up as if by magic.

Most frustrating of all, however, is this massive, half ton television I bought about 10 years ago, right before HD really started catching on. By all accounts, it was a great TV for its time. It’s huge. It was absolutely perfect for use with the old modded Xbox. And now, as the old Xbox hits its last legs and it’s growing more and more difficult and frustrating to keep the Xbox library of SD content up-to-date, I find myself uncertain what to do with the old lady.

The problem is, I hate to get rid of the TV. I still have a library of SD content and old Xbox games that I’d like to hang on to (plus, it’s heavy and easier to just leave where it is), but at the same time, if I’m going to keep this TV, I’d like it to be able to access all the modern shows and movies I’ve got in my library without having to deal with any irritating transcoding. I’m not a user of Plex, and even if I were, Plex doesn’t really play very nicely with XBMC4XBOX.

On top of that, it’s literally impossible to build any kind of reasonable (i.e. inexpensive) HTPC for this SDTV, because the TV only accepts RCA and S-Video inputs, and inexpensive HTPCs only output to HDMI and VGA (and sometimes DVI). I could buy an adapter, but those things run ridiculously expensive, making them fairly worthless for the simple goal of not throwing away an old TV.

The SD Hardware Solution

All of which brings us to the Raspberry Pi. And more specifically, the composite (RCA) video output that comes built into the Pi. Suddenly, I have an XBMC box that costs 35 bucks and can play back video that the Xbox 1 couldn’t even dream of touching.

Getting the Raspberry Pi for this project, I felt like I was going in fairly blind. There’s not a lot of documentation on whether and how well XBMC works using the composite out. I could very well be blowing a decent amount of money on a paperweight. On the other hand, I’ve got various family members who could benefit from a cheap HDMI-equipped HTPC, so it was never going to be a full loss.

Another one of the XBMC team members, Ned Scott, ordered six Raspberry Pis, because shipping was quicker or something. Since his were expected to come in possibly months before I could get an individual one, I took him up on an offer to just buy one from him.

After a week in the mail, I received my Raspberry Pi. My first discovery was the lack of an on/off switch. The simple solution was to get a remote control electrical socket switch. With this I could quickly and easily turn the power source of my Pi on and off. It’s possible that shutting off the Pi by removing the power source, rather than allow it to shut itself off is bad for the Pi or the SD card where the operating system sits. However, I’m putting myself squarely in the camp of the do-not-care. It’s fast and effective, and the hardware is so cheap as to be easily replaceable.

Next, absurdly enough, I needed to buy a composite cable. It turns out, every device I had connected to that TV didn’t use a standard cable. It used a special cable with a unique port on the device side and a standard composite cable on the TV end. I needed both ends to be standard. Fortunately, these things are dirt cheap at your local brick and mortar store, or online.

While I didn’t have an RCA cable, I did have a stereo y-adapter to connect the Pi to my TV’s audio. So no need to buy that.

Finally, I needed some means of remote control for after I’d completed installation. One of the really cool things about the Raspberry Pi is its built in HDMI-CEC compatibility thanks to Pulse-Eight and their libCEC. Hooking it up to most modern TVs via HDMI allows you to actually control the Pi using the TV’s remote control through the HDMI cable (aka magic). Unfortunately, since I wasn’t using HDMI, I needed another solution.

Enter flirc. Flirc, quite simply, is awesome. It’s just a tiny USB dongle that you set up using your standard Windows/OSX/Linux box to interpret key presses from literally any IR remote control as standard keyboard presses. No need to worry about remote control software or specialty remotes. You can then move the dongle from device to device, and it will remember all the key presses you taught it. I managed to take a remote control from an old DVD player that I wasn’t using and assign all the important XBMC keys to it in a matter of moments.*

*One quick tip though. The version of the software I was using 0.96 has an XBMC specific section, but doesn’t have a button to access the hypercritical context menu. My suggestion is to map out all the keys in the XBMC specific section, then switch to the Full Keyboard section and map a remaining key to ‘c’ so that you are covered.

For an idea of how this works, check out the video below where a user pairs the stop button on his remote to the keyboard letter ‘x’ (the keyboard letter used to stop a video in XBMC).

Finally, the Raspberry Pi was going to need local network access to reach my media shared folders. For me this was a complete non-issue. I already had a LAN cable hiding behind the tv for these exact purposes. Those of you without are going to need wifi support and honestly, wifi support via a usb dongle sounds like a real headache. Unless you are relatively comfortable with following instructions involving ssh’ing, I’d suggest just getting a wifi gaming adapter. These things act like a regular wifi usb dongle, but plug into your Raspberry Pi’s lan port after you’ve followed the direction to get them set up. They’re a bit of an expense, but so astoundingly useful that you could very well be using the adapter well after the Raspberry Pi has been replaced by the next great thing.

Getting the Software Going

I installed XBMC onto the Raspberry Pi. There are a number of different guides found under the Raspberry Pi download link. To install XBMC onto a Raspberry Pi, you have to start by formatting and setting up an SD card on your PC. Because I was using a Macbook Pro, I ended up using Raspbmc, mostly because I was having difficulty following the OpenELEC directions, which appeared more geared towards Windows users. For Windows users, I imagine both should work equally well. I’m not very familiar with Xbian, so I can’t say one way or other about it.

With all that said, installing XBMC was a breeze. I did all the stuff to the SD card on my laptop. Plugged the card into my LAN-connected Raspberry Pi and turned it on. Because there were still several steps left in setup, I plugged an old keyboard into the Pi to deal with the initial work. And 20 minutes later or so, XBMC was up and running.

Initial Impressions

The Raspberry Pi is SLOW. So… so… slow. I’ve got my mom set up with a NVIDIA ION box, which I previously thought was pretty bad, but that’s nothing compared to the Pi. At some point I read a thing that said the Pi’s CPU is roughly the equivalent of the CPU of the Xbox 1, but at half the clock speed. I don’t have that link, and I’m honestly not sure if it’s in any way true, but I’d be willing to believe it.

Navigation of a library is relatively fast, but the initial scanning of that library? Oh my gosh, was it ever terrible. If you have a fairly extensive collection of movies and TV shows, be prepared to wait a good hour for the scan to finish.

I have a feeling a great deal of that problem will be resolved with XBMC 13, if only because I imagine a fair amount of work to better integrate UPnP serving will have been accomplished by then. In an ideal world, my HTPC with its far more powerful CPU running XBMC (or even better, an XBMC Server service) would handle all the scanning behind the scenes. Then the XBMC on Raspberry Pi would automatically have a library hosted for it over UPnP, relieving the Pi’s CPU of heavy strain. That sort of works now, but XBMC’s UPnP implementation still isn’t nearly where it needs to be. For instance, playing a video doesn’t actually mark that video as watched and if you stop a video midway through, you won’t automatically be sent back to that point when you come back to the video. Additionally, once you’ve added the library, the stock skin Confluence currently forces you to access it through the Files folder. Movies and TV Shows won’t be listed as main sections on the Home screen, like they would if you scanned the library locally.

For a video of UPnP as it exists on XBMC right now, check:

With luck, that will all be significantly better by version 13. For now though, the Raspberry Pi remains slow.

The other point worth mentioning is that XBMC for Raspberry Pi doesn’t come with MPEG-2 or VC-1 hardware video decoding. XBMC will still attempt to decode the video in software, but the Pi CPU will definitely choke on any high bitrate video in either of these formats. If all of your video comes in MKVs using the h264 codec, you’re fine. If not, you may want to consider either converting your video or purchasing a hardware decoder license from the Raspberry Pi Foundation.

With those caveats out of the way, my impression of the Raspberry Pi is simple. It blows the pants off XBMC4XBOX. There are still some things the Xbox can do better (playing Xbox games, for example), but for the simple purpose of playing back an HD video library, the Raspberry Pi is absolutely fantastic.

If you are going to install an XBMC box for an HDTV, I probably wouldn’t recommend the Raspberry Pi.  It’s great for hacking and probably still more awesome than a Roku,* but right now I’d easily recommend something like the Pivos XIOS or another more powerful Android box, if you’re looking for a set top box.

*Insert biased pro-XBMC stance here.

But if you’re like me and you want to repurpose an old SDTV, there’s seriously no better way to go than the Raspberry Pi.


There are approximately 30 to 40 core developers of XBMC, of whom probably 15 are directly involved in the release of any particular version of XBMC. Each operating system has a boss whose job it is to say that XBMC is working in his environment. Above the OS boss is the Release Manager, who ensures that no more code is entered into XBMC once we hit our target release date and who is primarily in charge of ensuring that all the coding changes that need to be made for the update are made, as well as limiting code changes (made by something called PRs) to fixes, rather than features.

There are also packaging managers. These are people who focus on making sure that XBMC is compiled and built correctly and then placed in the proper folder for easy access to Windows, OSX, iOS, and AppleTV builds. One person maintains the Linux PPA (aka the Linux repository that allows individuals to easily download and update). One person maintains the XBMCbuntu package.

Other people manage scripts, plugins, and skins for the addon repository, as well as flagging compliance with our API and json-rpc calls.

Are all the ducks in a row yet? … Nope.

One person heads the wiki for installation instructions and FAQs about all the new updates. And finally, one person makes sure all the ducks are in a row and writes up the announcement.

That last person is me, and boy do I have a story to tell.

 

 

Taking a Step Back

If it isn’t already clear, XBMC is BIG. Like, really, really big. There are actually more lines of code in XBMC than in the entire Android kernel. Admittedly, quite a bit of that is probably related to 10 years of history with limited pruning, but consider this: XBMC can act as a full OS front-end replacement. When paired with a fairly limited number of Linux packages, it literally acts as an Operating System (in the form of OpenELEC). On every platform, it has the ability to launch programs. On Android, it appears to launch programs exactly the same as the standard Android launcher.

Given the sheer size, the fact that we have several people who understand the platform well enough to act as Release Managers is absolutely astounding. We have been lucky at least once with this release as long-time XBMC dev Spiff agreed to helm the position for Beta1. For personal reasons, it appears he won’t be able to head up Beta2, but almost immediately after informing the team, several other individuals with the requisite knowledge offered to step forward.

The release manager position is a brutal one. The issue isn’t simply one of knowing when XBMC is ready for Beta. It’s also having to make decisions about what code is a fix and what isn’t, and then taking a daily stand against developers who disagree. Telling people no, over and over, particularly when they’re convinced they are right (i.e. the entire XBMC development team… ♡ you guys!) is exhausting and has been known to lead to quite a few heated arguments.

But we have individuals who step up, drink a LOT after the release, and somehow manage to get on with their lives. More than anyone else, this story is dedicated to them (and particularly to Spiff, since this story is all about how we hit Frodo Beta 1).

The Decision to Feature Freeze

Because XBMC is not part of a larger corporate hierarchy, there is no decision made by higher ups to hit a target release date. Usually, we just keep working on the software and adding features until somebody says, “Well, that seems like enough.”

With Frodo, things were a bit different. At the end of Eden, we already had a tenuous list of items that we all agreed we’d like to see in Frodo before releasing. These were features that had been requested for quite a long time. They were:

  • HD Audio
  • PVR
  • h.264 10-bit decoding
  • Jim Carroll’s code generation work to improve the communication of core XBMC with addons (primarily an internal request)

The first item made it in almost immediately after Eden was released. HD Audio had been ready for quite some time. The Team was hesitant to pull it in, primarily because it was practically guaranteed to break things since audio touches so many other pieces of the project.

The second item to make it in was 10-bit decoding. For the most part, that was simply an ffmpeg update.*

*I say “simply,” but let me assure you, an ffmpeg update can be a truly painful experience, given the degree to which the code is patched to fit in XBMC.

Third in was PVR. The primary holdup for PVR, for quite some time now, has been the lack of binary addon support. As you may know, a major goal of XBMC is always to follow the KISS principle. Though we had planned, long ago, not to become full time developers of any PVR software, we wanted to make the addition of a PVR source as simple and painless as possible. To make that happen, XBMC needed to be able to simply install the PVR software itself. We call the installation by XBMC of full applications “binary addon support.”

The ability to install and launch full programs is an inconsistent one between XBMC platforms, and figuring out how to make that ability consistent is something of a coding and logistical nightmare.* Eventually, with Frodo, we decided we weren’t going to let the nightmare of binary addon support prevent us from pushing PVR support. In theory in the future you will be able to install full packages of other open source software, like the PVR server TVheadend, so you don’t have to look elsewhere to get your PVR support. Right now, because we don’t support binary addons, you have to install and configure TVheadend yourself. It’s not ideal, but at least users now have the option.

*This, by the way, is the reason XBMC doesn’t self-update. It would need to launch an updater across multiple platforms. Since it CAN’T do that right now, the only instances of self-update are ones externally provided.

Nope, still don’t get it.

Fourth on the listed of necessary for Frodo items was Jim Carroll’s code generation work. I’d try to explain that stuff to you, but I barely understand it myself (read: honestly, don’t understand it), so I’m pretty useless on the topic. Anyway, that final piece of the puzzle was added a mere month ago in October.

And with that, we entered Beta phase.

 

 

A False Start

I already spoke about the unpleasant job of Release Manager. I won’t rehash that bit, mostly because the time from feature freeze to a few days before beta release is pretty boring. Devs read bug reports, look at bugs, and then fix them. There’s very little drama in that, beyond the drama already described. The drama this year has been even more limited than normal. People are used to spending 2/3rds of every month purely working on personal things or bug fixes. In many ways, Frodo is likely the single most stable Beta1 of XBMC in the long history of the organization,* thanks in large part to the Team’s dedication to the monthly merge cycle.

*For the sake of clarification, I am referring to stability in the core code. We’ve already discovered some major errors in both XBMC for Windows and XBMCbuntu that were the result of an ugly build process. Simply rebuilding those versions of Beta1 resolved the errors.

Seven days before the unofficial due date of Beta1 and a mere three days after feature freeze, Jonathan Marshall added Frodo labels to all github issues and PRs that he believed were Frodo material.

Five days before the unofficial due date, Spiff wrote, “ping. 5 days to beta 1. what’s the status on platform foo?” In XBMC lingo (possibly all dev lingo, I’m not sure) this means, approximately, “Hey guys. We’ve got 5 days. I need each of the platform bosses to give me the thumbs up or down on the status of Linux, OSX, Windows, iOS, and Android. Is each platform free enough of bugs to put in beta?”

Montellese and Martijn gave the thumbs up for Windows. Memphiz and Scott Davilla gave the thumbs up on OSX/iOS/atv2.  Spiff himself gave the thumbs up on Linux. Cory Fields put up the red flag on Android, because it was guaranteed to crash any and all Android devices that didn’t include the NEON extension upon launch. After a quick huddle (primarily between Cory and myself, as we were the ones most likely to deal with the resulting furor and chaos), we decided to push releasing the first Android apk to a later date, to make sure we didn’t crash half the handsets in America.*

*That’s right, Android fans. I’m about 50% of the reason you still have to look to third parties for your XBMC apks. My bad! :)

The only real issue was the Linux ppa. As I said, Spiff gave the go ahead on Linux itself, but with each platform, the platform chief go-ahead is only half the equation. The individual in charge of building and hosting also has to give the green light.  The problem was, we literally DIDN’T HAVE a chief to build and host a Linux build on our ppa.

For those unfamiliar with how installing applications works in Linux, it’s fairly simple. Picture the Apple Appstore. Now realize that that is how Ubuntu has been installing most applications since the early 2000s. Maybe even earlier. Possibly since the 90s.* Essentially, anybody can make their own Linux Appstore and Linux users can download from that store. Except in Linux-land, this store is called a “ppa.”

*As a guy who tends not to use Linux, it’s often depressing to me to realize how far behind my platforms of choice are compared to Linux (or, at the very least, Debian).

Sadly, not the wizard we were looking for.

The problem is, essentially nobody on the team had any experience setting up a ppa. We’d gotten somebody else to do it for Eden, and he was fairly busy this go around. So Piethein (one of our XBMCbuntu wizards) and I began questing for a new ppa wizard.

November 9th struck. One more day until unofficial release day. I sent out a team-wide email to make sure everyone was informed that tomorrow was release day. I’d already written the release announcement. The only thing left was to make sure there weren’t any major stoppers.

Spiff had already said if we couldn’t get a ppa guy or figure it out on our own, we were going to go ahead with beta1 regardless. So ppa itself was not, technically speaking, a showstopper.

Needless to say, even without the Linux ppa, there were still several potential stoppers to deal with.

Number one on the list was the lack of the Frodo addon repo. For those not aware, every major release of XBMC comes with its own repository of addons. This is done for a couple reasons, but the primary one is to ensure that we don’t have dozens of outdated addons listed in our repository that don’t actually work. That kind of thing looks good for no one. We had not yet created a new repo, and we certainly hadn’t ported the known working addons over to it. Whether that would stop the beta was unknown.

Additionally, at almost the exact same time as I had sent my email, we had invited wsnipex to join the team and manage our Linux ppa. He’d already had quite a bit of experience in the field and seemed like a natural choice to lead the effort. It was destined to take a certain amount of time before he had access to our launchpad.net unstable ppa account, but that time was absolutely worth it. Whether he would get that time was less certain.

“I’m sure a sonic screwdriver could help you with your buildbots!”

It was beginning to look like whatever beta we put out would be ugly and incomplete, but then, like a gift from a Doctor Who Christmas Special, we were granted a bit more time. Almost in unison, practically all the XBMC platforms suddenly stopped building in our buildbot. November 10th came and went. Throughout the weekend, devs were scrambling to get the our buildbot building again.

Suddenly, we had plenty of time to get Linux going and the addon repo moved over, but on the flip side we had no idea when beta1 was going to come out.

Bringing It All Together

Over the weekend, wsnipex got the keys to the ppa. In very short order, he began performing successful test builds. Piethein (aka Erhnam) used those builds to create XBMCbuntu packages in a split second. The Linux side was looking good.

By Tuesday, Cory had gotten the Frodo addon repo in place.

On Wednesday, Spiff, Cory, Martijn, Olympia, and Montellese all moved as many addons as possible in various categories to the new repo. Only skins were left out, as it was decided each skinner should make the decision whether to move to the new platform or not. Spiff tagged. The Beta splash screen that users see was added to the Beta. And the build errors had all been worked out.

As a great deal of work had been accomplished, many of the devs drifted away. I determined it was time for dinner, but stated generally that I’d really prefer to see the beta released on Thursday instead of the weekend. Martijn noted that since Spiff had tagged beta, there was really no reason not to start building right now. I asked Martijn if he knew how to kick Billy the Buildbot and build the Windows, OSX, and iOS betas. He said he could probably riddle it out. I left him to it.

That evening, after dinner, Cory informed me that the Windows and OSX builds were done. We shifted those over, and I posted links to those builds on our download page.* I decided that it’d be a fun treat for those individuals who happened to stumble upon the downloads page to get an early copy of the beta before everyone else. My plan from that point forward was to post up each install as it came online.

*I also posted a link to our donations page on the downloads page. One of our big goals over the next twelve months is to be able to pay for our own developers conference without relying on the aid of a big corporate entity.** The more XBMC is for the people and financed by the people, the better we believe the whole product will be. That starts with making the ability to donate simpler and more visible. 

**In other words, if and when you donate to XBMC, you are welcome to think of your donation as a contribution to the “Keep XBMC Away from Sony” foundation! (Of course, legally speaking, our Foundation cannot be swayed by big corporate interests, as that would violate our 501(c)3 non-profit status tax protection, but probably just ignore that fact while you donate!) 

With Windows and OSX up, we were still missing Linux, XBMCbuntu, iOS, and AppleTV. It was 11PM on Wednesday night.  I emailed wsnipex and Peithein, asking them if they could get a build off in the next nine hours.

An hour or two later, after going over the announcement with a fine toothed comb and asking several other devs to take a look at it, I emailed a few news outlets who we have pretty good communication with, filled them in on the full story, and asked that they refrain from publishing within the next 12 hours, or until I sent them the go-ahead.

At 2:30AM (aka around 8:30am in Europe), wsnipex returned to the land of the living and began building. An hour later, after one false start, the Linux unstable ppa was ready to go. I updated the download page to reflect another source available.

By 4AM, Piethein had built XBMCbuntu, but a new problem cropped up. Nobody online had the access keys to upload XBMCbuntu.*

*A new board was recently elected for the XBMC Foundation. I was elected secretary, probably because I don’t like to write. ;) I think one of the very first things this board should do is put together a list of all passwords to ensure that we have double and triple backup to access accounts when necessary, regardless of the local time of day. 

Shortly thereafter, Amet appeared. Amet is in charge of uploading iOS/AppleTV builds. Curiously, even though XBMC for iOS has been around for quite a while, this is the first time we’ve had to replace the stable iOS version on Cydia, since the last version, Eden, was the first stable version of XBMC for iOS.

Between Amet, Ned Scott, and myself, we worked out that we could place the beta in a separate repo folder. Doing that allowed people without that new repo installed in Cydia to download the stable XBMC Eden. Further, those excited for the upgraded software would be able to simply add a second url and easily grab access. We had Ned update the wiki explaining all these new options.

That covered Windows, OSX, iOS, and Linux. The only thing missing now was XBMCbuntu. But it was seemingly not possible at that time (or within the deadline set for the press) to get access to that portion of the XBMC Mirror in order to get XBMCbuntu uploaded.  So I made a command decision. We would publish now with a note that XBMCbuntu would be available asap.

This is almost exactly what I looked like!

And so it was, at 7:06 AM on the 15th of November, 2012, Beta1 of XBMC 12.0 was officially released. I emailed various members of the press. I posted to Facebook, Twitter, and Google Plus. I dealt with early comments and cleared some last minute issues and hurdles. And then, exhausted, I fell into my bed. The thrill of a major release can do wonders for keeping a man running well past bedtime, but eventually the adrenaline wears out.

 

Some Final, Personal Thoughts

Man, do I ever love releases. As some of you know, I’ve been unemployed for quite a while now, except for the occasional website contracting job or social media task. Generally, I attempt to combat this by applying for Community Manager or Marketing Manager positions and hoping that employers will be impressed by all the work I do for XBMC and the resulting success we’ve experienced in increased adoption rates, increased social media subscriptions (we now have 30k Facebook followers, up from 6k when I took over, all on a budget of literally zero dollars!), and increased site traffic. But I suppose I’m going to have to work to even harder to make employers pay attention, because so far I don’t appear to have impressed anyone.

Anyway, with this release (and, honestly, the release of Eden before it), I’m beginning to wonder if I somehow missed my calling.

Maybe it’s the team I’m working with. Maybe it’s the multi-platform nature of XBMC. Maybe it’s the way I get to have my fingers in so many pies, working with half a dozen team leaders and devs, the press, people from numerous continents, and users that literally span the globe. I honestly couldn’t say….

All I know is that I wish for-profit companies had some kind “Non-technical Release Manager,” whose job it was to push a software product release out the last few legs of the journey. Because working with this team to coordinate such a monumental release of theoretically boring beta software is better than the best runner’s high, as far as I am concerned.

People always say you should try to turn what you love into a career. I’m fairly sure the world literally doesn’t have a job that lets you do all the things I enjoy doing for XBMC (last spring I even helped re-write the Corporation By-Laws!). But if it did… man, would I ever be jealous of the guy who was more qualified and happened to live geographically closer to the company that was hiring for that position, because he would be one lucky guy!

Some Final Impersonal Thoughts

Whether Beta2 is going to be as tricky a release remains to be seen. The odds seem to be against its being all that unpleasant. Now that we have a ppa maintainer in place and the Frodo repository exists, we should be all set. On the other hand, I’m fairly sure we always feel that way, and some last minute problem always pops up that requires some degree of scrambling. That’s just how life works.

Still, I’m hopeful for beta2, and also somewhat hopeful that we’ll have at least one nice little surprise for everyone that’s still waiting in the wings.

Other Notes

One of the biggest problems we have, building, may become much less problematic in the near future. Cory Fields, often times the primary build manager, is looking to switch from our current buildbot to Jenkins, which should theoretically make the entire process easier and more automatic. If we do end up traveling down that path, I’ll let you all know how it goes.


The following post is my letter to Nilay Patel regarding his take on the recent decision by Boxee to drop support for the Boxee Box in favor of their new hardware the Boxee TV. As always, the opinions expressed below are mine alone and do not necessarily reflect the opinions of the XBMC Foundation or Team XBMC.

Hey Nilay,

First, let me say I’m a big fan. Your take on software patents totally changed my thoughts on the topic. Nice work.

Second, I’d like to note that while I am an XBMC Project Manager, I am speaking only for myself, and my words should not be taken as a representation of XBMC the Team or XBMC the foundation.

With that said, I felt the need to address your recent column on Boxee TV. If this starts a conversation, awesome. If it does not, life goes on.

As far as I can tell, the last time the consumer has won a victory in the American court system and legislature with regards to copyright was 1984 with the famous (or infamous) Betamax case, when the court ruled that time shifting was fair use.  Since then, as far as I can tell, every single piece of legal opinion and legislation has been designed to limit or minimize the decision of the Betamax case.

Today, people can stil record and timeshift for personal purposes under Fair Use, but they cannot break encryption, share with friends and family, download software that enables the breaking of encryption, or access unencrypted cable content (thanks, FCC).

In other words, people have the right to fair use, but they barely have the ability.

For the past several years, Boxee has been one of the lone for-profit companies who appeared actively to be defending the rights of consumers to consume content the way they wanted. The “weird video files” as you described them were the mkvs and mp4s of users who had decided to take the Betamax case to heart. Every mkv video file had been legally created by an individual who recorded an episode of TV (as was his right), stripped out the commercials of the episode (as was his right), and then shared that episode without any intent of profitting from sharing (literally the first – and by extension most important – factor of the Four Factors Fair Use test, until recent legislation and political lobbying made the first factor, as it relates to the nonprofit nature of the use, the least important factor).

Boxee ensured that users could playback these files, along with almost every piece of content online. They actively promoted the ease of writing a simple plugin to make online video playback simple. Indeed, they fostered an entire community of plugin developers devoted to making the Boxee experience better!

However, now Boxee appears to have completely reversed course. They no longer support “weird video files.” They no longer provide users with a simple way to access content that those users have a legal right to access on the TV. Two years ago Jeff Zucker railed against Boxee to Congress and said that they were “illegally taking” content, when it was absolutely clear that theft of services was simply not occurring. Then, rather than taking Congress’s decision to side with Boxee in the case of Comcast’s acquisition of NBC to heart, the Boxee team have been actively working to make online content access more difficult. And they have been doing so ever since they moved away from the Boxee software platform to the Boxee Box platform and now the Boxee TV platform.

Old avacados are yucky!

Needless to say, that community of Boxee plugin developers has now been tossed aside like yesterday’s avocado dip.

It was nice to know that once upon a time there was a for-profit company who actually wanted consumers to have some kind of Fair Use rights. It is disheartening to find out, in retrospect, that they no longer have that goal.

But the fact that Boxee does not appear to care about the fair use rights of consumers is not the only disheartening issue in the column you wrote. Indeed, it is not even the most disheartening issue. The most disheartening issue is the fact that they appear now actively to be working AGAINST those very rights. You quoted Avner stating that 89 of the top 100 shows were on broadcast TV, and 95 of the top 100 events were on broadcast TV. By definition, this means that the vast, VAST majority of consumed TV content can still be gotten without the need to break encryption, which means users can do with their content as they please.

Except consumers can’t do so using Boxee TV. With a Boxee TV, the only recording option of the user is to convert the video file to Boxee’s preferred format, encrypt the file, and then send the file to Boxee’s cloud service. There’s no local storage. There’s no sending the file to an alternative cloud storage. And there’s no accessing that file using software that doesn’t meet Boxee’s standard. The only right users had with broadcast TV, the ability to do with it as they pleased, Boxee is working to remove.

I think all of that is disappointing, disheartening, and lacking in a certain degree of morality. I don’t find it at all funny. I do not guffaw in merriment at the incredible way in which Boxee appears to have turned its back on all the people who have supported it for the past several years. I do, however, find one piece of your article humorously ironic. Two years ago, Boxee had the good will of the people. They were the mouse roaring in the faces of the lions of Comcast and NBC and Viacom and every other industry bully. They had over 2 million users, and all signs pointed to more and more users as time went on. Then they dropped software support and lost approximately 1.8 million users. Now they’ve dropped the Boxee Box, and managed to lose the remaining 200,000 users. And yet now, with their own actions resulting in a user base approaching zero, an incredibly uncertain revenue stream, and goodwill so far into the red that it may never see black again (have you seen the comments in Boxee’s announcement?), you managed to get this quote: “We weren’t as savvy… I think now we’re much more sophisticated.”

I can’t decide whether to laugh or cry or simply shake my head in embarrassment at that statement. It appears Avner has mistaken business savvy with getting wealthy corporations as friends.  Though maybe I’m wrong. Maybe the move to strip user rights away and marginalize one’s company in the grand scheme of things will ultimately make Boxee stronger and more profitable. I like many of the Boxee dev team and hope to see them successful, so such a result would be nice for them. But from a consumer standpoint, and from the standpoint of a citizen of the United States, I certainly hope that this move is the final nail in the Boxee coffin.

Most frustrating of all is the fact that, as an XBMC team member facing yet another rush of ex-Boxee users, I should be very pleased with this decision, but honestly, I’m not. Boxee, Plex, and XBMC have all been pushing each other to advance over the past four years. The competition for eyeballs has led to some incredible software (and a few stinging words). With Boxee’s decision to go down the Boxee TV road, I’m afraid the world will be left with one less competitor dedicated to true innovation for the sake of the media consumer.

In the end, as always, it is the user and the consumer who loses. And that sucks.

Sincerely,

Nathan Betzen


As many of you know, I wear like 8 hats in the XBMC community, from publicity guy to project manager to operations to administration to junior business dev in training to whatever the team needs this week. But the hat I most frequently find myself wearing (and the one I tend to identify myself as the most) is Community Manager.

That means I’m the guy who posts on Facebook and Twitter (and when I remember, Google+). I’m the guy who usually tries to mediate any major forum disputes. And I’m the guy who works to connect the developers to the users.

The thing is, I think it’s fairly safe to say that I could be doing a better job. Honestly, if you run into a Community Manager who doesn’t think they could be doing a better job, you should probably work to get that CM fired. This isn’t the kind of position that rewards resting on one’s laurels.

I mention all that as background for some thinking I’ve been doing over the past few weeks. One of the distinguishing features of the XBMC user base is an extremely dedicated community. Our user base loves XBMC and loves talking about XBMC. They like to show off their installations. They like developing addons and showing off skins and collections. Honestly, I’ve been a part of a number of online communities, and the XBMC forums and social network sites are extremely high up on the list of  site where sharing pictures, words, and video is just the standard thing to do. We have well over 100,000 forum members, and as many as nearly 5,000 of those members have actively been interacting on the forum in a given moment. We have over a million posts on over a hundred thousand threads. On a typical day, the forum is visited by an average of 33 thousand unique visitors.

The problem, as I see it, is that we have all these actives users and all of this user generated content, but our site is simply not designed to take advantage of it all. Anything in the forum has to be replicated on the front page. A great deal of work must be done to cross over a gate, and because doing so is so much duplicated effort, it is rarely done.

So with that in mind, I thought I’d take a minute to run a thought experiment on what WOULD be an ideal site for the XBMC user base. One that breaks down barriers and allows the entire community to quickly and easily learn about what things are going on, taking advantage of user content as it occurs.

My Ideal XBMC Site

To start, I think it goes without saying that my ideal XBMC site would be a community/reddit site. The most visited portion of the site is ALREADY a community site, in the form of the forum, so dramatically extending that portion of XBMC.org seems like a no brainer. Except instead of being presented with a list of categories and having to search for worthwhile content, each registered user would start at either a newsfeed page or their personal profile page.

The personal profile page would include a picture of themselves, an avatar they’ve chosen from either Gravatar or somewhere else, or a picture of their setup. For comparison, the Google+ profile About page is pretty decent, if unfocused. In addition, users could select whichever skins and addons are their favorites. Perhaps at some point in the future they could even connect their copy of XBMC with their profile, so any addons they had installed would show up on their profile, and any addons they like on the site could be installed to their machine, similar to the Google Play store.

The profile page

On a second tab in this section, users would have the opportunity to blog, more in the manner of tumblr than WordPress or Blogspot, and they’d have a feed of past blogs of theirs. Users could write a few words or a few thousand words. They could upload pictures. They could possibly even link to Youtube or Vimeo video feeds that were somehow XBMC related. Users could ask questions and hope for answers from the community with the option of sharing as much or as little as they liked. Finally, before submitting the blog, they would be asked to tag the blog among a list of popular current tags, or create their own tag. Pre-existing tags might include XBMC for Windows Help, My Rig, Hardware Questions, or XBMC in the News. I suppose they could also post a link to the blog/question/whatever to their preferred social networks like Facebook or Twitter or Reddit, if they wanted. If they included a link under a particular tag, the system would notify them that the link in question had already been posted, and would suggest that they instead participate in somebody else’s discussion.

My Activity page

Finally, the third tab of the profile would be the Newsfeed. This feed would include a default of major news posts as selected by Team XBMC, as well as any posts that day that have been +1′d or liked or whatever enough to take up 3 or 4 (or more) spots. The feed would also include any posts of people that users have added as individuals they’d like to follow. For example, if a skilled skinner who is not a member of the team posts a lot about his awesome new skin, a user might choose to follow that skinner to catch all the exciting news about the skinner’s skin.

The Home Feed page

In addition, users could click on a field of popular tags, or do a search for tags that might be of interest, similar to the redditor’s ability to browse subreddits. In this way, we’d let the community decide what categories are really important to XBMC, rather than imposing the best guess of Team XBMC on a bunch of pre-determined categories. The categories that currently exist in our forum would naturally be converted into tags in this environment, and all past forum discussions would be pulled into this tagging environment. Also like subreddits, each tag could be given its own identity, with a community-provided background and a brief description of what the tag is about. For example, a General Help tag would include the description “Need help with XBMC? Please post under this tag if it’s a platform independent issue. If it is platform specific, we recommend posting in Windows, OSX, Linux, iOS, or Android.”

Somewhat unlike reddit, topics would not be weighted quite so heavily in favor of the new over the popular. If a topic continues to gain discussion over time, it would remain pretty high on the list, particularly in its given tag. Underneath the community nature of the site, a key goal would naturally still be to solve problems and make the user experience of XBMC better.

Other Pages on the Site

So those’d be the primary sections of the community site. Naturally, such a site would also require a certain number of “helper” pages that sort of fill out the XBMC mission.

First, there’d still be a front page for people who are not logged in that gives a quick overview of XBMC, provides a number of links, shows the current popular feed and current popular tags, and generally acts as a landing page.

Second, there’d be a download page, so users could easily download and install XBMC.

Third, there’d be an Addon page that users could browse and interact with to connect addons to their profile.

The Addons page

Fourth, there’d be a very simple “About Us” page that explains what XBMC is, what the mission of the Foundation is, and possibly links to the profiles of the members of Team XBMC.

Seriously, how awesome are these shirts?

Fifth, there’d be a “Contact Us” page that’s similar to the one already present on xbmc.org.

Sixth, there’d be a shop page, where users could browse XBMC merchandise and buy designs they liked. For example, a shirt similar to the 2012 DevCon shirt might be a popular seller.

Finally, there’d be a Wiki section that does what the current wiki does: namely, maintain a single repository for XBMC information that lasts over time.

Conclusion

The most important part of any community is… its community. It is the users, the fans, the people who like the topic more than the topic developers. XBMC always promotes from within the ranks of the fans, because those fans are the ones who have already dedicated so much of their time to a project that we all love.

As such, it seems right to me that any major step forward we take on our website is one that celebrates that community of users. To that end, if you happen to have any web coding skills, particularly of the js/php/python variety, or if you just feel strongly about this topic feel free to speak up. I’d love to hear your comments.

(Webpage mockups courtesy of balsamiq.com. Seriously, if you’re into webdev, Balsamiq is a must.)

The sitemap as currently proposed


One of the most exciting ideas put forth at this year’s devcon was a concept called the XBMC Mesh. It was a natural extension of Alcoheca’s GSoC project and is slated as a potential feature for the version of XBMC that comes after Frodo.*

*Somebody seriously needs to come up with a good ‘G’ name.

Today, we have software that works like XBMC, where there’s a database and a player all built together in one piece of software. We also have software like Plex, where the database has been pulled out and acts as a central server, and each instance of player software acts as a mindless drone being controlled by the all powerful server.

But what if there was a third way? What if a system were developed where each software instance was intelligent and could communicate with other software instances? For example, you set up XBMC for the first time on your tablet, then when you are done, you receive an Android set-top box in the mail with XBMC pre-installed; you plug that box in, and it announces itself on the network.

Mesh systems are pretty awesome.

Your XBMC tablet sees there is a new instance of XBMC on the network and asks you, “Would you like to add the set-top box to the mesh?” When you say yes, your XBMC tablet tells your XBMC set-top box where all of your shows/movies/pictures/music are and what addons you have installed. Rather than relying upon the tablet or other server for this information, the XBMC set-top learns where everything is located itself, so that it can always find it if the tablet has been turned off or taken out of the house.

Now, because these devices can intelligently communicate with one another, every single one of them can act as a remote control for one or all of the others. Your tablet can watch a show or tell your set-top to watch a show (along with play, pause, fast forward, record, etc.). You could theoretically start a whole-home audio session. You could, naturally, start watching a show in the living room, continue the show on your tablet in the bathroom, and finish the show in your bedroom.

And the crazy thing about this network is that it would be incredibly easy to set up. You tell one device where your content is, and all the rest of the devices know. You turn on your set-top for the first time, it sees the network, and it asks if you want to join. Heck, each device could even be smart enough* that if you, for example, took your tablet to your sister’s house, it could ask if you’d like to switch networks and keep a memory of multiple meshes.

*Eventually, of course, it would become so intelligent that it would decide to destroy all humans. Hopefully that won’t happen until we finally find out who the mother is on How I Met Your Mother.

An important aspect of this mesh system would be in playing nice with devices that exist outside the mesh. For example, the set-top box would likely need to interact with IR remotes and communicate with the CEC of your TV/receiver. Naturally, each device (particularly, each non-mobile device) would need to act as a uPnP server (given that most of the communication would be done via JSON and extended uPnP in the mesh in the first, this should be quite natural) for legacy devices that can only act as DLNA/uPnP clients. Given the cost-effectiveness of ARM hardware and (thanks to Sigma Designs) now MIPS hardware, it would arguably even be possible to set up an inexpensive router with headless XBMC software that not only acted as a mesh base, but also behaved like a simple router for the home network.

Of course, there are some challenges that would need to be ironed out with this idea. Would you still have to share your local content over something like SMB, or would you install XBMC on your local content server(s) and make it(them) act as uPnP servers for the mesh? Would it be better for there to be a shared database that each software instance latched onto while it was in the network, or would it be better for each instance to write to its own database? Or could you do both, so that the library immediately appears on your device via the shared database, but a redundant local database is written in the background while your CPU is idle or you are watching a movie or something? How would you deal with new binary addons like PVR backend addons that are entirely separate programs?  Would each device have to install the binary addon to be able to make use of it, or could you stream from the XBMC instance that has the PVR addon installed and simply communicate with that server via JSON? In fact, would it be possible to abstract out nearly everything to do with XBMC and connect it all together into this mesh, so that, in addition to the normal library, addon settings and other personalized aspects could be shared along the mesh.

Needless to say, something as massive as this idea isn’t going to happen over night. It might not happen at all. To put an idea as huge as this together would take a lot of smart people and a lot of man-hours. But my God, would it be awesome.


20120902-162635.jpg

Sunday

OpenELEC

At this point, OpenELEC is very well branded and somewhat unsynced from the XBMC dev cycle. There’s a question about whether we should push to pull OpenELEC fully into XBMC and call it XBMC powered by OpenELEC or OpenELEC powered by XBMC, or something.

At the moment, an idea is that OpenELEC could act as a sort of XBMC Stable or LTS branch, where both XBMC and the underlying OS are rock solid. Fully integrating OpenELEC and standard XBMC is looking like a long term project that may never actually happen, in the sense that we may always do something like releasing Frodo, and then intentionally hold OpenELEC back until 3 or 4 months later to ensure stability.

What ends up happening remains up in the air.

New Project Managers

Keith and Jim have agreed to become additional individuals who will be available to answer contact emails and work with businesses interested in working with XBMC, in addition to Cory, Pike, and myself.

TheTVDb

The TVDB recently lost much of its free internet hosting. Now, they need ~$500/month. The TVDB is massively critical for XBMC, so we need to review how we can help. One suggestion is to overhaul our UI so that when users add shows or movies or whatever, the scanner actually displays our scraper site (e.g. TVDB, MovieDB, FanArt.tv, etc.). In theory, the more other people actually SEE where their info is coming from, the more likely they are to get better donations.

Alternatively, any sites that we absolutely depend on we could work on trying to offload some server time. This is less easy to accomplish, but at least worth looking into.

Meanwhile, I need to do a post about all of the sites that we absolutely depend on a daily basis.

Saturday

Internal Discussion

4:30PM Vienna Time

Frodo

Current code stoppers: Code generation, PVR, Raspberry Pi are the three big pending changes.

Arne (aka Spiff) will be acting as the Frodo release manager. This is a newly created position that essentially says, “Beta 1 happens on this day. We are now ready for RC1. Time to release.”

Other discussions during this period include how to better manage the way XBMC deals with addons during the Beta period and how to handle skins that are missing certain xml pages and links. The typical question is, “Do we let a skin into Frodo, if it doesn’t support PVR?”

PVR

Lars is now Skyping in to talk about PVR. Right now the primary issue is that we need more people to work on PVR. In the past, the largest problem has been binary plugins. The first suggestion is simply to drop binary plugins. That’s possible now.

So… there’s really no other stopper. Without binaries, PVR is possible now. The September Cycle is going to be an exciting one!

One important issue is that PVR is the first bit of XBMC code where we don’t provide all the software to make things happen. That means that those users not directly plugged in to the XBMC blog/forum/wiki are going to be very confused when they click the PVR button and nothing actually happens, because they don’t have a TV tuner or TV decoder software. The currently accepted solution to this issue appears to be to create a pop up that says, “You don’t have a TV tuner and TV decoder software connected, and you need them. Please visit xbmc.org/PVR (or something) to learn more.”

3:00PM Vienna Time

Monthly Merge Window

We are now reviewing the monthly merge window. As you recall, each month we have 10 days to merge, 20 days to clean code. There is a debate whether to increase the merge window, whether to set aside a portion of the merge window for big updates, or what.

The primary issue is that code change is difficult to manage. While Mozilla has the resources to employ 20 or 40 builders and testers, 30ish people is our entire dev team.

One solution to breaking is to try to break up big commits into small packages that each get pushed in, so we can know which small portions appear to be breaking and which aren’t.

Trac

Possibly somebody else can fill this in. I pretty much blanked out for this entire section. Mostly, it was Github = not everything we want. We have a ton of open bugs that are probably super old and out of date. Many don’t actually look at Trac.

Documentation

Ned Scott explains mediawiki! In particular, we learn about python scripts, and templates.

12:30PM

GSOC

Jonathan summarized GSoC by saying that GSoC is awesome. We had four projects that we semi-called for at the beginning of this year’s project and they’ve done a great job greatly improving our library. It’d be nice to have more mentors this year and also a GitHub admin whose whole job was to harass students to make sure they were doing weekly code.

We’d also like to better work with the team calendar so we have a better chance of making sure we actually get into GSoC every year.

Amejia’s project comes next. The goal for Amejia’s project was to create a series of tests to make sure various aspects of XBMC work underneath the hood without needing error reports. For example, archiving within C++ does not appear to have been working for the past 10 years, ever since it was first written into XBMC.

Montellese came first. The situation that his GSoC was intended to deal with was users with huge video and music libraries and very little way to to easily get to each item.

His solution was to use Smart Playlists (essentially smart filters to narrow video and music lists). Unfortunately, Smart Playlists have not been very easy to use.

His plan was to speed up these SPs, integrate them into the library, etc.

First, he had to refactor sorting and limiting functionality. Then he added the ability to short or limit by artist, in addition to albums.

Then, he wanted to extend rule searches. For example, after his work, you can do a search for a list of movies of Nic Cage and Bruce Willis.

This is only available in Library mode, as it depends on the database functionality in the Library. Filters differ based on type. So you could sort by type of instrument in music, but you wouldn’t get to sort by type of instrument in movies, because that wouldn’t make sense.

You can actually see Filter in current nightlies.

Topfs2 (aka Tobias) came second. His GSoC was a Clean Scraping API. Tobias has put together an information extraction program called Heimdall with the goal of not worrying about content type (movies/music/tv/sports/whatever). Additionally, both outside scrapers and XBMC could potentially use it together. Finally, scrapers typically work right now by first looking for a title, then looking for built-in metadata, then reading the stream, then finally visiting a scraper website such as TheMovieDb. With Heimdall, we can perform the scrape on the computer separately from scraping on the website, so scrapes can perform faster and more efficiently.

There are no plans to fully integrate or replace any current XBMC scrapers at this point, but future potential is high.

Alcoheca has updated the latest UPnP server, started cleaning up code, etc. He’s now added a port for media control, so if you have 2 XBMC devices in your home, you can watch a percentage of the show on one device, then send the rest of that show to another device. Additionally, the XBMC device essentially acts as a remote control for another XBMC instance. In essence, this works somewhat like AirPlay, but with more extensive possibilities. Additionally, the uPnP client is being extended to better show metadata.

This isn’t available yet, but it is on the horizon in the near future.

Company Presentations

11:15AM (Vienna Time)

AT-Visions (the primary host of this year’s DevCon. Thanks guys!): They use XBMC as their frontend for Hotel IPTV systems. It actually looks quite a bit like XBMC, except with extended functions that work more with Hotel systems.

They’ve moved from NVIDIA ION to AMD Fusion chipset (Linux-based). Install base is approximately 150,000 machines. They are looking into ARM boxes to reduce cost, but so far they really don’t seem to be up to speed for business services. Their primary ARM testbed so far has been the Raspberry Pi, but they’re interested in taking look at the Pivos box.

Technical issues with the current version were discussed from video playback to mysql database problems to multiple different fonts running on the screen at the same time. Occasionally there were between 3 and 5 conversations happening at once. It was exactly like watching 5 different IRC chats happening at the same time!

10:45 (Vienna Time)

JetStream: A company who sells media servers to very high class yachts has incorporated XBMC into their service. JetStream uses ViaSat to stream video content over satellite to boats. While it’s a pretty great service, the latency is fairly high (as is only natural for satellite)… so probably no gaming.

JetStream acts as a placeshifting service, essentially like Slingbox, except instead of placeshifting to your work, you placeshift to your yacht anywhere around the world. Everything works simply and in full time. To be legal, everything requires access controls. A yacht owner buys a satellite (or, typically, numerous satellites throughout the world) which is then placed in the appropriate region of the world. For example the owner actually buys a lot in the UK for SkyTV. Then JetStream takes in that content and sends it directly to the owner.

For those of you interested, while the presenter didn’t give us a ballpark price, he said he himself could not afford it. Essentially, this is a service ONLY for those who can also afford yachts that cost more than the respective homes of possibly every single XBMC dev combined.

10:00 (Vienna Time)

Seagate The Seagate presentation is still very much in early stages. For now, they’re mostly interested in potentially using XBMC as a headless uPnP solution or something similar. More conversation is definitely necessary.

9:00 (Vienna Time)

Sigma Designs: As you may be aware, Sigma has been working with a few developers to make XBMC available on their SMP8656 (available now) & SMP8672 (port in progress, being demoed at Computex 2012) chipsets. Because these chipset CPUs are so limited, Sigma had done extensive work to totally separate the video decoding process from the CPU, so now any video playback XBMC lose hardly any CPU cycles. To put it simply, XBMC’s UI running on top of video playback works pretty well. Adddons (particularly scripts like PseudoTV) tend to be fairly slow, but to some extent that’s because Python in XBMC is always fairly slow. Plugin Addons (i.e. addons that let you watch online video and listen to online music) work well.

Where these chipsets get really exciting is in two categories. First, they’re MUCH cheaper than x86 processors and easy to implement in just about any system. Second, because the player is totally separate from XBMC, the Sigma player can do fully licensed DVD and Bluray navigation.

8:45AM (Vienna Time)

Nathan (me) sent around a form for XBMC Foundation members to affirm the Foundation By-Laws. This is the last step in joining the Foundation.

Ned Scott is doing his best to record a video of all the proceedings. With luck, we might be able to upload that somewhere for everyone to see.

3:30AM (Vienna Time)

You may notice that we don’t have any live blog info from Friday. I’ll try to go back and fill in, but long story short, Ned Scott, Cory, and I were stuck in the Frankfurt Airport for 8 hours right in the middle of a labor dispute, and after getting on stand-by with a guarantee of definitely not getting to DevCon on time, we tried to get on a train (none were hitting Vienna until an hour from now today) and finally, we managed to rent a car and drive the whole way. So much fun!

Thursday

8:30AM (Central Standard Time, Kansas, U.S.)

To avoid excessively clogging the various XBMC social networks with news about this year’s devcon, I plan on exclusively liveblogging what’s going on using this post. There may not be many updates today or tomorrow, but I’ll do my best to cover as much of Saturday and Sunday as I can. So check back here on those days for more interesting material on this post.

Right now, we’re working out the details for how we’re all going to meet up tomorrow and various other last minute prep items.

Those of you interested in the meetup, I’m still trying to work out details. One user has suggested the Schweitzer Haus, and I’m trying to get one of our local people on the case of either confirming that location or resolving on something slightly closer to the conference center.

Team member keith has just arrived in Frankfurt, a hub many of us are passing through, and has informed us that Frankfurt has no free wifi.

10:30AM (Central Standard Time, Kansas, U.S.)

On the plane bound for Atlanta, where I will be meeting Cory (aka TheUni). Only like 15 more hours!

2:16PM (Eastern Standard Time, Atlanta, U.S.)

I’ve arrived in Atlanta. Unfortunately, there’s still no update on the Meetup. Flight leaves in approximately 4 hours. Here begins THE GREAT QUEST TO ENTERTAIN MYSELF!!!

Somewhere over the Atlantic.

Midway through the flight, the video system reset itself, and Cory and I discovered that the system was based on a 2002 version of WindowsCE. It’s really remarkable how much better XBMC is than a custom embedded Windows build from a decade ago. Anybody know any higher up from Airbus or Lufthansa? We’ve got a suggestion for them… ;)

20120831-001832.jpg


Working as the primary blog author for XBMC can be a very humbling experience, particularly for a non-developer like myself.  As the person who sums up for users the work done by much smarter people than myself, I get to go through a process that I call “Putting on my stupid hat.” I begin by reviewing at the various Pull Requests for the month on Github or in some other way finding a topic that I’d like to describe to the user base. Then I ping the author of the pertinent code on IRC and have a conversation with him about whatever it was that he wrote.

Sometimes the results of this conversation get included in the monthly write-up, sometimes they don’t.   Typically, I try to only include oft requested features or other new additions that I think the majority of regular folk will be excited about. Sometimes it’s hard to tell what will or will not be interesting though, and on those occasions I’ll need to delve deeper into the topic.

Typically, it is these moments where I need to delve deeper into a topic when the putting on of the stupid hat occurs.

For example, when we announced XBMC for Android, a critical sticking point had to do with something called Neon. For several weeks prior to the announcement, a spirited debate was going on in internal discussion about whether we should or should not focus on Neon, whether focusing on Neon would kneecap us in the future, etc. etc. I’d tell you more about these debates, but honestly, they all pretty much blew right over my head.

When you are a non-dev working with devs, you very quickly learn to just accept that they are going to say hundreds of sentences that mean absolutely nothing to you. Heck, you also learn that software development can get so specialized that the guy working on database stuff can have absolutely no clue what the guy working on video decoding stuff is talking about. It’s little wonder that the history of software development is one constantly marred by a lack of communication. Simply entering a specific section of C++ coding is like training yourself in an entirely new language.

Anyway, what I knew was that Neon was important. I didn’t know why or what it was, but I knew it was important. After the announcement, only a few people in real life seemed to worry very much about Neon, but it nagged at me that I didn’t understand what it was. So I pulled my stupid hat out and went searching for Scott Davilla,* one of the major players in the XBMC for Android space.

*I should take a second to talk about Davilla. If you’ve been paying any attention to XBMC over the past 4 years, you know that Davilla is a smart dude. He was the main guy behind our iOS port. He’s big on OSX. The fact that he ported XBMC to iOS (i.e. the first ARM platform) laid much of the groundwork for porting to other ARM devices, like the Raspberry Pi and now Android devices. 

Scott, and, honestly, pretty much the entire rest of the team, can be very patient with the uneducated. So long as you keep following the explanations and can ask questions, he’s often willing to explain in great detail something as intense as why cross-platform cross-building is magic.

So I asked him about Neon. He told me it was a vector processor. I did not understand. He asked if I’d ever heard of mmx or sse, which are x86 (aka Intel) instructions sets. I said yes, guardedly. He said that Neon is simply an ARM instruction set which allows an ARM processor to work faster and more efficiently without needing more ghz. On a very basic level, all Neon does is allow the CPU to do a calculation on four variables at once, rather than doing 1 variable at a time. So instead of requiring the CPU to do 32 operations, it can perform the same function in a mere 5 operations.

This can be incredibly powerful on low power systems. For example, when converting 1080p yuv to y,uv (honestly, I have no idea what that means, but I guess its pretty critical for image and video display and playback or something), a typical ARM processor without Neon can perform the function in about 16ms or more. An ARM processor that has access to the Neon instruction set can perform the same conversion in less than 1ms.

This means two things. First, ARM processors that don’t have access to Neon (like the Tegra2) are almost certainly going to be slower than those that do have access. Second, ARM processors that do have access to Neon (like Tegra3) will not have to ramp up the CPU nearly as much to perform the same task, so in addition to being faster, they will also be more efficient in the battery department*.

*Curiously enough, another topic came out of this conversation. It’s somewhat ironic that we announced XBMC for Android a mere month after announced AudioEngine for XBMC, because the Android port is all about making XBMC as light on the CPU and battery as humanly possible, while AudioEngine, to some degree, is about taking maximum advantage of the CPU to output glorious HD sound with nary a thought for battery life. Those two endeavors are like oil and water and – much like any other polar opposites – require a constant, delicate tug of war within the XBMC codebase between efficiency on the one hand and performance on the other.

I learned all that about Neon, and the crazy thing is, I ultimately decided not to include it in any write up at all, because, while undoubtedly there would be numerous people interested in the explanation, the vast majority would mostly just say, “So… you’re saying I should buy a Tegra3 Android device?”  Or even better, there’d be users who would blame us for not working hard enough to support outdated hardware.*

*That’s probably my favorite thing of all!

Anyway, I’ve learned a lot of things in my time with XBMC. I learned what Neon was. I’ve had extensive explaining of json and parameters and API calls and databases sent my way. I learned that a Playlist is not the same thing as a Queue (I may write about that at some point). But most importantly, I’ve learned that the project is more important that pride.

I can’t code,* and I don’t especially want to learn to code. The typical method of making XBMC better is closed to me. But I can write and evangelize and tell the rest of the people of the world, most of whom are also not coders, just why XBMC and the XBMC Team is so awesome. And if doing that means periodically admitting to being sorely uneducated, then I guess I’m willing to hang on to my stupid hat and bear that burden.

After all, even the most refined among us are allowed to look stupid every once in a while!