[CaptainRewind]

Updated Gotham build, XBMC master from Mar 12 + newclock3 commits + additional commits.

Some info:
• NC3: [dvdplayer] Use inexact seeking like omxplayer
• NC3: [omxcodec] More care with dropping frames quickly
• NC3: Make use of TrueHD fastpath when downmixing (saves about 50% of the CPU required)
• NC3: New test for Airplay and IOS 7 clients
• Additional/SQLite: Updated SQLite version
• Additional/SQLite: Use mmap to accelerate SQLite file accesses
• Additional: Fix memory leakage in python bindings
• Additional: DVD various fixes related to libdvdnav issues and skip to menu

Firmware from March 12 included.
Recommendations, requirements and additional info (DVDPlayer etc.), see post #1

NB!
Firmware is now included in the build and installation process so no need to manually update firmware!
Also, you do not need to use Raspbmc settings to switch build, it will automatically switch build and reboot.

To install XBMC build, SSH to Pi:

Code:

wget -O xbmc-13-20140313-nc3.tar.gz http://goo.gl/uq3tuu --no-check-certificate
pv xbmc-13-20140313-nc3.tar.gz | tar xzf - -C /home/pi/.upgrade
sudo cp /home/pi/.upgrade/xbmc-13-20140313-nc3/{fixup_x.dat,start_x.elf} /boot
ln -sfn /home/pi/.upgrade/xbmc-13-20140313-nc3/xbmc-bcm /home/pi/.xbmc-current
cd /home/pi/.upgrade/xbmc-13-20140313-nc3/xbmc-bcm/xbmc-bin/lib/xbmc/system
cp /usr/local/lib/libdvdcss.so.2.1.0 .
ln -sf libdvdcss.so.2.1.0 libdvdcss.so.2
ln -sf libdvdcss.so.2 libdvdcss.so
sudo reboot

This was perhaps the least painful upgrade ever! The only thing I added to the above was, just before doing "sudo reboot":

Code:

rm ~/.xbmc/userdata/guisettings.xml

Also, I much prefer this method of upgrading. I like that I can see all the changes happening, rather than running some UI script making unknown changes. Upgrading the firmware is as simple as copying two files. I did not know firmware upgrade was that easy on the Pi... usually firmware upgrades involve pushing code to the motherboard and praying the power doesn't go out or a solar flare doesn't erupt. This was dead simple.

I did have to connect a keyboard just to re-enable the remote web interface (my only XBMC remote is an old Android phone). After that, it was pretty easy to set the settings I like:
720 max GUI resolution (menu is a bit more responsive)
RSS disabled (only for performance reasons)
"Programs" menu hidden (to avoid small hands from changing RaspBMC settings or launching the Arora Browser (BTW why can't we just remove Arora completely? I have absolutely NO use for it))

The YouTube add-on works! I made NO changes to configuration, and don't notice any of the sound problems reported above. This is a HUGE improvement over 20131219 which I was running previously. YouTube was completely broken on that build.

And, of course, the most important part for me: streaming SD and HD content, over a 802.11g WiFi bridge running DD-WRT, using NFS + UDP + 8192 rsize, is working consistently! This was a MAJOR pain point for me... I had issues with content pausing, locking, or just plain not downloading fast enough from the NFS server. I have a separate post that goes into far more detail on this, but suffice to say it's WAY WAY WAY better now.

Of course, as many of us already know, the RaspberryPi will not play DivX 3 content. It plays audio only, no video. This is a known issue with the Pi and DivX 3, and is due to licensing (or, lack thereof). Now that I have a working setup, I'm going to convert these all. I have loads of them.

I do still have a few 1080p h264 titles with some really high-def scenes that don't play well. There is one scene in particular, about 8 minutes into a Sci-Fi movie from 2 years ago, that has lots of dots moving around on the screen for about 1 minute. This scene does not play, but it's not specific to this build or the RaspberryPi... this scene uses lots of resources and is choppy even playing via gigabit ethernet on BoxeeBox.

All in all, I'm very pleased with this build. I'll continue testing it in the coming days and report any issues I find.

Thanks to everyone who helped code, build, test, and instruct!

UPDATE:
I did notice one bug. This build doesn't seem to respect the cachemembuffersize I have set in advancedsettings.xml. I have a RaspberryPi Model B with 512MB RAM. I did NOT adjust my config.txt to gpu_mem=256. Everything looks to be working as expected with gpu_mem=128. So, If I want to cache to memory, with 372 MB available, then a setting of 100MB should use 3 times that, or 300 MB (Can somebody please explain WHY using memory for cache buffer is supposed to use triple the RAM?? My testing on 20131219 does NOT support this.)

With the following advancesettings.xml, I see the cache fill up to only ~60MB, not ~100 as I was seeing on 20131219. When I do "free -m" I show plenty of available memory, so I would love to use it for cache buffer.

Code:

<advancedsettings>
<!--  <loglevel>1</loglevel> -->
  <network>
    <buffermode>1</buffermode>
<!-- Set cachemembuffersize to 0 to use disk -->
<!-- Only applies if buffermode is 1 and XBMC version is 13+ -->
<!--    <cachemembuffersize>0</cachemembuffersize> -->
<!--    <cachemembuffersize>89128960</cachemembuffersize> -->
        <cachemembuffersize>104857600</cachemembuffersize>
    <readbufferfactor>1.0</readbufferfactor>
  </network>
</advancedsettings>

Has anyone else seen this? It's not causing a major issue except when there's a high-action scene that lasts longer than the cache buffer. I want memory caching instead of disk caching: I see a noticeable performance hit using disk caching. Not only that, I'd prefer to not kill my SD card with too much activity.

Thanks again.