Media center setup - XBMC-XVBA

I finally got my nettop - AMD E-350 based barebones system. Installed 4G of RAM and the plan was to set it up with XBMCBuntu or XBMC-XvBA. Instead of installing the XBMC-XvBA version directly, I figured that I could start with XBMCBuntu, see how it does and then if necessary move to the XvBA enabled builds.

I don't have a hard drive for the nettop - the plan was to have the system run off a 8Gig pen drive.

Basic Installation - XBMCBuntu

What you need

1. The nettop with RAM installed.
2. 2 USB pendrives - One for installation (2GB) and another which is going to act as your HDD (8G)

Steps

1. Download UNetBootin for windows and the XBMCBuntu iso image
2. Create a Live USB using UNetBootin: Once you have UNetBootin installed, stick in a flash drive in the usb, start UNetBootin and selec the XBMCBuntu iso image as the source distribution iso and the flash drive as the destination.
3. Boot the nettop using the USB drive: You might have to play around with boot devices and priorities in the BIOS settings to get it to boot from the USB drive. To keep things simple, stick the pendrive into one of the USB2 ports (avoid the USB3)
4. ON the UNetBootin boot menu, you can just try out XBMCBuntu live image. I did so and things seemed to work well enough for me to do the full install to another USB drive plugged into the system. Note that if you're not able to find the target drive, then just reboot with both the USB drives plugged in - sometimes, newly inserted devices aren't detected.
5. Install, go through the menus and wait for it to complete.
6. As you go through the menus, keep in mind to choose a custom partitioning scheme. In my case, I had 4G of RAM and there's no sense in having a swap drive on the pen drive. If you plan on having hibernation support, then use a 2G swap partition (50% of RAM) - else you can skip the swap altogether.
7. Once done, pull out the installation pen drive and reboot. You should be able to reboot off the USB pendrive that you installed into. The installation pendrive is pretty much done - you won't need it any longer.

XBMCBuntu

At this point, I had XBMCBuntu up and running however, there were a few problems:

1. On idle, CPU utilization was very high (~ 60 - 70%) and the unit was running hot.
2. Display resolution proved troublesome - my LCD's native resolution is 1366x768 but that wasn't available over HDMI.
3. I was able to get 1360x768 on DVI/D-Sub - but that meant using a separate cable for audio out.

Of these, the high CPU utilization was the biggest worry - so there's a few steps available to try

1. Within XBMC - set sync to display refresh - always.
2. Turn off RSS feeds
3. Tweaks .xbmc/userdata/advancedsettings.xml:

<advancedsettings>
    <useddsfanart>true</useddsfanart>
    <cputempcommand>cputemp</cputempcommand>
    <samba>
        <clienttimeout>30</clienttimeout>
    </samba>
    <network>
        <disableipv6>true</disableipv6>
    </network>
    <loglevel hide="false">1</loglevel>
    <gui>
        <algorithmdirtyregions>1</algorithmdirtyregions>
        <visualizedirtyregions>false</visualizedirtyregions>
        <nofliptimeout>0</nofliptimeout>
    </gui>
    <measurerefreshrate>true</measurerefreshrate>
    <videoextensions>
        <add>.dat|.DAT</add>
    </videoextensions>
    <tvshowmatching append="yes">
        <!-- matches title 01/04 episode title and similar.-->
        <regexp>[s]?([0-9]+)[/._ ][e]?([0-9]+)</regexp>
    </tvshowmatching>
    <gputempcommand>/usr/bin/aticonfig --od-gettemperature | grep Temperature | cut -f 2 -d "-" | cut -f 1 -d "." | sed -e "s, ,," | sed 's/$/ C/'</gputempcommand>
</advancedsettings>

Did those and while they dropped the CPU utilization to about 25% which was quite good. However, during videos, the CPU was still high - and that's because even though XBMCBuntu official uses hardware acceleration through VAAPI, it still is spotty.

Getting XvBA

I went over to the XBMC-XvBA installation thread and followed the directions in the first post to add the XBMC-XvBA ppas. The download took some time and XvBA build got installed. Started XBMC and things were much, much better.

sudo apt-add-repository ppa:wsnipex/xbmc-xvba
sudo apt-get update
sudo apt-get install xbmc xbmc-bin    

There are other tweaks that are listed on the XBMC-XvBA installation thread which I also went ahead and applied.

Other tweaks

Optimizing Linux for a flash/pen drive installation

Installing on a pen drive /usb flash drive has its pain points. My boot time was around painfully slow (~3.5 minutes). Opening Chromium took forever and even page loads were slow (it would be stuck with the status bar on 'checking cache'...). Also, the incessant writing to disk is probably killing off my pen drive much much faster. I ended up doing the following:

1. Use the noatime and nodiratime flags for the USB drive

   # /etc/fstab
   UUID=39f52ccf-363b-4b6e-abdd-927809618d83 /               ext4    noatime,nodiratime,errors=remount-ro 0       1

2. Use tmpfs - In memory, reduces writes to disk and is faster. With 4G of RAM, this is a no-brainer.

   # /etc/fstab
   tmpfs /tmp tmpfs defaults,noatime,nodiratime,mode=1777 0 0

