Plex

The big change in this release (or perhaps the one which will make the most people happy) is the fix for the “pink screen” issue affecting GMA X3100 video hardware. It turns out that there is a serious bug (apparently one of many!) in the OS X driver which completely breaks support for the negation of constants in shaders. I had to modify the output of the NVidia compiler to make sure that constants were never negated (the constants are the things like “c[0].x”). I can’t even tell you how serious a bug this is. Just imagine if this were the case in a C++ compiler… Many thanks to d4rk for showing me how to get the shader compiling in the first place.

Here the the other changes in this release:

• NEW: Support for using the scroll wheel with the mouse.
• FIX: International character sets (and funky characters in English) now work. Go Spanish! Non Western European characters probably work too with that Unicode font. N.B. There is still a problem when displaying *filesystem* entries; I’m working on it.
• FIX: Don’t dim the screen when the screensaver kicks in unless we’re in full-screen mode. It’s scary and makes people think their LCD is dying.
• NEW: Make ‘Done’ the default key selected in the virtual keyboard. It really makes keyboard entry much more natural. Thanks to ScottTFrazer for the suggestion!
• NEW: All standard output logging has been moved to the /var/tmp/xbmc.log file. This means that (a) I will never ask you to run from the terminal again and (b) I’ll be asking you for that file a lot more.
• FIX: The audio output is no longer stuck in digital mode.
• NEW: Support for mounting SMB filesystems using the OS’ support for it. This was introduced by vulkanr in this change. It seems to work well, but if the SMB share is inaccessible, XBMC hangs on start for quite a while waiting for the mount to timeout. Let me know which options provides better performance.
• FIX: Store mediasources.xml in the Application Support/XBMC directory, instead inside the application bundle. You’ll have to move yours there if you want to maintain settings.
• FIX: There was a naming conflict between the SMB client code and some other library I can’t remember, which was causing the application to crash quite a bit when using SMB.
• FIX: The infamous hang-or-crash-on-exit bug has been nailed. I double-dare any of you to hang XBMC on exit!
• NOTE: Make sure your vertical sync is enabled (set to Always Enabled). People were complaining of video issues and tearing. It’s in Settings -> Appearance -> Screen.
• NOTE: I’ve been able to play FLAC files without a problem. I’m not sure why people (or only a couple of people?) are unable to play them.

The surprise feature in this release is basic support for the Apple Remote. It’s very basic and will be enhanced much more, but here is what’s supported for now:

• Left, Right, Up, Down: As expected, and no support for volume (isn’t everyone using their receiver remote for this anyway?)
• Play/pause: As expected.
• Menu: Up one level.
• Double-click Play brings up context menu.
• When in full-screen video, the menu button brings up the menu, and holding down the menu button stops and returns you to the browser.

Really simple, but hopefully useful, and also hopefully it doesn’t break people who are using Remote Buddy.

As usual, enjoy the release, brought to you by Barkley and my sweet wife, who have both been really supportive of all my late nights.

I need to clean up some code and then I’ll make a release later on tonight (and check in my changes, sorry it’s been so long). It turned out to be a blatant bug in the fragment shader runtime or assembler, which I have worked around. More details later.

Very strange…there appears to be something fundamentally wrong or different with the X3100, as best I can tell from my extremely limited experience with such things. Which probably means I’m completely wrong.

D4rk helped me get set up compiling my own fragment programs (thank you!). The approach I took is what I always do, which is get the working code on one end, the non-working code on the other, and then move towards the middle until you find out what breaks.

I took out all the matrix multiplication, and just started with some basic transformations to see what worked. While rgb.r = 1.164 * yuv.r; produced the expected pixel color rgb.r = 1.164 * (yuv.r - 16.0/256.0) + 1.596 * (yuv.b - 128.0/256.0); doesn’t (at least according to my Numbers spreadsheet). So tomorrow I’ll do some more back and forth to see if I can figure out why the second formula isn’t working. (Note that it DOES work on an NVidia card). Doing debugging where the only way to output debugging information is through 0-1 values in pixel color components has given me new respect for people who work in that field.

