We are hoping for a seamless transition and we don’t foresee any difficulties, but don’t be alarmed by any unexpected results for the next day or so. We’ll update this space when the move is complete.

Update: Somehow, these things never go smoothly. The move is complete, but we did see some unreachable time. Most everyone should be back up by now, depending on your DNS servers. Our apologies for any inconvenience.

You may have noticed that for the past few weeks the Weather section of XBMC has become unable to provide updated information due to our default weather provider moving to a fully fee-based API. A brief scramble ensued, and the change provided the kick-in-the-pants we needed to move weather providers into our add-ons framework so that we can send out updates between releases, and allow users to choose between different sources much more easily.

We have now added the final piece of the puzzle: A default provider who has agreed to sponsor XBMC and its users with all the data we need. A special thanks to Weather Underground for working quickly with us to fill the void. It’s great to work with companies who see the value in donating their services to open-source communities like ours. We hope that they see some extra commercial interest as a result.

Thanks also to ronie for having the add-on ready before the ink was dry.

Users of recent nightly builds have already seen the change, and it will be fully baked in to the upcoming Beta1 release.

As always, the schedule will be dictated by our ability to get things polished up for release. So file those bug reports, clone our repo and send a pull request for fixes or translations… every little bit helps.

So much has changed since Dharma, we’ll use this space over the coming weeks to discuss in more detail what you can expect in 11.0. For now, Here are a few things you’re sure to notice:

• A new “Files” view in the video library in order to remove the notion of Library Mode vs. Files Mode that confused so many new users.
• The default skin changed to a horizontal layout allowing for more useful information to be displayed on the home screen (vertical version is still available in Add-ons)
• Efficiency improvements to reduce high cpu/gpu usage
• Much improved touchscreen support to go along with the first major versioned XBMC release for the iOS (iPad, iPhone, AppleTv2)
• Ability to customize the home screen by adding your favorite Add-ons
• The usual smattering of visual improvements, playback improvements, new ways to stream and discover media.. the list goes on.

The last few days have been hectic as the developers have been working hard to get their last changes in, but we’ll be slowing things down now to begin cleaning up for release!

The short of it is that a major chunk of dirty-region rendering has finally been merged into XBMC’s bleeding-edge code, though it is disabled by default while we continue polishing the rough edges. The change produces impressive performance gains on low-powered hardware, and is the groundwork for many changes to come that will further reduce CPU and GPU consumption for all XBMC users.

For those interested in a more detailed explanation, read on.

As you may remember, XBMC started as a project for the original XBOX where things were very different. After the move to desktops and embedded environments, many of the legacy procedures remained. One of these procedures, and a long-time thorn in XBMC’s side has long been its rendering model in which where every frame is rendered by the GPU in its entirety, typically at 60fps. As you can imagine, this is incredibly intensive and very unfriendly to low-power platforms. This is where dirty-region rendering comes in. Thanks to the work of Tobias and Jonathan (jmarshall), XBMC now has the ability to only render what has changed.

Marking the dirty regions

So how is this accomplished? Let’s use an example.

In this screen, the user has moved from the Browse button to Add. Previously, XBMC’s renderer would’ve happily uploaded the entire screen to the GPU for each frame (remember that almost every movement in XBMC comes with an animation, so there’s rarely a single-frame change). So in this example, assuming we’re running at 1080p, we have uploaded an entire 1920×1080 scene 30 times just to change the selection. In addition, each pixel is likely rendered more than once due to the layering of dialogs and blending of translucent textures – in the above case each pixel is rendered around 4 times. That’s roughly 1GB of data sent to the GPU for a half-second animation! But not only that, even after the animation is finished, data continues flowing at the same rate – even if nothing on screen is changing at all!

The obvious solution is to send only the data that have changed, and this is exactly how dirty-regions work. With each pass of the rendering loop, we now have the ability to mark controls as dirty. In the example above, the current and next buttons are marked dirty for the length of their animation. We then create a rectangle that contains all dirty controls and send it out for display. During this animation, the data transfer drops to just 16MB. When the animation is complete, nothing is dirty so nothing is uploaded at all.

Clearly the savings here are massive.

The impact