3. Browsers - use profile-sync-daemon for Ubuntu from Arch Linux - will automatically move your browser profile directory from your home folder to /tmpfs
4. Move .xbmc to NAS/External drive along with your media. Makes a lot more sense to keep your .xbmc folder with your media on a external hdd.

5. Change to noop or deadline scheduler:

   # Assuming sda is your USB drive
   sudo echo noop > /sys/block/sda/queue/scheduler

6. Change system swappiness. We don't want the OS to use swap drive at all.

   # /etc/sysctl.conf
   vm.swappiness=1

Getting suspend/hibernate to work

I had greatest trouble here - but was able to get pm-utils working eventually. pm-utils is a framework of shell scripts around suspend/hibernation/wakeup that provides hooks to execute scripts before standby/hibernation and when the computer resumes from sleep/shutdown. First test if basic suspend/hibernate works

# check suspend methods supported
cat /sys/power/state
# S3
sudo sh -c "echo mem > /sys/power/state"

If your system goes into standby, then things are good. But its just a good start. In my case, system would go into standby only the first time after boot. After that, it would go into standby but then resume immediately. Its been asked enough times on Google and I've probably tried all the fixes. The first one is to update a kernel param acpi_enforce_resources=lax

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_enforce_resources=lax"

After that, make sure to run  sudo update-grub In my case, the magic incantation above failed (your mileage might vary). Nothing bad happened so I kept it on. Anyway, so I rebooted, then suspended and resumed the first time (which works) and took a dump of dmesg > dmesg.1.log. After that again tried to suspend and when it came back immediately, I could get a dmesg output and scan the entries after the first run. Turned out that the log had entries related to xhci_hcd - so decided to unload it first and then try to suspend:

sudo modprobe -r xhci_hcd
sudo sh -c "echo mem > /sys/power/state"

After this, the system was able to standby each and every time. Now it was time to get pm-utils working. Out of the box, pm-utils came with a config that had a bunch of things that I didn't understand (and I doubt they applied to this machine). If standby was working directly, then it should have worked through pm-utils. However, it needed some amount of pushing around before that comes around to a functional state.

Getting pm-utils to play nice

So now that I had confirmed suspend working, it was time to see why pm-utils was being so bad. First off, time to clean up the default configuration. So copied /usr/lib/pm-utils/config to /etc/pm/config.d/config and then start editing it

SLEEP_MODULE="kernel"
# These variables will be handled specially when we load files in
# /etc/pm/config.d.
# Multiple declarations of these environment variables will result in
# their contents being concatenated instead of being overwritten.
# If you need to unload any modules to suspend/resume, add them here.
SUSPEND_MODULES="xhci_hcd"
# If you want to keep hooks from running, add their names  here.
HOOK_BLACKLIST="99_fglrx 99lirc-resume novatel_3g_suspend"

Waking up with the keyboard

if you'd like wake up with a usb device (usb keybd), then you need to find out the usb port where your device is connected. The easiest way might be to check dmesg output which would usually print this out. In my case, my wireless keyboard/trackball are connected on USB3

echo USB3 >  /sys/proc/acpi
echo  enabled > /sys/proc/devices/usb3/power/wakeup

After that, the HTPC could be woken up with a keypress. Now I haven't been able to find a way to do the same thing with only the keyboard (so that the system doesn't wake up anytime anyone picks up the keyboard - so for now, have turned this off). The above change won't persist over a reboot - so to make it persistent, put the two lines above to /etc/rc.local before the exit 0

Fixing up fglrx annoyances (ATI binary driver)

Not much point of a HTPC if the video isn't top quality. And there are a lot of variables involved there - your computer hardware, software, drivers, type of connection (HDMI/DVI) and the telly itself. Also, video driver support on Linux for ATI leaves quite a bit to be desired. One of the reasons of going with XBMCBuntu was knowing that there'll be large community support available on ubuntuforums.

Right off the bat, things started at the mildly irritating level. Catalyst control center in root mode won't start even though there's a big fat menu item there. Quick google and it says that the easiest way out is to use gksu amdcccle in the run dialog (ALT-F2).

So where does all this get us

After all this, it makes a sea change in the overall experience:

1. XBMC idles at 15 - 20% cpu utilization. During video playback, stil stays at a comfy 40% - 50% while playing 720p/1080p videos
2. Browsers (Chrome and FF) open near instantly; browsing experience is better than my desktop and page loads, tab switches etc feel much nimbler than on my desktop (AMD 6 core, 12G monster running Win 7x64)
3. Total cost - USD 180

More to come

1. Hibernation support
2. Torrenting
3. Scheduled wake up from shutdown/hibernate/suspend state

Media center upgrades

I have a small form factor (SFF) machine on the way to take up duties as a media center machine. After waiting for long, finally pulled the trigger on a Foxconn Barebones Book sized system and 4G of RAM. I haven't ordered a hard drive - the plan is to run XBMC completely off a USB drive. As it is, media is on a 1TB external disk and the cost of 2.5" laptop HDDs has gone through the roof.

