Well I thought I ought to sort out my laptop to connect to my CompuTrainer for the upcoming winter indoor training which ought to take place. As it turns out, I ran into a few issues as my laptop has been rebuilt since I last used the CompuTrainer connected to my laptop. I’ve been using the CompuTrainer handlebar control for varying the power rather than courses or 3D videos.

Anyway the bits of software I’ve installed are:

CompuTrainer 3D

http://www.computrainer.com/html/improvements_to_3d_v3.htm

Download the latest version (v3.0 2010/08/05) and install. Make sure to install into C:\ and not C:\program files.

Coaching Software CS

http://www.computrainer.com/html/coaching_software_support.htm

Download and install into C:\ aswell. This is now free.

Topo GPS

http://www.computrainer.com/html/TopoUSAsupport.htm

Download and install. I also needed to download the “other” topogps.exe from

http://www.racermate.net/forum/download/file.php?id=157

which was included in the forum post at

http://www.racermate.net/forum/viewtopic.php?f=11&t=3516

Without this update I was unable to view/edit 3DC files, as described in the forum post. The error in the application’s fatal.log file was:

Error in X:\_f\lib\velib2\willcourse.cpp at line 113:
nlegs error

This is a great piece of software which allows one to convert .gpx files into .3dc files which can be “ridden” using the CompuTrainer 3D software.

 

I am considering getting the updated RacerMate One software which has recently been released. I do wonder how useful it wil be though. Hopefully DC Rainmaker will do an indepth review of the software in the near future.

When using Veritas Cluster Server (VCS), the following error messages from your system logs can indicate a problem with the cluster heartbeat interconnects:

Dec 12 15:26:20 serverb llt: [ID 194859 kern.notice] LLT:10019: delayed hb 935350 ticks from 1 link 0 (qfe:0)
Dec 12 15:26:20 serverb llt: [ID 761530 kern.notice] LLT:10023: lost 18706 hb seq 3448194 from 1 link 0 (qfe:0)
Dec 12 15:26:20 serverb llt: [ID 194859 kern.notice] LLT:10019: delayed hb 935350 ticks from 1 link 1 (eri:0)
Dec 12 15:26:20 serverb llt: [ID 761530 kern.notice] LLT:10023: lost 18706 hb seq 3448194 from 1 link 1 (eri:0)

These types of messages can be seen when you are running two LLT links over the same physical network. This is bad from a design point of view, as it may introduce a single point of failure. However, there are situations where you may have two physical connections into your cluster servers and have the links run over the same VLAN. If you are sure your interconnects are working properly and you are experiencing this error due to the issue described above then you should be able to solve it by changing your /etc/llttab file on all cluster members.

By default, on Solaris, your /etc/llttab file will look something like this:

set-node servera
set-cluster 1
link eri0 /dev/eri:0 - ether - -
link qfe0 /dev/qfe:0 - ether - -
link-lowpri ce0 /dev/ce:0 - ether - -

The second to last field for each of the links is the SAP field, or ethernet type used for the LLT link. This defaults (when specified using -) to 0xCAFE. Two LLT links on the same physical broadcast domain for a cluster cannot share the same SAP ID. If you do this, you may get the above error messages. Assuming this to be your problem (eg, if you run your eri0 and qfe0 links over the same broadcast domain) you can work around the problem by changing your /etc/llttab file to the following:

set-node servera
set-cluster 1
link eri0 /dev/eri:0 - ether 0xCAFE -
link qfe0 /dev/qfe:0 - ether 0xCAFF -
link-lowpri ce0 /dev/ce:0 - ether - -

This tells LLT to use different SAP types for the two links. All cluster members need to have this change made on them and have the cluster node restarted or have llt restarted.

Sun Blade 100 and Registered/buffered memory

By default, the Sun Blade 100 comes with 133Mhz Sync ECC CL3 unbuffered Dimms. By setting jumper JP6 (which is next to the memory slots) you can use registered/buffered memory in the Sun Blade 100.

The SunSolve handbook for the Sunblade 100 shows where the jumper JP6 is located.

You can mix registered and unregistered memory on the system board and it still appears to work ok.

 

Sun Blade 100, power management and ECC errors

The Sun Blade 100 workstations have a problem with their power mangement circuitry. If power management is enabled within Solaris (or Linux I guess) you can get uncorrectable ECC memory errors or other random hangs.

To work around this, you can edit /etc/power.conf and edit the autopm line to be
autopm disable

Obviously you can just uninstall the power management packages.

SunSolve has document #47042 on this issue. Also searching for “Sun blade 100 Alert” reveals a few more tidbits about this machine.

 

Well, I’m still vetting my HTC Sensation to see if it is a worthy replacement for my BlackBerry… Still not convinced as it happens. However, I have resolved one of my problems with it…

IMAP sent/trash/draft folders don’t work properly if you have a “typical” IMAP server with a folder prefix of “INBOX.”. The IMAP NAMESPACE RFC (RFC2342) defines how this works and how clients should handle it. As usual, Google developers figured they knew better than or just chose to ignore the RFC! As a result, the Andoird mail application doesn’t support folder prefixes, let alone automatically working correctly based on the namespace command.

If you are lucky and are using a IMAP server which does not have a personal namespace (Dovecot??) you might find the mail app works OK for you.

You can use the Android K9 mail client. I briefly tried it and it seemed to work. However, it doesn’t seem as “integrated” as the stock client so I gave up on it. It’s not a bad app – it just didn’t grab my attention. Luckily, there is a work around which is partially documented on the Android issues page at (thanks to those who posted there as it got me working on this workaround):

http://code.google.com/p/android/issues/detail?id=1811 in particular comment 83 and comment 84.