For those of you running XBMC on a desktop, other than knowing that your GPU is working much less, you also may notice a drop in CPU usage. For those on low-power x86 machines like IONs, it is quite possible that there will be some speed-ups along with the drop in CPU usage. The most impact, however, will be seen on low-power embedded devices; hardware like the beagle/panda boards is now much more interesting. Additionally, the atv2 and iPad ports should see a nice benefit from this, though there is currently a bug that prevents correct rendering when dirty-region rendering is enabled.

Because we now know which controls are dirty, in the future there are several changes that will come in that reduce CPU usage further. We hope that we can finally reduce XBMC’s idle CPU and GPU utilization to where they should be, especially when it is minimized or has lost focus.

Try it out

Obviously you will need a bleeding-edge build to see the new functionality, and the same caveats apply that always do when running unstable builds. Currently there are a few bugs that are blocking dirty-region being enabled by default, so for now you’ll need to explicitly enable it in advancedsettings.xml. See here for the settings.

If you are interested in seeing what is going on behind the scenes, you can enable the visualizer (used in the example above) that paints a rectangle over marked regions. Use the <visualizedirtyregions> setting from the wiki link to enable.

With each new version of XBMC, there are sure to be changes that require add-on authors to make changes in order to remain compatible. We have made improvements to python, JSON, the skinning engine, etc. So much like Firefox, we will be asking all add-on authors to test their creations against each version of XBMC and mark them as compatible in each before they’re available in that version. For more detailed information on API changes for Eden, check out the wiki.

Browsing the repository list with the new Xeebo skin

So what does this mean for you?

If you are a stable user happily using Dharma, it means nothing. Only that bleeding-edge add-ons are getting good testing before you’ll see them in the next stable version

If you are an unstable/nightly user, it means that from now on you will only see add-ons that have been accepted into the Eden repository. Much like Firefox, they will likely be few in the beginning and really begin to pile in when we enter the beta stage for Eden.

So remember: if you open your add-ons list and your favorite one is not listed, poke the author in the forum and ask him/her to make the necessary changes and submit to the Eden repository, or better yet, help with it!

And before anyone asks, the new Feature Friday has been a big hit. Nate is out of town this week, but he’ll be back next Friday with another installment.

In early May 2010, a representative at Sony Japan’s Home Theater and Console division expressed interest in using XBMC as a delivery platform for its newest content. After nearly a year of development, we have delivered a product that is suitable for deployment into millions of living-rooms, backed by Sony’s reputation for delivering high-quality standards-compliant hardware and software. We believe that within 3 months, we will have a new appliance on store shelves that will revolutionize the industry. The XBMC team is also excited to be a part of Sony’s Home Theater and Consoles division, where free-thinking developers are regarded highly.

What does this mean for XBMC? The sky is the limit. Combined with Sony’s impeccable reputation in tech crowds, we anticipate that the platform will be a quick success in the retail market. Sadly, the XBMC source will be closed in the future (all developers unanimously agreed to assigning a proprietary license), but we believe this is the right move going forward. As Jonathan Marshall, XBMC Foundation President put it, “While the free and open-source model worked well when we were all still in our parents’ basements, now that we’ve been showered with gifts from our new friends at Sony, we understand that it is not sustainable in the long-term; DRM is the way of the future.”

We realize that some may see this as abandoning our principles, so we have used our new partner’s influence to secure a special treat for XBMC’s existing users. For the next year, we are able to bring you the latest box-office top-10 movies in 1080p quality, some before the Blu-Rays even hit the store shelves. The best part is, they are free of charge! Just check out the ‘Blu-Ray Movie Streamer’ plugin, available now in the XBMC add-on browser.

We understand that not everyone will agree with our decision here, but we assure you, it’s for the best. Stay tuned for more as the details unfold!

Now that a few weeks have gone by we are comfortable sending out skin updates. For those of you who still have not updated to 10.1 (especially Windows users who don’t use the default skin!), please be sure to update now.

Enjoy the newly updated skins. In addition, be sure to check out some of the new ones that have gone in recently like Simplicity and Neon, plus two more from our very own Jezz_X that are slated for inclusion in the next few days.

The main focus of this release is to address a bug that could cause XBMC to freeze when updating a skin. We have held back skin updates from the main repository because of this, but now that it is fixed, they will begin rolling out in a few weeks.

This is intended as a bug-fix release only, no new features have been introduced. Notable fixes include:

• If an in-use skin was updated in Windows, XBMC would freeze
• Some RTMP streams in Windows did not play
• Included add-ons have been updated
• The correct referrer is now used for downloading add-ons, improving dependency statistics
• Crashes during playback on ATI hardware in some circumstances have been fixed
• Hardware decoding improvements for OSX
• Various small fixes

In addition, XBMC Live has been updated with the most recent packages, one of which includes a fix for the annoying SMB+Windows Live Essentials bug.

Those interested may check out the full changelog.

Updating

Windows and OSX users should download and install as usual, all user data will be kept intact.

Ubuntu and XBMC Live users can use ‘apt-get update && apt-get install xbmc’ to update.

Thanks to everyone who commented on the last post. Apparently there’s enough interest to justify some technical ramblings every now and then. As promised, here is a follow-up to address the popular questions and comments. Next up after SCALE will be a few words about add-on stats.

I wonder if there are any work in progress for Spotify support, that is the most important thing missing in my setup

This is not something that we are working on, but if someone develops an add-on that works well and doesn’t anger Spotify too much, we would certainly accept it.

Any thought of porting this to Android, it is linux based. With all of the new tablets coming out, that’s something I’d be interested in.

The simple answer is: most of us are lacking the hardware. As tablets and small-form-factor boxes flood the market, we will likely look into it.

I have to ask, did you evaluate using Mercurial instead of Git? Why Git?

Many of the developers were already using git-svn. It has become increasingly popular, and many of our upstream libraries use it as well. There wasn’t much of a “what vcs should we switch to” discussion, so much as a “how do we switch to git?”.

Do have any updates to share regarding the Sigma port?

This is still being discussed. More info as it unfolds.

Any plans to update to Python 3.2 version of the scripting engine?

As mentioned before, we are working to support an external Python, rather than building the antiquated 2.4 internally. We will still have to include a version for OSX/Windows. As far as I’m aware, no decision has been made regarding which version to ship. Though my guess is that it will be 2.x initially to ensure the most compatibility with existing add-ons.

I truly recommend that the whole XBMC developers team read this from start to finish: http://progit.org/book/

Thanks, I’ll certainly pass that along.

Any more definitive ETA on packaging 10.1, that bug (and the VDADecoder issue) has been causing me a few headaches and I’d rather stick to official builds.

I volunteered to handle the 10.1 build and I’m in LA for SCALE this weekend (Come see us!), but I hope to get it done quickly when I return.

I am also interested in the Audio Engine branch given it’s supposed to support bitstreaming HD audio.

Details on AE were sparse the last post, so I asked gnif to give a quick rundown of what it brings:

• Audio is now processed in the highest possible resolution instead of conversion to S16
• The sound device is now opened in float mode, or the next best thing that is supported.
• SDLMixer has been removed and replaced with our own mixing code finally giving us consistent GUI Sound support.
• Latency of the audio stream has been greatly improved meaning GUI sounds now play on time.
• AC3 transcode has been moved into the audio engine, meaning that GUI sounds and PAPlayer can be transcoded too.
• AC3 transcode of every sample rate is now supported instead of just 48 KHz.
• No more loss of stream sync on amplifiers when bit streaming and on pause/resume of playback.
• We can now take full advantage of PulseAudio, including its sound cache ability.
• Changing audio settings are now applied instantly and do not require a player restart any more.
• SSE conversion between formats has been added as well as extensive SSE optimizations to the software audio engine.

I was wondering if your were planning on adding more flexibility to the menu structure? Right now we only have “Movies” and “TV Series” and no option of adding other entries/categories (Anime comes to mind), except for using custom skins. What would be great is if users were able to add menu entries themselves, defining what folders and which scrapers should be used for each entry.

We are looking into several ways this might be handled without requiring XML hacking. These things bother us as well!

Git

First up is our move to git. We said goodbye to SVN a few months ago and have experienced the pros and cons of a distributed vcs. Git can be challenging even for seasoned developers, but it brings many benefits. Here’s what we’ve seen so far:

Pros

• Distributed. We can work as we travel. Everyone has a clone, so it’s much easier to say “try my code!”
• Branching/Merging. These are obvious to any git user.
• Github. The pull requests have proven to be excellent for discussing new features before merging them into mainline.
• Code quality. Due to the above, we have been working hard to keep the master branch compiling on all platforms for each revision. Though git is a great tool, not magic..
• git-svn. This provided many of us with a bridge to git.

