I've been a bit busy the past few months crafting another app for Android. Today, I hit the big scary 'publish' button and released it onto the market.

Alf for LOVEFiLM is a an Android client for the LOVEFiLM rental service, allowing you to browse their catalogue of films, television and games, and rent those that take your fancy. If you've not got an account with LOVEFiLM yet, you can sign up for a month free.

It's now available in the Android Market for £1. Only available to UK users for the moment as the LOVEFiLM API doesn't support other countries yet.

The BBC have released an official iPlayer app for Android (running firmware 2.2 or later). The lack of an way to access iPlayer from my G1 was the original reason I wrote beebPlayer, so to finally have an official solution makes me very happy indeed.

Any existing beebPlayer users may find that they get an obscure "-2147483648" error message when attempting to access any streams. It is an ex-parrot.

I've just pushed Tweetabouts 1.3.2 to the market. Changes in this version:

• Tweetabouts now respects the system-wide background data setting.
• Minor polish to UI, including tweaks for low- and high-resolution screens.
• Fix for a bug that led to log pruning not working, causing the update log growing very large over time.
• Minor update code cleanup.

Go update and frolic, or whatever it is one does with a freshly-updated location field in ones Twitter profile at this time of year.

Excessive filtering courtesy of Vignette.

(download)

Click here to download:

Snow_joke.zip (11.69 MB)

Around 6 months ago, my beloved Dell XPS M1330 died, firstly of a bad power jack, and then due to a bad motherboard (the GPU overheated for a second time, outside of the extended warranty Dell granted after its first demise). So, I’ve been on a notebook hunt ever since, trying to find the perfect PC that’ll do me for the next 2-3 years – until it inevitably breaks or gets swallowed whole by a particularly vicious grue.

Several purchases-and-returns later (a Lenovo T410, a Dell XPS16 and a Sony Vaio F11), I managed to snag a Sony CW2 (VPCCW2C5E) off Sony’s clearance section meeting my requirements: an i5, a good nVidia GT330M GPU (read: GT325M GPU), a high-res 1600x900 14" LED screen, only a little bigger than my old M1330 for less than £800. A decent upgrade from my old laptop, and a significant upgrade from the Dell Mini 1012 netbook I’d been using in the intervening months.

Having somehow trashed the Windows 7 install by turning the machine on, I got to work on installing something better, and so, for later reference (should the Sony warranty cover hungry grues), here’s the process I went through in getting it all to work.

Installation

I had opted for Ubuntu 10.10, it being only a week or two old at this stage and being what I used on my other systems. The first hurdle was to get the installer displaying anything – easily resolved by selecting F6 on the boot screen and enabling the ‘nomodeset’ kernel parameter. The installation went rather smoothly once going, although I (fortunately) chose not to download and update with the latest packages while installing.

To cut a long-story short, the first problem came while trying to install the nVidia drivers. Despite being a 64-bit machine, I initially downloaded and installed the live x86 32-bit version. However, this led to issues with the nVidia driver and nouveau driver not leaving enough memory for each other (I had various vmalloc and ‘bad RIP value’ errors in the kernel log when starting X). nVidia’s proposed solution: go 64-bit.

Having heard about the issues of going 64-bit, I then read this Phoronix article of 32-bit vs 64-bit benchmarks. Convinced, I grabbed the 64-bit DVD, and started again.

Out-of-the-box

On first boot, nearly everything seemed to work – I had a display, audio, working touchpad, and I was even able to connect to my WiFi network. But those were minor issues, “easily fixed”, I figured…

Immediate issues

However, there were also some major issues. To even get to the desktop, I’d had to again add the ‘nomodeset’ kernel parameter while booting to get anything on the screen. When booted, the display was low-resolution and refused to budge up to the native 1600x900 of my panel. The WiFi connection was incredibly slow, loading pages even slower than my Nexus One on the same WiFi network. I couldn’t change the display brightness, and suspending didn’t work – it just rebooted.

WiFi

While I was able to connect to my WPA2 network as soon as I had logged in, wget was reporting download speeds of ~50kb/s at best, rather than the 1-2Mb I typically get on my other machines. This was going to make updating my system very very very slow indeed unless fixed, and I had no desire to tether myself to the router via a rather unsexy grey ethernet cable.

Nor did I want to spend the rest of the evening swapping out the mini-PCI Atheros AR9285 card for the Intel one in my netbook, so I opted for the proper solution – obtaining an updated ath9k module which contained a fix for this issue. I downloaded the latest source tarball from the Linux Wireless website, compiled, installed, and rebooted (for good measure). Instantly speedy.

Graphics

