It was great to meet a bunch of people and show them just what XBMC is all about.  In particular it was great meeting Erik de Castro Lopo of libsamplerate fame, which we use for resampling audio when video is synced to the refresh rate of the monitor.

We had 3 systems showing off what XBMC could do, one of which was the MSI Windtop AE2020 – an all in one unit with a 20″ touchscreen kindly on loan from MSI Europe (Look out for an upcoming post where you’ll see some of the new touch stuff being utilized within XBMC.)

Thanks heaps to the Linux.conf.au organizing committee and everyone who popped over to the booth – we’ll definitely see you all again in Brisbane at next year’s Linux.conf.au!

Left: Jonathan Marshall (almost smiling for once), Right: Patrick, JM's helper for the day

Singles and albums are different and it’s always irked me that music software tends to just lump the two together into a single listing, where you end up with hundreds of single-song “albums” in your listings. Of course, this is the same way XBMC has dealt with it. Until now.

Now, you have another option for your Singles, thanks to the suggestion by forum member thomash72. If you wish your singles to be separate from albums, then just remove the ALBUM tag from the track. XBMC treats any songs without an ALBUM tag as a single, and thus:

1.  Album covers aren’t cached for these blank ALBUMs – instead we cache the thumb per song, so each single from the same artist can have it’s own covers.

2.  The songs don’t show up in the Albums listing in the Music Library (after all, they’re not albums).

3.  If you browse to an artist, then it’ll list all the albums by that artist and, in addition, will group the singles by that artist into a Singles folder.

4.  Lastly, if you have any Singles in your music library, a new Singles item will be available in your Library listing.

Finally, a nice way to have your singles available in the library without them cluttering up the albums listing!

Given that these nodes are not widely used, it seems sensible to see whether or not we can do things differently to get the same (or better) functionality without having such a heirarchy in place.

My initial thoughts:

• Studio and Year browsing are likely not used at all.
• Actors and Directors are better served by searching and/or a “Related movies to this movie” feature.
• Genre browsing might be better served by some sort of “filter” system, where we just show you the movies or shows broken down by one or more genres.

One idea for a “filter” system is a Filter button which when clicked gives you a list of pre-configured filters, or allows you to design of a new filter, which is saved for later use.  Similar to smartplaylists, but simplified down a bit, and available in any listing.

If you have some thoughts, and in particular, if you make use of the current “category” nodes on a regular basis, then please head over to the forums and make yourself heard.

It has what appears to be an Atom 230 processor, so compilation of XBMC took just over an hour, but thanks to hardware accelerated video decoding, performance while running XBMC is awesome

[HTML1]

More pics are available in the forums, and if you want to see it in action, get to Linuxtag in Berlin, June 24-27.

Now it just utilizes a single image control with <fadetime> set, and just sets the new filename when necessary.  Obviously it supports background=”true” (on the <imagepath> tag) to allow the images to load in the background.

Combined with the recently added support for static content updates, you can now do most of the background changing on different states that skins normally do with a single multiimage control, rather than having a separate control (or multiple separate controls) for each state.  Examples would be the various Aeon incarnations, Mediastream, or even PM3.HD’s homescreen.

Steps involve:

1. Fill your container (wraplist or list) with static content.
2. Set the <icon> tag to point to the “normal” background image you want displayed for that item (image should be outside of Textures.xpr).
3. Set the <thumb> tag to a skin settable background images (or path of background images, or to something like Weather.Fanart etc.)
4. Create a single multiimage control for the backdrop, using <imagepath background=”true”>ListItem.Icon</imagepath>.

Due to the “fallback” functionality of ListItem.Icon, if there is a custom background image or folder set, it’ll use it, else it’ll use the normal backdrop for that item.

As the user moves through the items in the list, the multiimage control will update the path to the current image, and you’ll get seamless transistions between the different backdrops, with no stutter due to all the image loading being done in the background.

Nicer effects and smoother navigation with far less code – what could be better!

I’ve also added an attribute background=”true” to all texture related tags.  This forces the image to be loaded via the large texture manager except for textures in Textures.xpr.

Jezz_X also suggested a slight tweak to info images with <fadetime> set.  Now, if the first texture to load in a window is already in memory (due to being used in a previous window) it will load instantly, and thus forgo the usual fade in.

All these changes mean:

• You can use the background texture loader for images within containers – this means your wall thumbs can be loaded in the background, giving silky smooth scrolling, at the expense of a slight delay in loading the image (you can mask this by using a loading image for instance).
• You can use the background texture loader for background images that persist across window transitions – there’s no fade in due to the new window being opened.

With judicious use of background=”true” you can have texture-rich skins whilst still having nice, smooth scrolling.

After discussions with Jezz_X, we thought it’d be nice to extend this feature to the other slider based settings in the Audio and Video OSDs.  The Audio and Video OSDs currently tend to take up a lot of space on screen, which makes some adjustments difficult.  If the audio and video sync is out, it’s hard enough trying to fix it without having a bunch of stuff covering up the video!

