Down to one remote with HDMI-ARC and HDMI-CEC functionality

One of my biggest complaints about getting a home theatre system was the need for multiple remotes.  I know you can buy an all-in-one remote that will manage everything for you but for whatever reason I didn’t do that. I just bought a Samsung Smart TV and decided to look into the state of TV remotes again.

Last night I learned that I was just ignorant of some progress that had been made in this area by two standards: HDMI Audio Return Channel (HDMI-ARC) and HDMI Consumer Electronics Control (HDMI-CEC).  Using these two technologies, I have tied all of my devices together under one remote control.  I push one power button and everything turns on. I push the volume up button on the TV remote and my receiver volume increases.  I want to go to bed and I hit the power button on the TV and both the TV and receiver turn off.  This is the way things always should have been.

Let’s start with HDMI-ARC.  This is quite simple in concept but solves the persistent issue of how do you get audio from the TV back to your receiver.  Most setups I have done and seen involve Blu-ray players, cable STBs and PS3s sending their video and audio to your home cinema receiver then the receiver sends the video to the TV.  Basically, your TV is a dumb monitor.  This all changed when I got my Samsung Smart TV and tried to watch Netflix on it for the first time.  My picture quality was fine but all the audio was coming from my TV!  Enabling the HDMI-ARC on the TV and my Onkyo receiver solved that problem and now it makes no difference where the audio comes from, my receiver can find it.

Next is HDMI-CEC.  You will find this under various brand names like VIERA Link or Anynet+ but they are mostly compliant with the HDMI-CEC standard.  What it allows you to do is send commands over the HDMI cable so when your TV powers up and it’s on the cable input, it tells your cable box to power up too.  When you switch to Blu-ray, it turns that on for you.  My TV also automatically tied into my receiver’s volume control so when you change the volume on the TV it is actually changing the volume on my home cinema receiver.

Sounds like paradise, right?  Well, I have managed to get things gummed up a couple of times and had to reboot everything a couple of times already but I’m hoping that it’s because I don’t have it all hooked up correctly yet.  Also, you’ll probably still need your Tivo remote to do some Tivo things and your Blu-ray remote to do some BD things.  But I’m okay with that.  If I can use one remote 90% of the time then I’m happy.

Using CSS instead of XPath in Xopus config to set placeholder text in Xopus

We have URLs that are generated from the main topic’s title element and we wanted the authors to be aware of this when they created a page in Xopus. I thought it would be a simple update to the Xopus config.xml file but it turned out not to be. In the end, we added content using CSS instead of using the Xopus config like this:

/* This adds text to Xopus specifically on the first page title*/
#xopus-xsl-root div h1.topic-title:first-of-type .xopus-placeholder:after {
  content: ' (used for generating page URL)';
}

I believe this could do with a little more refinement but it’s worked in all the cases we’ve tested so we are happy.

If you are interested in what didn’t work, keep reading.

One of the limitations of the Xopus placeholder configuration option is that it is not really XPath so it only matches on the element name, attribute name or a class name.  This is documented on the Xopus Use of XPath in configuration FAQ page.

So we first tried:

<x:node match="class('topic/title')" preferElementsOnlyParent="true">
  <x:name xml:lang="en">Title (used to generate URL)</x:name>
  <x:placeholder xml:lang="en">{name}</x:placeholder>
</x:node>

But this added the message ‘ (used to generate URL)’ to the titles on figures, sections and other elements. My next thought was to do add the longer placeholder only to actual descendants of the topic element (and go back and add concept, etc. later) like this:

<x:node match="topic/title" preferElementsOnlyParent="true">
  <x:name xml:lang="en">Title (used to generate URL)</x:name>
  <x:placeholder xml:lang="en">{name}</x:placeholder>
</x:node>
<x:node match="class('topic/title')" preferElementsOnlyParent="true">
  <x:name xml:lang="en">Title</x:name>
  <x:placeholder xml:lang="en">{name}</x:placeholder>
</x:node>

This resulted in not showing the additional text message anywhere because the Xopus config doesn’t use full XPath, as I mentioned earlier so a match of topic/title matches all titles and since class(‘topic/title’) also matches the element and it comes later in the file, that is the version that was used.