Next task was to get rid of the ugly 1024x768 scaled desktop and get the 1600x900 the panel was capable of. I headed to Ubuntu’s “Additional Drivers” app to automatically download and install the latest nVidia drivers in the Ubuntu repository, which turned out to be 260.19.12. With the WiFi fixed, these downloaded and installed rather promptly, but after rebooting I got barely more than a blank screen and – if I was lucky – the welcome sound. I rebooted with ‘nomodeset’ again (bypassing the newly-installed nVidia module), and downloaded the latest drivers from nVidia’s site to install manually. Rebooted. Same issue. 

I suspected the nouveau issues were causing the problem, based on forum reports, but I did not want to blacklist nor remove them since they can be useful for the text-mode TTYs. I consulted the forums again.

Fortunately, the problem was not the nouveau drivers, but rather the version of the nVidia driver I was using (thanks to Mrnelson1986). For some reason, 260.19.12 simply did not want to play nice. I rebooted with ‘nomodeset’ again and headed to the nVidia website to download the 256.53 drivers (which they very fortunately keep archived for cases like these). 

Before installing them, I did some preparation:

• Uninstalled my manually-installed nVidia drivers by re-running the same install script with ‘—uninstall’
• I ran ‘sudo apt-get remove --purge nvidia-*’ to remove the existing nvidia drivers I had installed from the PPA
• Noted down the values I’d need to put in xorg.conf (apparently not needed on 260.19.12 drivers)
• Downloaded the SNY06FA.BIN EDID file and threw it in /etc/X11 (again, apparently not needed on 260-and-later drivers)

I then proceeeded to install the newly-downloaded 256.xx drivers from nVidia. I did it like this:

1. Dropped to a terminal
2. Stopped X with ‘sudo service gdm stop’
3. Ran the nVidia installer (‘chmod +x nvidia-installer.run; sudo ./nvidia-installer.run’)
4. Edited xorg.conf to add the EDID and monitor declarations (see below)
5. Rebooted!

And, astonishingly, it worked. The default Ubuntu desktop at 1600x900 looked lovely, although the default ‘tulip’ wallpaper required replacement to really shine.

Here’s the Device section of my xorg.conf (based on the xorg.conf that nvidia-xconfig generated for me)

Section "Device"
    Identifier  "Device0"
    Driver      "nvidia"
    VendorName  "NVIDIA Corporation"
    Option      "ConnectedMonitor"  "DFP-0"
    Option      "CustomEDID"        "DFP-0:/etc/X11/SNY06FA.bin"
    Option      "RegistryDwords"    "EnableBrightnessControl=1"
EndSection

Backlight

It was quite late in the evening at this point, and the bright display was starting to irritate my eyes, so I attempted to reduce its brightness. Unfortunately, it’s impossible to alter the backlight on a fresh install – either via the labelled Fn-F5/F6 keys or poking around – so I had to do further digging.

First was to confirm whether the keys were working and being recognised. acpi_listen proved they were, there was just nothing responding to them.

Half the solution is to install the nvidia_bl module, handily provided in the mactel-support PPA. This added an entry to the proc filesystem that lets me manually adjust the brightness – but by default, its maximum allowable brightness was ‘2048’, which is just bright enough to see in a dark room, but I needed brighter. 

The backlight module didn’t seem to know about my particular model, so was setting a low value as a precaution. This was easily overidden by adding the line ‘options nvidia_bl max_level=0x10000 shift=9’ to /etc/modprobe/nvidia-bl-dkms.conf to tweak the range of exposed values. A ‘modprobe -r nvidia_bl; modprobe nvidia_bl’ later, and screen brightness could be controlled with ‘echo 100 | tee /sys/class/backlight/nvidia_backlight/brightness’.

Fixing the Fn-F5/Fn-F6 keys to work as labelled took a little more work, and the solution I’m now using isn’t exactly ideal as it doesn’t use Gnome’s own brightness controls (so there’s no on-screen display when the brightness is changed). The workaround involved identifying the appropriate keycodes using acpi_listen, and then use these to create 2 custom ACPI events, as well as a pair of scripts that would increase/decrease screen brightness as needed using the method described in the last paragraph.

The first task involved writing two bash scripts that would increase or decrease the screen brightness when executed by retrieving the current brightness value, adding or subtracting 10, and then setting to the new value. These were to be executed when the keys were pressed, and saved in /etc/acpi with names of ‘sony-brn-up.sh’ and ‘sony-brn-down.sh’ in line with the other scripts in the same directory.

Secondly, I created two additional files in /etc/acpi/events named ‘sony-brightness-up’ and ‘sony-brightness-down’ which are read by ACPI to identify a key code to listen for and the associated action (event) to execute when they occur. They were basically copies of the existing scripts in that directory, modified accordingly to reference the sony-brn-up.sh and sony-brn-down.sh scripts respectively.

