It took a bit of extra futzing around to get it working under Linux (Fedora 14 in my case), but I got there in the end. Amazingly it supports all my devices (TV, PVR, DVD, RX) despite some of them being ancient and obscure, for example a cheap and cheerful Telefunken DVD player.

Logitech has a web site for configuring and downloading the settings needed to control up to five of your AV devices with the Harmony remote. Unfortunately, the current configuration site balks with an ‘unsupported operating system’ / missing plugin error when visited from a browser running on Linux. Time to head off the beaten track…

The ‘congruity’ package provides a graphical setup for the Logitech Harmony. The process still involves configuring the device from a Logitech website, but at an alternative URL, and some preparation is required:

1. Install the ‘congruity’ package. In Fedora: sudo yum install congruity
2. Configure the web browser to ask what to do with download links. In Firefox: Edit->Preferences->General->Downloads->Always ask me where to save files

Now go through the following process:

1. Plug in the remote via the provided USB cable.
2. Visit the URL mentioned above.
3. Create an account (why do I need to provide my name to program a remote control?)
4. Skip/ignore the “you need to update your software” steps, and eventually a download prompt appears.
5. Choosing ‘open’ rather than ‘save’ impressively results in the Congruity graphical setup up launching.
6. Step through the setup boxes as prompted.

However, in my case the remote control detection phrase failed. This was overcome by updating the concordance package from 0.21 to 0.23 and trying again. See further below for the sordid details.

I was then able to select my four devices and program the Harmony remote control unit.

I encountered some teething issues when attempting some tasks with the remote, e.g. the wrong AV input was selected on the TV or the DVD player wouldn’t switch off, but I pressed the ‘help’ button on the remote and it tried some things and made it work!

The only thing I couldn’t get to work was changing the band (AM/FM) on the radio tuner of the AV receiver (Yamaha RX-V361).

Now, provided the devices are in standby mode, it is a one touch action to have everything setup to watch TV, then another to watch a DVD and so on. This saves a lot of fiddling and lengthy explanations to visitors of how correctly set all the various remotes to watch TV, not to mention removing some clutter.

It’s a shame that the Linux configuration is not smoother. Perhaps it could work better by separating out the concordance device identification data, and provide a mechanism for updating that alone, without having to recompile or rebuild the whole package.

It’s also a bit unsettling that future reprogramming of the remote is dependent on Logitech’s website being operational. It feels all too inevitable that bit-rot will set in once Logitech’s priorities shift onto newer products.

Nevertheless, it’s working just well enough for now.

Sordid details:

In different attempts the following errors occurred during the detection phase within the Congruity graphical app:

LibConcordException: libconcord function 'init_concord' failed with error code 11 ('Error connecting or finding the remote')

…and…

LibConcordException: libconcord function 'get_identity' failed with error code 1 ('Unknown error')

Now for the investigative diagnostics:

Running the ‘concordance’ command line app to display detected info also failed to find the device in my case: sudo concordance -i

Concordance 0.21
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

ERROR: failed to requesting identity
Requesting Identity: Failed with error 1

Digging a bit deeper reveals the relevant USB device ID information, and shows that at some level the operating system is aware of the device:

lsusb | grep -i logitech

Bus 005 Device 006: ID 046d:c122 Logitech, Inc. Harmony 700 Remote

dmesg

[ 8041.000104] usb 5-1: new full speed USB device using uhci_hcd and address 6
[ 8042.176170] usb 5-1: New USB device found, idVendor=046d, idProduct=c122
[ 8042.176181] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8042.176189] usb 5-1: Product: Harmony Remote 0-0.2.0
[ 8042.176195] usb 5-1: Manufacturer: Harmony Remote 0-0.2.0

Interestingly, while my particular unit was marketed as a “Logitech Harmony 600 Five-In-One Universal Remote”, lsusb reports it as a Logitech Harmony 700 Remote.

Some web searching turned up a useful thread on troubleshooting Harmony software setup with Congruity and Concordance:

i had the same problem.
I bought a Harmony 650, and concordance (0.21) doesnt detect it.
Easy solution: install concordance 0.23″

Now, I tend to prefer the clean solution to the easy one. In Fedora that involves building and upgrading relevant RPM packages (as opposed to downloading the tarball and doing a make install as root, which doesn’t have the traceability that RPM packaging gives).

Here is an outline of the steps:

1. Remove the existing packages to avoid conflicts later on: sudo yum remove congruity
2. Install build dependencies: sudo yum install libusb-devel python-devel
3. Download standard Fedora source packages for libconcord and concordance in order to get the .spec files: yumdownloader --source --disablerepo=ifedora --enablerepo=fedora libconcord concordance
4. Download the concordance-0.23.tar.bz source tarball in a web browser.
5. Edit libconcord.spec and comment out the patch lines, and replace references to version 0.21 with 0.23:

   #Patch0: libconcord-0.21-mime-type-def.patch
   #%patch0 -p1
   # Comment out mime file
   #%{_datadir}/mime/packages/%{name}.xml
   

   The patch lines need to be removed to avoid errors during the rpmbuild phase like the following:

   Reversed (or previously applied) patch detected!  Assume -R? [n] n
   
   RPM build errors:
       File not found: /home/makerpm/rpmbuild/BUILDROOT/libconcord-0.23-1.fc14.x86_64/usr/share/mime/packages/libconcord.xml
   