The work around is to reconfigure the mail application’s SQLite database to point to IMAP provided folders rather than the default folders which do not work. On the surface it is pretty easy if your phone is rooted – no idea how I’d do this if the phone was not rooted.

The method I used in the end, to get around the SQLite database files being in use, was to boot to clockworkmod-recovery, mount /data, adb the necessary files to the PC, edit the datafiles using SQLite and push them back using ADB.

The updating of the database is the trick. First, the ID of the account to be “fixed” needs to be determined. This account ID is then used to get a list of corresponding folders’ IDs from the mailboxs [sic]. These IDs and names are then used to update the accounts table which is the “magic bit”.

Here is the code snippet of the steps I followed. If you have a vague idea of technical stuff in this area, you should be able to follow the steps.

**boot into clockworkmod recovery
** mount /data on the phone
** connect USB cable to phone and PC and select HTC Sync mode
** check device can be seen by adb:

adb devices

** copy the data files from the phone to your PC (might not have the -shm and -wal files):

adb pull /data/data/com.htc.android.mail/databases/mail.db
adb pull /data/data/com.htc.android.mail/databases/mail.db-shm
adb pull /data/data/com.htc.android.mail/databases/mail.db-wal

** run sqlite on the data files

sqlite3.exe mail.db
sqlite>  pragma wal_checkpoint;            -- to clear the sqlite logfiles...
sqlite>  pragma wal_checkpoint(FULL);      -- to clear the sqlite logfiles...
sqlite>
sqlite> .headers on       -- to make it easier to see whats happening
sqlite> .mode column      -- or .mode list

sqlite> --view the current folders for all accounts
sqlite> select _id, _name, _sentfolder, _sentfoldertext, _sentfolderid from accounts;
sqlite> select _id, _name, _trashfolder, _trashfoldertext, _trashfolderid from accounts;
sqlite> select _id, _name, _draftfolder, _draftfoldertext, _draftfolderid from accounts;

** based on output from above, determine the _id value for the account to modify (1 is used below in example):

sqlite> select * from mailboxs where _account=1;       --where 1 is from _ID above
sqlite> --below command is more succinct and useful...
sqlite> select _id,_undecodename,_decodename,_shortname from mailboxs where _account=1;   --where 1 is _ID above

** the above will give a list of folder IDs and corresponding names. Hopefully, the _undecodename, _decodename and _shortname fields are equal. If not, then I’m not sure which you’d use in the step below – some trial and error might be needed, but I’d start with the _decodename values.

** if you have a large number of IMAP folders and a “typical” IMAP server, the following should list the three needed folders and their associated IDs:

sqlite> select _id,_undecodename,_decodename,_shortname from mailboxs
   ...> where _account=1 and
   ...> _shortname in ("INBOX.Drafts","INBOX.Sent","INBOX.Trash");

** Once you have the folders’ _id values you use them in the commands below, changing the _sentfolderid, _trashfolderid and _draftfolderid values to correspond with those shown in the above step. Note to change the where clause to reflect the correct account _id used above.

sqlite> --update the folder details
sqlite> update accounts set _sentfolder = 'INBOX.Sent', _sentfoldertext = 'INBOX.Sent', _sentfolderid = 23 where _id=1;
sqlite> update accounts set _trashfolder = 'INBOX.Trash', _trashfoldertext = 'INBOX.Trash', _trashfolderid = 9 where _id=1;
sqlite> update accounts set _draftfolder = 'INBOX.Drafts', _draftfoldertext = 'INBOX.Drafts', _draftfolderid = 27 where _id=1;

sqlite> --exit from sqlite
sqlite> .quit

** back at your DOS prompt, delete the files on your phone (maybe mv instead for backup purposes?? – your choice) and push the updated files

adb shell rm /data/data/com.htc.android.mail/databases/mail.db
adb shell rm /data/data/com.htc.android.mail/databases/mail.db-wal
adb shell rm /data/data/com.htc.android.mail/databases/mail.db-shm
adb push mail.db /data/data/com.htc.android.mail/databases/mail.db
adb push mail.db-wal /data/data/com.htc.android.mail/databases/mail.db-wal
adb push mail.db-shm /data/data/com.htc.android.mail/databases/mail.db-shm

**reboot the phone and hopefully all is working with the correct folders!!

adb reboot

 

Note: If your phone has sqlite3 installed on it and it is rooted, you may be able to issue the above sqlite commands without having to boot into recovery mode. I’m not sure how well the mail app would behave with it’s configuration changing while it is running.

Note2: You do this at your own risk, etc etc. It worked for me. It might work for you – or it might not.

 

Hi,

A technical post for a change… For a while now I have noticed that my Vista laptop has been running with a svchost.exe process at anything from 50% to 100% CPU busy time. I tracked it down to the plug and play and DCOM svchost.exe process. Using Google to investigate this issue revealed that a number of people had the same problem – busy CPU bound svchost.exe processes.

Common causes seem to be bad sound card drivers or VMware’s workstation product’s vNetwork services.  I tried various things to resolve my problem; none of which worked.

Last night I managed to resolve my problem of a busy svchost.exe process. Turns out to be caused by the Garmin Ant Agent needed for my Garmin 405! Quiting the Ant Agent immediately drops the svchost.exe process back to normal and starting it causes the svchost.exe process CPU utilisation to jump skyward. This only happens with the Ant Agent USB device removed. With the USB device inserted the computer appears to be OK. I guess the root cause is the Ant Agent being over zealous with it’s polling to see if the USB device has been inserted.

So for now I will not have the Ant Agent running unless I need it to download a workout from my Garmin 405.