Turns out there are similar scripts available for the Sony F11 which do the same as mine, better, and I should probably use instead.

Suspend

Easy to fix by adding ‘acpi_sleep=nonvs’ as a kernel parameter (source). Best done by editing /etc/defaults/grub and running update-grub to propagate the changes through to grub.cfg.

Miscellany

• Attempting to run L4D2 under Wine gave me various errors about not being able to initialise OpenGL. The solution was to install ia32-libs, boot into text-mode (‘text’ boot parameter) and then re-run the nVidia installer, making sure to select to install the 32-bit compatibility OpenGL libs when prompted. L4D2 ran after this step, albeit with significant mouse lag that I’ve yet to investigate.
• Battery life seemed short (1-2 hours), but was resolved by installing cpufreqd and enabling the on-demand power governor to enable dynamic CPU clocking. Now sits at 2-3 hours, which still seems remarkably short. I’ve been spoilt by the netbook, curse it.
• Currently, using 64-bit Ubuntu has thrown up only one, minor, easily solved issue regarding installing Adobe Air – which is 32-bit only. Other than that, completely plain sailing – even Flash works!
• The lid really is a smudge magnet. I need jeweller’s gloves…
• The BIOS is extremely sparse – hardly anything can be tweaked besides the date, time and boot order. I’m sure there must be a way to get at all the juicy stuff but fortunately I don’t need or want to… yet.
• It was 4 weeks between ordering the thing and Sony UK actually shipping it. Even worse, they took payment immediately after the order was placed (rather than on day of dispatch), so I was £800 poorer for nothing to show for it for nearly a month. Not impressed by that at all, which was apparently caused by them refurbishing their warehouse in preparation for Christmas… (they’re obviously planning to sell a lot of “3D” tellies and glowing magic wands this winter.)

03/01/11 ‘Laptop battery critically low’

After unplugging the machine from charge, I would frequently get an on-screen Gnome dialog telling me the battery was critically low, and then going into hibernation unless I pressed ‘Cancel’ quickly enough. This is a known bug and can be worked around using ‘gconftool-2 --type bool --set /apps/gnome-power-manager/general/use_time_for_policy false’ (only retained for the duration of each Gnome session).

17/01/11 nVidia drivers

