Skip to main content


Showing posts from February, 2010

Volkswagen UHV bluetooth touch adapter & its problems

My Volkswagen car has the "universal cellphone preparation" UHV built-in. This is the main part of a car kit, but requires an additional adapter for connecting to a cellphone. At first, I was using an adapter for my good old Nokia 6310, even after I changed to the Nokia E71. Connecting was easy: pair the phone with the "VW UHV" bluetooth entity, and done. This has the phone connected to the car kit at all times, so even non-call-related functions use the car audio system (e.g. voice recognition). But progress will have its way, no matter what happens. So in comes the "bluetooth touch adapter". Instead of a phone-specific adapter, this is a small touchscreen device that slots into the UHV dashboard mount. Connecting a phone is very different now: the Bluetooth Touch Adapter connects to the "VW UHV" device via bluetooth the phone connects to "Touch Adapter" device, also via bluetooth The device doesn't allow step 2 if step 1 didn'

Preparing Linux for optimal thin provisioning and deduplication

VMware and disk-array based thin provisioning can help you economize on disk space, just as disk-array based deduplication can. But how to take optimal advantage of those techniques ? Executive summary: dd if=/dev/zero of=/tmp/tempfile.zeroes ; rm -f /tmp/tempfile.zeroes First of all, both thin provisioning and deduplication work transparently. But you can make them work better with a little bit of work. There's three different types of blocks on your (virtual) disk that we need to distinguish: data blocks, old data blocks, and empty blocks. Data blocks and empty blocks are what they are, and can't be influenced. Data blocks contain data for files that are on your filesystem. Empty blocks are empty, have never been written to with any real data, so their blank, contain only zeroes. It's the "old data" blocks that we can improve: they contain data that used to be part of a file. The file got deleted, but the contents are still there. Overwriting those blocks with

DLNA with Linux and a Yamaha RX-V2065

The Yamaha RX-V2065 is the first non-PC-based surround sound system I own. In addition to playing everything radio and hdmi-based, this receiver has an Ethernet connection. It can stream a long list of Internet radio stations, and it can find DLNA media servers on the local network to play various audio formats (no Ogg Vorbis though). I've got my collection of some 400 CD's in mp3 format stored on my CentOS Linux fileserver, so obviously I wanted to access these files from the RX-V2065. First attempt: Coherence on the CentOS 5.4 fileserver. Because of missing dependencies, only the FSStore backend worked. Streaming worked, but no Track/Artist/Album fields were passed through. Second attempt: Coherence 0.6.4 on Ubuntu 9.10 in a VM, with the mp3 catalog mounted via NFS. Now the FSStore backend still works, and the MediaDB backend too. This second backend does provide Track/Artist/Album information, and even Album Cover art, downloaded using albumart-qt 1.6.6 on the CentOS

ADSL speed

ADSL has got me stumped. A couple of months ago, Scarlet (aka Belgacom) claimed that even though my ADSL2 modem synced at around 6Mbps, it wasn't unusual that the maximum downstream data rate was 1Mbps, because of the distance from the modem to the ADSL concentrator apparatus thing. Even though I was very sure that it had been 3+Mbps over a year ago. Today I notice, from the corner of my eye, the download speed of a virtual appliance I was fetching: 500+ KBps, or a good 5 Mbps. Sync rate of my modem is still 6Mbps. Was something changed at the Scarlet/Belgacom side ? If yes, why ? Or am I blessed by a unique and unexplained cosmic alignment of some sort ? I just hope it doesn't go down again. Maybe I should keep in my bookmarks.