Cons

• Git is hard. It has proven to be a big change for several of our developers, and has made us quite cranky at times. We’ve even decided that the committer who makes the biggest git-related oops will be presented with the first-annual “git-wtf” award at the next DevCon.
• The distributed nature means that it can be difficult to get a quick overview of what’s happening. We each maintain repos and branches, then merge them in upon feature completion. As a result, there may be zero activity in the main repository for a few days, followed by large feature-complete merges.
• Rebasing can be voodoo to inexperienced git users.
• Not related to git specifically, but switching our VCS has been a big hassle. We have had to fixup our buildsystem on all platforms, trac, mailing lists, irc bots, buildbot, etc.

Nightly Builds

Nightly builds were a big hit during the Dharma development phase, and proved to be very helpful for debugging. The move to git has slowed us down, but nightly builds started back up last night. Windows and OSX are up and running, our Ubuntu PPA will be up soon.

Restructuring

As with each major version, we’ve taken the opportunity to clean up old code, refactor for easier development, and abstract away as much as possible. The first big move was a “code reshuffle” by cptspiff, and it was a huge step towards cleaning things up. As a result, the classes and includes have undergone a major cleaning, and files have been moved to sane locations. One of the main goals was to separate our code from that of upstream libs, which had become tangled into a nasty mess over the years. This should help us move towards inclusion into Linux repositories, among other things.

OSX and Windows have undergone similar restructuring. The goal for these platforms has been to get away from keeping pre-built binaries in our repository, and to build them natively instead. This can be tricky, especially for unixy libraries in windows. Kudos to WiSo, CrystalP, and the others for getting ffmpeg built as part of the XBMC compile.

Jcarroll has recently been working to clean up some of our global variables. This is pretty transparent to users, though some Linux users may notice that the annoying “Critical Section” messages are no longer spamming their consoles. In addition, he is working to make external python default for all platforms so that we can finally stop building the ancient 2.4 with each compile!

New Stuff

Anssi has bumped FFmpeg to a more recent snapshot. For the most part, this means playback bugfixes and new format support, but in this case we were also able to trim a few dependencies: liba52, libdts, and libmms are no longer with us.

FneuFneu has submitted a pull request that provides FreeBSD support. This will surely undergo a few rounds of review, but should be merged in soon enough. This should make XBMC appeal to yet another audience.

Jmarshall has several projects going. With the iPad announcement, we have a new audience of touchscreen users. He’s working to make the experience better by providing skinners with a new set of touchscreen tools. The first bit was committed last night, it adds a touch-friendly slider during movie playback.

In addition, he has a “files-in-library” branch going that will lead us an overdue refresh of how the library works. Suffice it to say, the goal is to unify the File/Library views so that navigating is much more intuitive. From the work done so far, it is shaping up to be incredible. I hesitate to mention it here because it is likely to cause plenty of confusion, but we’ll discuss it more as there is more to see.

Gnif continues his development on his new AudioEngine, a complete rewrite of our audio system that solves many problems at once. This is mainly waiting on the OSX portion and testing.

Dushmaniac and several others continue their work on the PVR interface while the other piece of the puzzle, cptspiff’s binary add-on work, continues as well.

iDevice/aTV2

Davilla, Amet,  Gimli, and others continue to work tirelessly on these ports. A quick update (10.0-7) was released on Feb 19 featuring:

• Faster picture loads
• Improved rendering speed
• Remote thumbnail fixes
• More flexible h.264 playback
• Disabled portrait mode (while this is a cool feature, it was more annoying than anything)
• Enabled ZeroConf
• Updated Samba

A special thanks for Memphiz for working out several bugs lately.

This will be the last release for a while. They will now focus on integrating the port into mainline code.

Dharma 10.1

We have been working on a bugfix release for Dharma, due out very soon. The main reason for this release is a bug that keeps us from updating skins on the official repository. In Windows, if a new version for the current skin is released and automatic updates are on (default), XBMC will fail to load the update, leaving users in skin-limbo. Ouch. This has since been fixed. You can follow the merge request here. Only packaging is holding up this release.

Statistics

We’ve begun tallying add-on statistics so that we can display download counts, popularity, etc in XBMC. The numbers are VERY impressive. Next up is a post with some details.