Fed up with having to reinstall the 256.19 drivers every time I updated my kernel, and running several revisions behind the latest driver release, I’ve found a better way. sudo add-apt-repository ppa:ubuntu-x-swat/x-updates && sudo apt-get update && sudo apt-get nvidia-current does the trick. (Remember to uninstall the nVidia drivers using ./NVIDIA-Linux-x86_64-256.19.sh --uninstall first.

Remaining issues

The biggest remaining issue is the corrupt display when accessing a text-mode TTY. Minor issues include the screen corruption on suspend/restore, the hacky brightness control, and powertop reports a high frequency of kernel wakeups, which may be affecting the battery life somewhat.

I’ll update this post if/when I discover solutions to these issues, and with anything else that pops up.

I admit to being slightly disappointed to find the Vaio rather hostile to Linux, but this seems largely due to the Vaio’s various proprietary bits and bobs and Sony’s own deviations from the normal components. My Dell M1330 ran beautifully, as does the Mini 1012, with absolutely minimal post-install tweaking. Perhaps it’s simply the Dell machines have had more attention from Linux hackers than this Vaio, but in the end, it’s working well enough for me not to worry about it.

Tweetabouts 1.3.0 is now on the Android Market. Only one real change here - support for OAuth, as necessitated by all apps that use the Twitter API.

Let me know if you encounter any issues (I imagine there may be some, as lack of internet access made it particularly difficult to test!)

Update: Just released 1.3.1 to fix a crash when updating location manually.

BBC iPlayer Mobile boss David Madden explains on the iPlayer blog how the BBC are approaching Android support. He specifically explains what happened with beebPlayer:

Tiggs questioned why the BBC took down the beebPlayer which worked on older Android devices and did not rely on Flash, and why we have replaced it with something that only works on newer devices and requires Flash.

The BBC's syndication policy, which governs how the BBC makes its services available through other parties, clearly outlines the criteria for using BBC content. BeebPlayer was not a licensed distributor of BBC content online or on mobile. The BBC routinely looks for unauthorised usage of our brand and our content across all platforms and when we encounter it we work to resolve the issue. If on investigation we find that a company's service proposition does not adhere to our standard licence terms and conditions, we will take steps to remedy the issue.

While I was developing beebPlayer – and also since I’ve discontinued it – I’ve been surprised at some of the misunderstandings about how it actually worked. In fact, so much that I felt I should probably explain exactly what beebPlayer was and how it worked. Right now.

…but first we need to establish what the BBC’s iPlayer is.

iPlayer isn’t just a website – it’s an encoding powerhouse and delivery platform. It’s responsible for chewing through hours of broadcast TV and pumping out each programme into many different forms to ensure the widest and greatest number of people are able to access the content. For example, the finale of Doctor Who on Saturday will first have been converted into a dozen or so different formats. Half of these are all mostly the same format, but simply at different bitrates and qualities to suit a variety of different users on both slow and fast connections (smartly chosen automatically by the Flash player). There’s another format for viewers who want to watch the HD version. There are a few more versions for iPhone/iPod/iPad users. Then there are a couple more for services such as Virgin’s net-connected Freeview boxes. To encode all this on a normal desktop PC would take a few days, if not a week – and yet the BBC has to do this for every single television programme they air, for every hour of every channel every day. Altogether, it’s a complex and impressive system – and that’s before the whole server architecture, networking backend and immense amounts of bandwidth required to get it from the BBC’s servers to the content servers (mirrors) and finally from those all the way to your monitor or screen at the same time as everyone else. And of course, there’s also radio…

However, for our purposes, the most important thing about iPlayer is that it also caters for mobile phones, primarily those running the Symbian operating system (i.e. most ‘dumbphones’ made by Nokia, Sony-Ericsson and so on.), and provides mobile streams for these phones in a 3G streaming format designed for small screens and delivered over RTSP. All users of these phones have to do is load up their WAP or WWW browser and head to the iPlayer website to install the iPlayer app onto their phone.

Unfortunately, the BBC mobile TV website isn’t (or rather, wasn’t) particularly knowledgeable about Android phones. So, while Android phones were technically capable of playing these streams, they simply weren’t made available. (Why? I’ll come to that that later.)

This is where beebPlayer came in – allowing Android phones to access the streams intended for simpler phones* by simply reading the appropriate URLs. Unfortunately, the use of the mobile streams – which remember are designed for phones with small screens and not much CPU power – aren’t exactly beautiful on the big 3" screens that adorn most Android phones. The smearing, pixellation and sub-standard sound don’t exactly make for a cinematic viewing experience, but that wasn’t the point. The point was: “BBC iPlayer on my shiny new expensive phone!”

But, that’s all beebPlayer was – a simple little interface for the content that the BBC already produces. It really isn’t much more than a user interface for an XML reader that any competent Android programmer could whip up in an evening, if not a weekend. Indeed, the very first version of beebPlayer was practically that! Subsequent versions simply added more layers of polish and tweaks, but never anything particularly complicated (well, subtitles were a little tricky). It certainly didn’t require much investment from me, besides time and a little sweat. From the outset, my only aim was to provide a basic level of access to iPlayer content until the BBC could provide a more comprehensive and acceptable solution.

Were it not for the iPlayer platform pushing out two streams that most Android phones were capable of playing, beebPlayer would not have been possible without a lot of extra time and investment to augment Android’s existing media framework so it could understand the other streams. Fortunately, Android 1.5 and higher have had little problem playing the mobile streams provided by iPlayer, which made making beebPlayer very simple indeed! That is to say: the real power (read: magic) behind beebPlayer was the BBC.

Of course, there were problems. While Android is technically capable of playing those mobile streams, those mobile streams weren’t exactly designed nor tested for Android. Small errors or unexpected changes in the stream would utterly confuse Android, and hence would be unable to play the stream at all. In other cases, Android simply dislikes some routers (or rather they dislike Android and/or the BBC streams.) The mobile streams were great for mobile phones, but not so great for Android phones. For this reason, beebPlayer was not without its flaws – most of them were beyond my power to rectify.

The new iPlayer site does a much better job at providing a good experience for Android users than beebPlayer ever could have – not only are the streams it uses designed specifically for Android phones, but because of this they’re higher quality and less likely to break at the merest sign of a lost bit or byte. It’s also maintained by the BBC and paid for by the license fee, so it’s level of service will be far higher than what beebPlayer could provide.

The fact the new site is limited to Flash-enabled devices is a sore-spot, but I can understand this requirement and its benefits, as well as its current and future limitations. RTSP (mobile/beebPlayer) isn’t exactly an ideal alternative if you have a level of service you wish to maintain, something RTMP (Flash) is far better at providing, especially across multiple different platforms.

And that’s how beebPlayer worked.

* Despite what many people assumed, beebPlayer did not use the higher-quality iPhone MP4 streams – which are simply not quite compatible with Android (but only by a whisker – while Android phones are easily capable of playing the streams, they just don’t quite understand the QuickTime container used.)

The BBC have just announced that their iPlayer site now supports Android!

Of course, it's 2.2/Flash-only... and only works on WiFi (unless you're on 3's or Vodafone's 3G network, which I'm not)... 

Finally :)