I now have the hardware in-house, and have confirmed that the problem appears to be with the ARB YUV-to-RGB conversion. If I enable software conversion (which takes a rather large hit on the CPU), things look fine. I’ll look some more later on tonight.

The bottom line was that the canonical type on OS X is UTF-32LE, not UTF-16LE as on Windows, or WCHAR_T as on Linux (which is a pseudo-encoding anyhow, which means “the system dependent and locale dependent wide character encoding”). On OS X using WCHAR_T defaulted to UTF-8, which - while it is a great encoding - didn’t jive with the rest of XBMC.

I can’t believe that took around 6 hours to figure out…

As many of you know, there aren’t a lot of people coding on this project. I try very hard to respond to comments and help people out with the problems they’re having, but any time I spend doing that takes away from time I would otherwise be working on the next release.

Please try to use the following guidelines when reporting problems. This will maximize your chances that I will be able to diagnose and fix the problem:

• If you’re asking about a problem that may not be OS X specific (e.g. SMB mounts and thumbnails), please check the forum first. That means you should do a few searches, and then post if you can’t find your answer. If it’s determined to be an OS X specific problem, and it’s not known (e.g. Python doesn’t work), then please go ahead and post it.
• If you’re asking an end user question (e.g. “How do I do XXX?”), please post it on the forum.
• If it’s a visual issue, take a screenshot and post it to ImageShack.
• If XBMC crashes, get a Problem Report, post it to Pastie and post a link, along with a full description of what you did to make it crash.
• If you’re getting high speed video and no audio, and you’ve read the FAQ, paste the output when running from a Terminal ($ ./XBMC.app/Contents/MacOS/XBMC). I’m going to be moving this output into the regular XBMC log in the next release.

Thanks very much for reading.

Last night I was forced to watch Rumor Has It. I say forced, but actually I was staring at the screen transfixed the entire time, not because of the acting (horrible), the plot (puerile) or the surprise peek at half of Jennifer Aniston’s right breast (entirely forgettable), but because of the quality of the output of the 1080p movie by our trusty little mini.

By the numbers: This was an x.264 encode in an MKV container. The average bitrate was 11.5MBps, with spikes between 15 and 20. Total number of frames dropped in the entire movie (counting those 20 odd that always seem to go missing at the beginning): 230. The means the drop rate was 0.16%. Those dropped frames were all clustered around “difficult” scenes in the movie, and resulted in a bit of jerky movement, but no audio loss.

Note that at this point we are peaking at about 130-140% of the (dual core) CPU in use. This means that there is another 70% of a core doing absolutely nothing. With further improvements by the ffmpeg team, we can only do better. This was also a full-quality decode. Tweaking some of the ffmpeg settings. as suggested by inloop would probably improve things as well, at the expense of picture quality.

This new release still only works on Leopard and Intel. No plans at all, present or future, to move to PPC or Tiger. (Note that I’m linking to another page with another big Leopard/Intel warning, and the new release is at the bottom of the page).

NOTE: You will almost definitely want to move Sources.xml aside and then whack the “Application Support/XBMC” folder, as lots of related things have changed, and it’s best to get a fresh start. If you report a problem, and I find that you didn’t start over from scratch before reporting it, I will be very upset with you.