Now, when you click on “Zoom amount” from the video settings, the dialogs fade away and the slider bar pops up, allowing you to adjust the setting while in full view of the video file.  Now fine tuning of video settings is much easier.

It’s a nice touch that I’m hoping all skins take on board.  For the skinners, just add a DialogSlider.xml file based on the PM3.HD one, and modify the OSDs to animate out of the way when it pops up.

We’ve also added two new actions “AudioDelay” and “SubtitleDelay” which popup the slider allowing you to change these settings directly – a bit more remote friendly than having two buttons (one for plus and one for minus) for each feature.

1.  Don’t use the old Q:, P:, T:, U:, Z: paths. Replace these with their special:// counterparts below.

2.  Use xbmc.translatePath() to translate any path to it’s true path if/when you need to read or write from the filesystem.

Note that xbmc.translatePath() will take care of number 1 for you in the meantime, but this functionality is not guaranteed to be available forever.

So what should you use?

1.  Use special://home/ if you need to read or write to the writeable version of the xbmc install folder.

2.  Use special://profile/ if you need to read or write to the current users userdata folder.

3.  Use special://temp/ if you need to read or write to a temporary location.

If you absolutely have to, you can also:

4.  Use special://xbmc/ to read from the xbmc install folder itself.

5.  Use special://masterprofile/ to read from the master users’ userdata folder.

These should not be needed by the majority of scripts, however, so if you find yourself needing to do either of 4 or 5, please contact me so that I know why, and can see whether there’s a better way to do things.

As a remnant from the xbox days, XBMC used 5 internal DOS based drives as base paths in order to find files and store settings and so on.  These were Q: (the location of the xbmc executeable), Z: (a temporary cache), P: (the current profiles userdata folder), U: (a writeable version of Q:), and T: (the master users userdata folder).  References to these littered the code, and caused many a headache with the initial port to Linux, where essentially it was decided to wrap the win32 filesystem layer that we had in place, and, in addition, provide a path translation routine (CUtil::TranslatePath, macro’d to _P()) to translate from the virtual path to the real path.

On win32 we didn’t have to bother with this, but we did have to (internally) map those drives to the appropriate directories.  This, ofcourse, caused problems for anyone who wanted to use those drive letters for removable storage or network drives.

The main problem with all this is that the magic _P() macro was treated as a “cure-all” for any path related problems.  If you had a problem with paths, just throw a splattering of _P() calls all over the show, and eventually one of them would catch it and “fix” the problem.  Not a particularly good fix, but it did the trick in most cases, so that xbmc could find textures, fonts and skin files and the like.  The problem, ofcourse, is that the majority of the _P() splatterings should not have been there, and this has caused nightmares in more recent times.

A quick example:  We have a tokenize routine which is mainly used for tokenizing paths.  Someone had decided to throw a _P() in that so that we were ensured that we were looking for the correct directory separator.  This is all well and good, until you realize that the routine is also used for tokenizing other strings.  For instance, it’s used to split multi-line text up into single lines, so that the fribidi stuff can do it’s magic to convert logical Hebrew and Arabic text to it’s visual counterpart.  Low and behold, this was causing the direction of the slash to change!  Me, being not of Hebrew or Arabic persuasion, was rather perplexed by all this.  Was it the intended behaviour?  After all, the routine was supposed to flip the text!  Needless to say, it took a wee while to track it down to the errant _P() in the tokenize routine!

Of late, many more examples have been found.  The solution was obvious: Go through the code and account for every single path translation and ensure that it absolutely _has_ to be there.  Basically: No path translation should occur _ever_ unless we need to hit the filesystem directly.  There were more than 500 instances of _P() to be removed.  Fun and games!

At the same time, we changed things from using DOS based paths to other paths, so that win32 users could claim back their drive letters, and reused one of the protocols we already had.  We now have:

special://xbmc (where the executable resides)
special://home (a writable version of special://xbmc)
special://masterprofile (the “master” userdata folder, usually special://home/userdata)
special://profile (the current profiles’ userdata folder, usually special://masterprofile/profiles/<profilename>)
special://temp (a temporary cache folder, such as /tmp/xbmc on *nix)

So that’s it pretty much.  Lots of changes required to fix up what was on the face of it not a particularly bad implementation to get stuff running on Linux, that over time grew into a monster.

As you can see, we’ve been busy tackling these reports – 228 closed tickets out of 326 at the time of writing, so we’re 70% of the way there, and that includes only bugs that have actually had tickets assigned (i.e. not stuff we’ve discovered ourselves or was reported on the forums that there was an easy fix for that didn’t really warrant ticket creation).  sho has been doing an awesome job at managing the trac reports – busy assigning them to us devs and following up on them to make sure that they get fixed.

We hope to have the first beta release out within a week, and will be shortly inviting some of our more active users on the forum and trac to come aboard the team as official beta testers.  There’ll be some nice surprises included with the beta as well that we hope you guys will smile about, including a treat or two for you Mac users.

Let’s keep up the testing and bug bashing to make Atlantis as stable as possible.  Your help in looking over the trac reports and reproducing and supplying more information about the reports makes our job much, much easier, so keep it up!