In terms of software, I've got to figure out which XBMC to use - the contenders are to either install XBMCBuntu or go with one of the specialized builds from OpenElec. I'm still new to both - so will need to do some reading up before I decide.

OpenElec

OpenElec has small footprint (100MB), customized builds for different chipsets. Its meant to be run from a flash drive - so it has a few optimizations to make sure that it doesn't clobber your flash drive. Also, the stable version of OpenElec based on XBMC 10.0 "Dharma" has native AMD Fusion chipset support. Its also designed to be self updating and from reading the manuals, boots right into XBMC and OpenElec settings are all accessed via a XBMC extension so you never have to drop down to the linux machine underneath it.

At this point, looks like OpenELec is really limiting. I would really love to run a browser, use the machine for torrenting etc - and somehow using the XBMC interface for all those doesn't sound too good.

Also, XBMC Eden is supposed to support AMD Fusion natively and OpenElec hasn't been updated yet for Eden (there are nightly builds available though that are based on Eden).

XBMCBuntu

XBMCBuntu is XBMC's official liveCD - you can use the live CD to install to another USB drive media and provided the system can boot from USB, you're off to the races.
The thing here is that it isnt specific to a 'flash' drive - so there's a small tradeoff in terms of the flash drive life. XBMCBuntu is based on Lubuntu 11.10.

Migrating the database

I also have to figure out how to migrate my XBMC database of movie information from Windows XP to the Linux setup - not sure if its even possible - but its something that's definitely worth a shot. In any case, if it doesnt work, then will just let XBMC rebuild its database overnight.

The hardware's supposed to come in april 2nd week - can't wait for it :)

Yoohooo!! Successfully compiled Android from source

Finally!!!

So my last weekend project had been to compile Android ICS from source. Given that the size of the repo itself is in excess of 6Gigs, just getting it down itself took the better part of Friday night and Saturday night. When I got down to running make on it, it was Sunday afternoon.

Needless to say, things didn't work too well. I'm running this on a 32 bit Ubuntu 10.04 Virtualbox with a piddly 1GB RAM. When make failed the first time, realized that swap was a measly 300Mb. First steps first, went on to increase memory to 2GB (that's all I can spare) and increased swap to 2Gs.

Compilation next round started and that failed too - ran out of disk space - and this was Sunday night. Things kind of stayed there and finally this evening, resized the disk in virtualbox to 50Gigs. Again started the compilation and this time ran into linker errors when building webcore. One more round of troubleshooting involved deleting the previously built static library and then running make again. Surprisingly, this time make completed successfully - to the point where I wasn't sure if it had succeeded or just failed silently on something else.

The next step was to run the emulator to see if it really would boot up. Over at source.android.com, they oversimplify it when they say that you just run emulator from the android root folder. That didn't work for me - and this time it was because I hadn't sourced the envSetup.sh file... this thread http://groups.google.com/group/android-platform/browse_thread/thread/91ff18e034acf951 helped in tracking that one down.

So finally, after all that trouble, I have my very own ICS build running!!!!

For now, its onward ahoy to setting up Eclipse and starting with a fix I've been mulling about for sometime now..

Signing off from cloud nine
R

Ubuntu, Console VIM - weird characters in insert mode

Now that I feel quite comfy with VIM, over the weekend I needed to edit a config file in my Ubuntu 10.10 Virtualbox machine quickly. Instead of GVim, I just opened the file in console VIM. As I hit i to get into insert mode, a bunch of weird character boxes were inserted. That was not good at all :( - just when you think you're comfortable with something if it does something totally weird. In any case, I was in too much of a hurry to bother and went about editing my file with gVim. Also, backspace was wonky (same weird characters) - so I felt better. For some reason that I fail to understand, why must Linux make proper backspace and delete handling such a pain! In any case, it's something that I've dealt with enough times to know that there'll be something on Google.

Later on, tried to see what all the fuss was about. Googling around, I found :help :fixdel and that seemed simple enough. Alas, when I tried it out, it didn't fix the issue at all. Also, I seemed to be getting weird characters just pressing i to get into insert mode - and the VIM wiki page didn't have anything about that. Neither did Google turn up anything that seemed related.

So today early morning, on a whim, read up a little on VIm terminal handling. I have the following in my .vimrc
[sourcecode language="text"]
set t_Co=256
[/sourcecode]
Maybe it was the color escape code that was coming in - so checked out :echoe &term which returned xterm under gnome-console and builtin_gui under gvim. So I've put the following bit in my .vimrc and it seems to have fixed things nicely:
[sourcecode language="text"]
if &term == "xterm"
set term=xterm-256color
endif
[/sourcecode]

Compact Ubuntu

I've always hated the fact that on Ubuntu with the default themes, there's far too much space wasted. The buttons are too tall, the treeview wastes too much space so that if you're on eclipse or some other ide, you see a precious few items on the screen.

I've been trying to tweak it to no end - even looking to see if there are any ~/.gtkrc-2.0 tweaks. Found a few links such as this Making Eclipse look good on Linux - Max's blog - however, didn't really satisfy my need.

And so it stayed until today when I came across Clearlooks Compact Gnome Theme.

I love it - one more for my list of must-haves!