• NEW: Fixed up the virtual keyboard. No more assertions, and you can type with a real keyboard (even backspace works). Since Enter is used to “hit” a virtual key, you will need to navigate to the Done key.
• NEW: Fullscreen support has been enhanced to support other-than-primary screens without setting environment variables (now that everyone’s figured out how to do that). I also renamed “desktop” mode “full screen” mode to clarify a bit. Some people will probably hate this. Others will love it. Can’t win ‘em all. Basically if you have multiple screens, and you scroll through the resolution settings, you’ll see multiple “full screen” settings, one for each screen. The thing about that resolution list that confuses me is that some are windowed modes (720p, 1080i), and some are intended to be full-screen video modes (where XBMC would actually set the mode for you). Right now, all you have to know is that the full screen modes labeled as such DON’T change the video mode, so you’ll do that in OS X, get it how you like it, and XBMC will use it.
• FIX: Updated the scrapers to the correct versions, you should now have much better luck scraping. I took all but the latest and best maintained TV scraper out of the release. Also, I made a network fix to avoid timeouts that probably would have otherwise occurred. I also tried to track down a library problem someone reported with multiple sources of which XBMC would allegedly forget all but one upon restart, but no luck reproducing the problem.
• FIX: The release now comes with a much better Keymap.xml file, which includes a mapping for the context menu (the C key). This sort of thing is why you want to whack the application support files.
• FIX: There was a serious race condition in some of the audio code (PortAudio specific) that could lead to a crash when playing videos.
• FIX: The RSS feed file was added back in, and reset to default to something a bit more interesting for Apple users.
• NEW: Some progress playing IFO/VOBs. I built some needed modules (e.g. MPEG2 decoder, dvdnav, etc.) and although I don’t own a single DVD I was able to get some VOB files to play. Sort of. If you’re still watching DVDs, isn’t it time you moved into the 21st century?
• FIX: A serious problem that prevented lots of audio streams from playing at all (and thus resulting in fast video), notably ones with strange sample rates (with strange being anything other than 48KHz/44KHz, I think).
• FIX: I applied the XBMC subtitles fix to the ffmpeg library, which means that one person who was complaining about ugly subtitles might be happier now. And buy me some beer.
• NEW: D4rk made some enhancements to the way we interact with SDL, to the effect that we no longer need a custom SDL build. He also got full-screen toggling working (the ‘\’ key). Very tasty.
• NEW: Shoutcast audio sources seems to work. YMMV. I was grooving to some rap earlier today that made me wish I hadn’t gotten it working.
• NEW: The SMB client is now included, although I haven’t done much with it. Lots of people wanted this one.

This release brought to you by our very own Barkley.

I’m actively working on support for the Apple Remote (and after that other remote control options), but we had quite a spectacularly good development over the weekend that I wanted to share earlier rather than later. It turns out that a fellow named Andreas Öman (bless his heart) made available an experimental patch to ffmpeg back in September 2007 that provides impressive speedups for multi-core decoding of H.264 content. We’ve applied it to the ffmpeg sources we’re using and the results are nothing short of stellar. The infamous 1080p Planet Earth encode plays back much better on a mini, without audio dropouts and with far fewer frames dropped. It’s not perfect, but it’s *much* better.

Additionally (and perhaps more importantly), all other 1080p content I tried played back virtually flawlessly on my Mac Mini 2.0 GHz. This includes Kill Bill Vol. I (tried the last third), a Lost episode at 1080p, and cullman even tried a crazy 5GB .ts/H.264 format Lost episode.

Whereas without the patch the CPU load is concentrated in a single core (with non-slice encoded H.264 content, at least), with the patch the load seems to be distributed much more evenly between cores. The author claims a speedup of 20-30%, which doesn’t sound like much, but it appears to push the envelope far enough to provide a much better experience.

So without further ado, give this new version a try and let us know how it works for you.

N.B. The author does mention a lack of support for the MBAFF subtype of H.264 encodings - which apparently isn’t used all that much - so it’s possible (but fairly unlikely) that content that played without the patch is now broken.

To all those (like mingistech) who are noticing differences in the output modes to their TVs, please download this binary and replace the one in XBMC.app/Contents/MacOS. Then run from the command line:

$ ./XBMC.app/Contents/MacOS/XBMC

Please paste the entire output in the Terminal into this site and then post a link in the comments. The binary has lots of diagnostic output and also adds an extra check into the mode selection, making sure it’s compatible with TVs (in theory, at least). You might not notice any difference, and actually this new code may cause your TV to catch on fire. Have water handy.

Also, cullman was kind enough to write up an excellent FAQ. Please read it before you ask any questions. If we catch you asking a question that’s already been answered, no matter how obtusely, we will make endless fun of you, and the next time I’m spear-fishing I’ll name the fish after you before I stick it with my spear.