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:

1. the Bluetooth Touch Adapter connects to the "VW UHV" device via bluetooth
   
2. the phone connects to "Touch Adapter" device, also via bluetooth

The device doesn't allow step 2 if step 1 didn't succeed. Apparently this complex setup was necessary to allow the Bluetooth Touch Adapter to request phonebook, call list, and SMS information from the phone.

But it's not just good news: because the audio link from phone to car isn't direct, non-call audio functions don't work. The phone thinks it'll receive audio through BT, so doesn't use its own mic, but there's no BT audio feed because the BT Touch Adapter knows there's no call going on. And maybe worse: from time to time, I've experienced connection problems in step 1: the Bluetooth Touch Adapter fails to connect with VW UHV. With the limited UI of the device, this is almost impossible to troubleshoot. This seems to happen mostly after I've unlocked the car, and then closed it without ever turning on the ignition. On opening and starting the car minutes later, the connection failure happens.

the only remedy I've found is to turn on the ignition, "open" the VW UHV for new connections (press the phone button on the steering wheel twice), and keep doing that (every 5 to 10 seconds) until the unit connects. If it still fails, keep "opening" the VW UHV unit and use the "Settings", "Bluetooth", "Connect UHV" function on the BT Touch Adapter to retry. I'm hoping this will be fixed in a firmware update some day...

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 zeroes will help a (re)conversion to thin provisioning later, and for dedup they are now empty blocks again, so perfect sharing possibilities.
Overwriting just the old data blocks is hard, but you can probably live with overwriting both empty and old data blocks. This will allocate all blocks (byebye thin provisioning, for now), but the contents will be all-zeroes: perfect thin re-thin-provisioning later, and perfect for dedup.
for each local filesystem mounted on your system, you can execute

dd if=/dev/zero of=/$mountpoint/tempfile.zeroes ; rm -f /$mountpoint/tempfile.zeroes

be careful, this will - very briefly - fill up your filesystem(s). If your application can't handle this, do it when that app isn't running. For those of you who use LVM, the unallocated PE's in every VG aren't cleared by this procedure, so for every Volume Group, find out name and available free space:

vgs -o vg_name,vg_free

then run (fill $vg_free and $vg_name with the data you just gathered)

lvcreate -n zerolv -L $vg_free $vg_name && dd if=/dev/zero of=/dev/$vgname/zerolv ; lvchange -a n /dev/$vgname/zerolv && lvremove /dev/$vgname/zerolv

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 0.6.6.2 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 server. The Yamaha gets "All Tracks", "Artist", and "Album" listings.
I'll stick with this second solution until I can have the Coherence MediaDB dependencies on CentOS too.

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 speedtest.net in my bookmarks.