6. Change to “makerpm” user su - makerpm and copy the spec files in the SPECS directory and the tarball into the SOURCES directory.
7. Build the libconcord rpm package: rpmbuild -ba libconcord.spec
8. Install the generated rpm: sudo yum localinstall --nogpgcheck /home/makerpm/rpmbuild/RPMS/x86_64/libconcord-python-0.23-1.fc14.x86_64.rpm
   If this is not done at this point then the latter rpm building will fail with something like:

   error: Failed build dependencies:
   	libconcord-devel >= 0.23 is needed by concordance-0.23-1.fc14.x86_64
   

9. Edit concordance.spec and change all occurrences of the version 0.21 to 0.23
10. Build the concordance rpm package: rpmbuild -ba SPECS/concordance.spec
11. Install the resultant packages: yum localinstall --nogpgcheck /home/makerpm/rpmbuild/RPMS/x86_64/libconcord-python-0.23-1.fc14.x86_64.rpm
yum localinstall --nogpgcheck /home/makerpm/rpmbuild/RPMS/x86_64/concordance-0.23-1.fc14.x86_64.rpm
12. Install congruity again, now that the backend has been upgraded: sudo yum install congruity

Note that I’ve missed some steps above, e.g. some variant of rpmbuild --rebuild xyz.srpm which is left as an exercise for the reader.

Now the concordance tool will be cleanly installed and should show up the device:

[root@orange etc]# concordance -i
Concordance 0.23
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

Requesting Identity: 100%                 done
  Model: Logitech Harmony 700 (Molson)
  Firmware Version: 0.2
  Hardware Version: 1.1
  Config Flash Used: 12% (473 of 3904 KiB)

The Ubuntu forum thread also mentioned the following which may be required in some cases:
echo 'SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c122", MODE="666"' |tee /etc/udev/rules.d/custom-concordance.rules
Also tried changing SYSFS to ATTR, based on warnings in /var/log/messages

At this point, the web configuration steps outlined earlier in the post should work, with congruity successfully detecting the Harmony remote, allowing subsequent software setup.

# Note: about 1.3GB of workspace was required to generate 170MB output, in this case a short slide show with sound track.
# 

yum install vobcopy mjpegtools dvdauthor
mkdir video_work
cd video_work
vobcopy -l
mkfifo stream.yuv
mplayer -ao null -noframedrop -vo yuv4mpeg VIDEONAME.vob &
cat stream.yuv|yuvfps -r25:1|yuvscaler -n p -O DVD |mpeg2enc -n p -f 8 -F 3 -o out.m2v
mplayer -ao pcm -vo null -vc dummy VIDEONAME.vob
# Note: 224000 bits per second (224kbits/sec)
ffmpeg -ab 224000 -ac 2 -ar 48000 -i audiodump.wav audiodump.ac3
mplex -f 8 -o ready-to-master.mpg out.m2v audiodump.ac3
mkdir dvdauthor_out
cat << EOF > dvdauthor.xml
<dvdauthor dest="/data_dir/video_work/dvdauthor_out">
<vmgm>
</vmgm>
<titleset>
<titles>
<video />
<pgc>
<vob file="ready-to-master.mpg" />
</pgc>
</titles>
</titleset>
</dvdauthor>
EOF
dvdauthor -x dvdauthor.xml
growisofs -Z /dev/dvd -dvd-video dvdauthor_out

After a quick look around it appears the only LightScribe labelling software available for Linux is proprietary. LaCie provide the software in RPM packages which is nice if you are a Fedora user like me. (Apparently they have tested it with the other major distros, which is nice to see.) It installed fine under Fedora 10 beta, which was a nice surprise given that it was apparently written for Fedora 5. It didn’t install a menu entry, but firing up the “LaCie Lightscribe Labeller”, ’4L-gui’, provided a reasonably nice experience.

I grabbed some DVD media artwork from the Fedora art team. There were two labels in each image file, so I had to pick one and chop it in half with the GIMP. I then cropped it to remove the alignment patterns, and then did an autocrop to crop to the edge of the DVD label. Then it was a simple matter of importing it in the 4L-gui and selecting ‘fit image height to disc’.

Writing the disc label took a bewilderingly long 15 minutes. I suppose it is effectively doing the same thing as burning a CD, but it’s a big wait for little reward. The inscribed label is a hazy monochrome image that is below the surface of the disc.

In future I think I’ll just use a pen. Nevertheless, it’s interesting to the see the improvement in the quality of Linux software provided by a hardware vendor. It would be even better if they would free the code. This would enable distros to incorporate the software into the main repos, making the experience a bit more streamlined and integrated.