Ceton InifiniTV 4 in MythTV 0.24 - Part 3 (Mythbuntu)

In Part 2 of this article, I provided all of the instructions for setting up MythTV 0.24 to use a Ceton InfiniTV 4 cablecard tuner. Today, I'm going to provide a simple step by step that should get a Mythbuntu 11.04 user up and running with Ceton support. However, before continuing, please first read Part 2 to see all of the disclaimers and important info. I'm going to assume you've read it, and thus won't be repeating all of the important details here.

Instructions

mkdir /usr/src/mythtv
cd /usr/src/mythtv

apt-get build-dep mythtv
apt-get source mythtv
apt-get install devscripts

cd mythtv-0.24.0+fixes.20110416.9ba3ece

dch -i

This will take you to edit a file containing a changelog. At the top of the file, it will have already filled in the framework for you to enter your change info. There will be a line with a single asterisk * about 3-4 lines down. Next to the asterisk, just put a brief summery like "applying ron's ceton patch"

For the following, I'm going to assume you've put the patch file (which you can get here) in your home directory. Also, substitute the XXX in the filename with the appropriate version you've downloaded.

cp ~/ceton_mythbuntu_verXXX.patch debian/patches/
patch --dry-run -p1 < debian/patches/ceton_mythbuntu_verXXX.patch

Make sure you got no error from the above. Also please double check the output to make sure it doesn't say anything about applying the patch with fuzz. Although patching with fuzz will work at this step, when you go to rebuild the package, it won't allow fuzz.

pico debian/patches/series

Add ceton_mythbuntu_verXXX.patch at the end of the mythtv section.

debuild -us -uc -iFFmpeg

In the above command -us and -uc are necessary so that we can build the packages even though we aren't setup to sign them. The -iFFmpeg is to tell the packager not to include the FFmpeg stuff in the package. I had to do this because the build process started complaining about the binary file being different. I couldn't find any good explanations on google, but since I didn't modify anything in ffmpeg, we can just leave it out and it will use the old version.


Now at this step you are going to need to install the packages to replace the binary files with your new version. First, I want you to run the following command and make note of the timestamps on the existing files (copy the output to a text editor and hold onto it for a few moments).

ls -l /usr/bin/mythbackend /usr/bin/mythfrontend* /usr/lib/libmythtv-0.24.so* /usr/bin/mythtv-setup*

Now lets install the packages. There are a ton of packages here, and you can try to install them all if you like. However, I only bothered with the following, and everything seemed to work

cd ..
dpkg -i mythtv_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_all.deb
dpkg -i mythtv-common_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb
dpkg -i libmyth-0.24-0_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb
dpkg -i mythtv-backend_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb
dpkg -i mythtv-frontend_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb


Now, let's once again look at the timestamps on the files:

ls -l /usr/bin/mythbackend /usr/bin/mythfrontend* /usr/lib/libmythtv-0.24.so* /usr/bin/mythtv-setup*

Everything should have a new timestamp on it


At this point, all of the Mythbuntu specific stuff should be setup. Now go to Part 2 of this article and continue on from step 8.


...click here to read more!

Ceton InifiniTV 4 in MythTV 0.24 - Part 2

In Part 1 of this article, I discussed my decision to get a Ceton InfiniTV 4 card instead of a HD Homerun Prime, how it didn't initially go as planned, and how I eventually went through the process to write my own code to utilize the card in MythTV 0.24. Now I'd like to share the fruits of my labor...the necessary code which you can compile into MythTV 0.24-fixes to get Ceton support for yourself. In the upcomming Part 3 (hopefully posted tomorrow), I'll post a patch and instructions for Mythbuntu 11.04 users


Standard disclaimers

I'd be absolutely thrilled if you wanted to use my code to get your Ceton card working in MythTV. However, before I unleash all of this on you, I need to be clear about a number of things. I wouldn't want you to not realize what you are getting into and get mad at me if something goes terribly wrong (like you miss a bunch of recordings). So here are a few things you'll need to know before getting started

1) This isn't just a distribution you can download and install, or run apt-get on. We are talking about custom compiled code. You will be downloading the mythtv source code from the git tree, applying some patches, and custom compiling it on your own. If you've never done this before, then I'd prefer that you get comfortable with that process before trying to add in my code. So I'd suggest downloading 0.24-fixes from git (see the instructions at code.mythtv.org), compiling it, installing it, and making sure everything works. If that all works fine, only then should you think about proceeding

2) This isn't official code by any means. This is something I put together by myself, as a stopgap measure until 0.25 is eventually released with real Ceton support. So far, the only person to test this code is me. If you run into problems, the folks on the MythTV forums aren't gonna help you with this one. You'll be depending on me for help.

3) If you have problems with the code, I'll try to help. I take pride in what I do, and I'll be willing to work with you as much as I can to figure out your problems. That said, I've got a full time job and a 1 year old daughter, so don't expect 24 hour support and quick turnaround time. It may take me a while to figure out and get to the bottom of it, but I'll try my best.

4) If you do need help from me, then I'm gonna need help from you. I'm gonna ask you for logs, I'll probably send you some custom code, ask you to run it, and send me back the results. I may do this a number of times.

5) Realizing that this isn't the official software for running the Ceton card in MythTV (nor will it be the official code in 0.25 or ever), you are going to have to expect things to break when you eventually upgrade to 0.25. You're going to have to delete your tuners and repeat the setup process in 0.25 using the officially supported mechanism.

6) When 0.25 comes out, if by some chance it does NOT contain the official support for this card as expected, then this code won't work on 0.25. I may be a bit delayed in upgrading my systems to 0.25, so it may be a little while before I can update the code. That said, I should be able to do it relatively easily, as I already did some preliminary work at getting this working in 0.25 (and had it working in a limited capacity), so I've got a decent part of the code written. And some of the biggest parts (that deal with tuning and getting status info) are actually not tied to myth directly, so I should be able to port them with no problems.


Other important information

If the disclaimers didn't scare you off, then here are few of the little quirks you need to know about:

Importing QAM channels - I haven't written a channel scanner for this card, so if you want to run it in QAM mode without a cablecard installed, you are going to have to do some work to get your channel data setup properly. I can work with you to get this setup if necessary, and I can probably write some perl scripts to help you with the process. However, hopefully nobody is buying this card just for it's QAM support, so hopefully this won't be such an issue. But if you maybe want to test it in QAM mode before upgrading your cable service and ordering a cable card, then we'll have to setup some channels for you

Importing cable card channels - For cable card support, we just use myth's download option and let mythfilldatabase download the data from schedules direct and create the channels. This sets up the channels for the most part, but they are not yet usable by this code. You'll need to run an SQL query to update one of the fields in the database. I'll provide you with instructions below. Also, in the future, if new channels get added to your lineup automatically, they are going to need to be tweaked before they are usable, so you'll need to rerun that query whenever your lineup changes. In the future, I'll try to figure out the most appropriate way to automate this so you don't have to worry about it, but for now it's something you'll need to be aware of

Live TV channel changing - Typically this works very well...about 3 to 4 seconds per channel change. However, occasionally a tuning request may fail and the Ceton doesn't properly tune the channel. The good news is that I've got code to detect this condition (as least for every way I've experienced this or I anticipate it could happen) and re-initiate the channel change request automatically. However, when it does happen, it will take 5 seconds for the code to kick in, and then another few seconds for the channel change to occur. When this happens, you'll be staring at a black screen for several seconds. Back on the good news side, I've only had this happen to me once in my testing, so I don't expect it will be very common).

Startup error condition - I've started and stopped the mythtv-backend service hundreds of times almost entirely without issue. Once it's running, the code works great. However, one time I rebooted my computer and when it came up, it didn't initialize properly. As a result, the card wasn't usable for recording until I stopped and restarted mythtv-backend. When it happened, it was logging very obvious info to the log file, so this will be easy for you to detect. Sometime next week (after my daughter's 1st birthday party) I intend to take a better look at this, rebooting my system several times to see if I can recreate it. I'm pretty sure it was just a matter of mythtv-backend starting up before the Ceton card was ready. I've modified my card to get its IP through DHCP instead of using the static 192.168.200.1 that it has by default, so this may have been the cause of the problem.


One final disclaimer

It's important to know that cablecard support is going to depend on your cable provider. Unfortunately, cable labs has only certified Windows Media Center to support certain modes of DRM. This means in MythTV, you can only watch channels that are marked as Copy Freely, and it's up to your cable provider to decide this. If they mark a channel as Copy Once or Copy Never, you are out of luck and the only thing you can possibly do is complain to them (for all the good it will probably do). You can probably check with others on the MythTV forum to try and figure out what channels are marked Copy Freely for you (either someone that lives in your area may know, or someone may be able to show you how to retrieve that info from your cable box).

In general, WOW (wide open west) has said that they mark everything except premium channels (HBO, showtime, etc) and PPV as Copy Freely. This should hold true in all WOW markets. Comcast has the exact same arrangement in most of their markets, but I believe there are some places here and there that are configured differently. With other cable providers, results may vary.


Are you still here? OK, let's get this going

If I haven't scared you off with the disclaimers and quirks, then I guess you are serious about this and it's time to get to work. So here's what you need to do

1) Download myth 0.24-fixes and make sure you can compile it all fine.

2) Download my ceton patch for 0.24-fixes.

3) cd to the mythtv/mythtv folder of the source code. This is the folder that contains the ./configure script

4) Clean up any previously compiled code by running:
make dist-clean

5) Test the patch first by running the following command:
patch --dry-run -p2 < /path/to/ceton_verXXX.patch

6) If the above test was successful and no failures occurred, then apply the patches by running:
patch -p2 < /path/to/ceton_verXXX.patch

7) Run ./configure, compile everything, and install it

8) Start mythtv-setup and add a Ceton tuner. The default IP address (if you haven't changed it) is 192.168.200.1, and the tuners are numbered 1 to 4. Repeat this process for all 4 tuners (or as many as you want to setup).

9) Create a brand new data source exclusively for the Ceton tuners (and don't let any other non-ceton tuners use it).

10) Click the button to fetch channel info (I don't recall the exact wording, but it's the next to the scan button in the Input Connections page

11) If you have a cablecard installed in your Ceton InfiniTV, perform step 11-A and then go to step 12. If you DO NOT have a cablecard installed (ie: you want to operate the card in QAM mode) perform step 11-B and then go to step 12.

11-A) Note: this step is no longer needed as of patch ver 008 (1/7/2012) Do this step ONLY if you are running the Ceton in CableCard mode (ie: you have a cablecard installed):
Download the channel mapping utility. Unzip/untar it and edit the perl script to adjust the config settings at the top of the file. You'll want to verify (and change when necessary) the path to wget, the ip address of your Ceton InfiniTV 4 card, and the mysql info (host/db/user/password). Then simply run the perl script to have it update the channel config.

11-B) Do this step ONLY if you are running the Ceton in QAM mode (ie: you do NOT have a cablecard installed):
Download the QAM channel mapping utility. Unzip/untar it and edit the perl script to adjust the config settings at the top of the file. You'll want to verify (and change when necessary) the path to wget, the ip address of your Ceton InfiniTV 4 card, and the mysql info (host/db/user/password). Then run the perl script to have it update the channel config.

Note: One limitation of this script is that it cannot determine which channels are available in unencrypted QAM. It will simply look at every channel in the videosource that you've assigned to the card in mythtv-setup, and then update the configuration of that channel accordingly. Therefore, in order to eliminate the encrypted channels so that myth doesn't have to tune them, you will need to delete those extra channels or mark them as not visible (either in mythtv-setup or using mythweb).

12) Startup the backend and the front end, and you should be good to go if I haven't forgot anything.


...click here to read more!

Getting iMON 0038 LCD working with LCDproc

Yesterday I discussed how to get the iMON display working in LIRC. The next step after that is to get the LCD display working. The most popular program for controlling the LCD is probably LCDproc. As it turns out, once you've got LIRC running the LCD properly, it's relatively easy to get LCDproc going too.

Once again, these instructions are specific to the 0038 version of the iMON LCD. Other versions may need slightly different instruction. Check over at the codeka.com forums for details.


Step 1 - Making sure your LIRC installation is good

LCDproc relies on the lirc_imon driver that is part of LIRC. If that isn't properly configured and installed, you have little hope of getting LCDproc going. Well, I've heard it's possible to have LCDproc control the LCD directly without LIRC, but I haven't tried it so I don't know if it's true, and even if you were to do so you'd lose its IR and front panel button capabilities. For this reason, LIRC is really the right way to go.

To test if your LIRC installation is correct, you can run the following command:

perl -e 'print pack "H*", "80000000091e0088"' > /dev/lcd0

When you run this command you should see the LCD clear itself and then display a clock with the time "AM 09:30" (in an ugly font, where the 4's look like 9's, and are only different by a single pixel, but I digress). If that's what you get, then lirc_imon is configured fine. You can proceed to step 2 after resetting the LCD with the following command:

perl -e 'print pack "H*", "4000000000000088"' > /dev/lcd0


If you weren't so lucky, then you might have a problem. First thing you want to do is make sure the driver is loaded:

lsmod | grep lirc_imon

You should get back a few lines of text that contain the lirc_imon driver and some other drivers (lirc_dev, usbcore, etc). If you get back nothing, try loading the driver manually:

modprobe lirc_imon

Then try running the command to set the clock again. If it works now, you may need to find a way to load the lirc_imon driver automatically (possibly by putting lirc_imon in /etc/modules). After that, you can proceed to step 2 (turn off the clock, first).

If it STILL isn't working, go back again and test whether the iMONs IR and/or front panel buttons are still working with LIRC. If not, somehow you don't have LIRC built correctly, with the correct patches, so you need to fix that first. Check out yesterday's post on that topic. However, if it does work, then my best guess is that LIRC thinks you have the VFD rather than the LCD and built the lirc_imon module for that device.

If you configured LIRC for only a single device (the Soundgraph iMON IR/LCD), then it should have handled everything for you. However, if you are like me, and have a separate IR receiver that you are using, and thus need to install LIRC with multiple drivers, you probably configured it something like:

./configure --with-driver=all

As I covered in an update to my post on setting up LIRC with multiple devices, the --with-driver=all option will configure it to use the VFD rather than the LCD. You will need to change config.h so that the line:
/* #undef LIRC_IMON_LCD */

becomes:
#define LIRC_IMON_LCD 1

and then recompile and reinstall LIRC. Then unload and reload the lirc_imon driver. Then once again try the perl command to set the clock. It should now work (once again, be sure to turn off the clock before proceeding). If you still have problems...I have no clue. You are on your own. Try posting over at the codeka.com forums.

Step 2 - Configuring LCDproc

This is actually a much simpler process than it was configuring lirc. Once again, you will want to follow the basic instructions post by Dean at the codeka.com forums. However, you will want to make the following changes.

1) Instead of using dean's lcdproc-0.5.2-imonlcd-0.3.patch patch, download my slightly modified version. I've made a few tweaks where he forgot to set an icon flag or set the wrong icon flag.

2) After running automake but before running configure, you will want to download my slightly modified version of madCoder's patch for the 0038 model, and apply it by running

patch -p1 <../lcdproc-imon_0038-v2.patch

3) When you get to the part about modifying the /usr/local/etc/LCDd.conf file, rather than changing the file manually, you might want to start by downloading my patch for the conf file and applying it with:

patch /usr/local/etc/LCDd.conf ../LCDd.conf.patch

This saves you from the error prone process of modifying it manually, especially since it's easy to leave off the leading or trailing slash on the DriverPath setting (in fact, deans instructions even left off the trailing slash).

4) Dean mentions changing the RENDER_FREQ from 8 to 1. You might want to experiment with other values in between (2 to 4). While I found 8 to be too fast, 1 update per second was too slow for my tastes. If you decide to play around with it, you will need to recompile each time (it would be better to move this to the config file, but I didn't find it important enough to waste the effort on). After making a change, you do NOT need to rerun configure or any of the previous commands. Just make and make install.

Step 3 - Testing LCDproc

This part is quite easy. Just run the following command:

LCDd -f -r 4

The display should light up with some text from LCDproc. If not...well, I really don't know what could have went wrong. Just make sure you carefully followed all of the instructions in the proper order (are you sure you ran the command to turn off the clock in step 1)?


Thats it!

See, it was quite easy. In fact, if you take a look at my instructions, you'll see that there was more detail involved with debugging your lirc_imon setup than there actually was getting LCDproc going.

You can now go on to configure your other applications to interface with LCDproc. Sorry, I have no advice on that part yet. I'm actually working on my own interface program at the moment (it seems I've got more things going on than I have time to write about). I'm sure I'll talk about that at some point.


...click here to read more!

Getting iMON 0038 LCD working with LIRC

As I mentioned before, getting the iMON display working was a bit troublesome. However, I managed to get it all working. Since it was so problematic, I'd like to share details of how I did it.

Before continuing on, I have to give huge thank you to Dean Harding for setting up the codeka.com forums and for all the work he did with the iMON. Also, thanks to many of the people in those forums who provided followup info and helped troubleshoot/patch things to work with newer versions of the hardware (especially madCoder for his patch for the 0038 model).

Also, I just want to say that, while the following instructions may seem a bit long, it really doesn't take that much work. A lot of this will just be verbose text. I'm trying to provide as thorough instructions as possible and describe whats going on, so that if you run into problems (ex: your configuration is a bit different), hopefully you will understand what needs to be done and figure out how to work around it.


Step 1 - Determine which version of the iMON you have

First, you need to get the ID of your iMON device. Run the lsusb command and look for a line that says Soundgraph. Before that will be the ID string. In my case, it's 15c2:0038, with the 15c2 being the vendor ID and the 0038 the product ID. If this is the version you have, then the rest of the instructions on this page should hopefully get you up and running.

If you have the 15c2:ffdc version, you have the original, and you can probably just follow Deans instructions from codeka.com. If you have another version number, then that means either Soundgraph has changed the device again, or you don't actually have the LCD (perhaps you have the VFD, which is a very different device). In either case, you can have a look around at the codeka.com forums and see someone has figured it out.


Step 2 - Determine if usbhid is controlling the iMON

Originally, the instruction I found for setting up the iMON display didn't work. I followed them to the letter, but had no luck. Well, as it turns out, it seems newer versions of the kernel (I'm running Debian 2.6.24) have support for the iMON in the usbhid driver. That means when the usbhid driver starts, it takes control of the iMON. Later, when the lirc_imon module loads, it's unable to take over the device.

So the first step necessary in setting up the iMON is to make sure the usbhid driver hasn't taken control of it. Run "cat /proc/bus/usb/devices". The output of this will be 1 block of info for each USB device in on the system. You want to find the block(s) that has Vendor=152c and ProdID=0038. Then look down a few lines further in the block and look for the line that contains "Driver=". That will tell you what driver is loaded for that device. If the driver is "usbhid", you need to continue on to disable it. If it's "(none)", you can just skip step 3. If you see lirc_imon, then you already have the proper driver loaded. Anything else and you are on your own.

---------------------------------------------------
Edit: It has come to my attention that /proc/bus/usb/devices doesn't exist on all systems. Apparently not every distribution has usbfs mounted. You can run the command

mount -t usbfs none /proc/bus/usb

to mount it, and then /proc/bus/usb/devices should exist.
---------------------------------------------------

Step 3 - Prevent usbhid from controlling the iMON

Assuming the usbhid driver has been loaded, you now need to disable that. You probably don't want to completely disable the usbhid driver, because that can prevent other devices from working properly (such as usb keyboards and mice). Instead, you want to tell the driver to ignore your particular device. The following instruction work for the 2.6.24 kernel under Debian.

1) Edit /etc/modprobe.d/usbhid (create it if it doesn't exist) and add the following line. The first hex code is the vendor ID, the second is the product ID, and the 0x0004 means ignore this device.

options usbhid quirks=0x15c2:0x0038:0x0004

2) Run the command: depmod -ae
3) You need to rebuild your initrd. If you are running a typical installation, you can do this by running:

update-initramfs -u


In my case, I'm doing a diskless boot over NFS, so I had to do it slightly different. Edit /etc/initramfs-tools/initramfs.conf and make sure BOOT is set to nfs. The run "mkinitramfs -o initrd.img.netboot". Finally, copy the new initrd.img.netboot over to the appropriate location on the tftp boot server (and rename it if you are using a different filename in your setup).

Once this is all done, a reboot should use the new settings and stop loading usbhid for your iMON. Run the "cat /proc/bus/usb/devices" once again. This time, the driver should be listed as (none). If it is still usbhid, do NOT continue on with these instruction until you've figured out how to deal with it for your particular distribution.


Step 4 - Installing LIRC

The basic installation instruction come from this post in the codeka.com forums. The patches to deal with the 0038 model come courtesy of this post by madCoder. In addition, I've made a few small changes to the patch to deal with the iMON pad remote and the front panel buttons on the Thermaltake DH-101 case. Other cases with front panel buttons likely require this same patch. If you don't have this case, I don't really see any harm in using my patch anyway.

You can get detailed info from the above 2 posts, but I'll summarize it below to help you keep things in order between both posts. Also, I'll provide links to actual patch files you can download, because copying and pasting the patch files from the forum are likely to get you "malformed patch" errors because of formatting issues.

Also, before beginning, you'll want to make sure you don't already have an installation of LIRC by running "apt-get remove lirc"

1) Make sure you have the prerequisites for LIRC installed as listed on this page. In my case, I was able to do that through apt-get:

apt-get install libtool automake1.9 autoconf

2) Download the current version of LIRC from CVS.
3)

UPDATE:

With the latest version of lirc (as of sometime in early 2009) all the necessary patches have been included into the CVS version of lirc. It is now possible to get full iMon support without applying any patches to the CVS branch (at least until SoundGraph decides to create a new iMon device with different control codes :)

Anyway, I'm crossing out the info that is no longer needed (but I'm leaving it here in case anyone has any use for it)

The 0038 version of the iMON hardware requires you to patch the LIRC code first. Download this patch and then install it by running the following command from within your LIRC directory:

patch -p1 < lirc-imon_0038-v2.patch

UPDATE:

The code in CVS has changed slightly, and a critical part of the patch no longer applies automatically. Until I get a chance to update the patch, you will need to do the following AFTER applying the patch:

1. Edit drivers/lirc_imon/lirc_imon.c


2. Find this line:
   
   { USB_DEVICE(0x15c2, 0xffdc) },


3. Add this line after it:
   
   { USB_DEVICE(0x15c2, 0x0038) }, /* IR & LCD */

Then you can continue with the next step

UPDATE 2:

It looks like cvs has been updated to handle the new version of the imon. However, from what I've heard, it appears that the patch applied to cvs wasn't as comprehensive as the patch I applied, and some of the buttons on the pad remote as well as some of the case front panel buttons might not work.

I haven't yet had a chance to look at the new version to see what it takes to get it going. In the mean time, if you would like to try with the old version from CVS, you can download the version I used from:
http://ronfrazier.net/mythtv/downloads/lirc-cvs.tar.gzip

4) Run autogen.sh and setup.sh. This will give you the configuration dialog. Choose the following sequence:

Driver Configuration -> USB Devices -> Soundgraph iMON IR/LCD

Save configuration & run configure

5) Run make, make install, and then modprobe lirc_imon.

With the 0038 version, you should have devices setup for /dev/lcd0, /dev/lcd1, /dev/lirc0, and /dev/lirc1. In addition, you are also going to have a device for /dev/lirc, but thats not really important. The actual devices we need are lirc0 and lirc1.

Notice to Ubuntu users: I received an email from Sascha Zucca who said that after following these instructions, he did not get all of the appropriate devices showing up under /dev. After working through the problem with him, he discovered that Ubuntu was loading its modules from a different directory than the lirc installer was putting the compiled files in. As a result, even after installing the new modules, lirc was loading the old version without the iMON fixes. Here is how he told me he fixed it:

i had to
mv /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_imon/lirc_imon.ko{,.OLD}
and
ln -s /lib/modules/2.6.24-16-generic/misc/lirc_imon.ko /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_imon/

I've since received a half dozen emails from other users who encountered the same problem. Performing the same fix worked for each of them (taking into account that the path will be slightly different for different versions of Ubuntu). Also, take note of the line wrapping. Those are actually only 2 commands.


FYI - Why are there 2 LIRC devices?

The iMON pad remote acts like a mouse/keyboard in addition to a remote. In the old version, it was my understanding that this was all handled through one LIRC device. However, the 0038 version splits it into 2 devices. All of the mouse/keyboard related keys come through the lirc0 device (the directional pad, left click, enter, the number button, ect....however NOT including the Mouse/Keyboard toggle button). Everything else comes through the lirc1 device (play, eject, colored buttons, zoom, etc...plus the Mouse/Keyboard toggle button). Finally, if you have front panel button, they will also come through the lirc1 device (at least they do on the DH-101).

If you have no plans to use the included remote, and plan to use a separate LIRC receiver with a different remote, you might think you can just skip the lirc0 part and use lirc1 for the front panel buttons. However, that may not work. Even if you don't use the iMON's IR receiver, it will still pick up some of the IR signals from certain remotes. When it does you will run into a problem. The iMON buffers up the inputs from each device separately, but maintains the sequence of events between the 2 buffers. If you only run the lirc1 device, everything will work fine until the iMON picks up an IR signal that it decides to put in the lirc0 buffer. When that happens, the lirc1 buffer will appear to have locked up and will not generate any more events. In reality, it's just maintaining the event sequence, and the next event is waiting to be removed from the lirc0 device. Until you do that, you will see no more events coming from the lirc1 device.

Now, on to the testing.


Step 5 - Testing and using LIRC

First you are going to need a lircd.conf file. For the pad remote, you can download this file. For the Thermaltake DH-101, you can download this file. If you want to use them both, you can just combine them into the same file. Whichever file you use (or both files combined), you will need to put that file in /etc/lircd.conf.

Once lircd.conf is in place, you can do the actual testing of LIRC. You need to get both devices up and running. The way to do this it to run 2 copies of lircd. The first one needs to listen to a socket and output its events there. The second one connects to the remote socket, gets events from there, and combines those with its own events. Each of the 2 processes will be listening to a different iMON device. Run the following 2 commands:

/usr/local/sbin/lircd --driver=default --device=/dev/lirc0 --pidfile=/var/run/lirc0.pid --listen=8765
/usr/local/sbin/lircd --driver=default --device=/dev/lirc1 --pidfile=/var/run/lirc1.pid --output=/dev/lircd --connect=localhost:8765

Now you can run the irw program and start pressing buttons on the remote and/or front panel, and you should see the event output on the screen. If you have a different case and don't get output from the front panel buttons, you will need to record a custom configuration file for it using irrecord.

First, you need to kill off the lircd processes (kill `pidof lircd`). Then you need to run irrecrd, but you need to point it at the right LIRC device:

irrecord --device=/dev/lirc1 frontpanel-lircd.conf

Follow the instructions to create your config file. When it's done, you will want to add the contents of frontpanel-lircd.conf to your /etc/lircd.conf file. Then restart both lircd processes and try irw again. Everything should be fine (hopefully)



Congratulations

If you made it this far, then you must have got everything working. Now you probably want to do something useful with the LCD. The most common program to control it is LCDproc. I've covered getting LCDproc setup with the iMON in this post.

If you have any questions or problems, be sure to leave a post in the comments below, or email me (you can find my email address through the "My MythTV Patches & Add-ons" link at the top of the right hand column). Or you can post about it in the iMON forum over at codeka.com

...click here to read more!

Enabling Quality of Service for the HDHomeRun

A few times recently, I've had problems where I was generating a large amount of bandwidth at the same time mythtv was recording a few HD programs from my HDHomeRun. The HDHomeRun transmits its data over the network via UDP instead of TCP, so when it ends up on the losing end of an oversaturated network, it's packets just get dropped and the data is never retransmitted. The end result is a lot of packet loss, and the recording will be full of skips and other corruption. Having damaged recordings is an unacceptable situation, and was something that I needed to resolve. Simply scheduling any heavy network activity around the recording schedule was not acceptable, either. I needed a better solution.


Upgrading the network

As it just so happens, I also had another problem at the same time. My home network had grown considerably, and I was now out of ports on my router and switch. I needed to add another switch to the network. In looking around, I found the D-Link DGS-2208 and it seemed to be both inexpensive and had very good reviews. It also had something else I found interesting...support for 802.1p Quality of Service delivery.


QoS on the HDHomeRun

When I saw 802.1p support in the feature list, something clicked in my mind. I remember reading once that the HDHomeRun could enable Quality of Service flagging on its packets. I figured that would be a great feature to enable, to ensure that the HDHomeRun got priority over other devices when the network starts getting saturated.

I figured it would be as simple as changing a setting in the HDHomeRun, and all data would be streamed with a QoS flag. Do that once, and it would be transparent to everything else. I promptly opened up a support ticket with Silicon Dust to find out how to do it. I got a prompt response back indicating how it could be done.

As I expected, the solution was quite simple. Simply pass an extra flag to hdhomerun_config when you tell it where to stream the data to. Instead of

hdhomerun_config FFFFFFFF set /tuner0/target "udp://192.168.0.10:5555"

it would be

hdhomerun_config FFFFFFFF set /tuner0/target "udp://192.168.0.10:5555 qos"

(note...the quotes in the parameter list are important so that the qos string doesn't get treated as a separate parmaeter).

I gave it a try and it worked. That was a very easy solution. However, there was a slight problem here. The way this was enabled meant that a patch would need to be applied to mythtv to enable this to happen each time it opened up the stream.


Patching MythTV

The patch to make this happen wasn't very difficult. There were only a few tiny changes that needed to take place. A single line of code could be used to accomplish this, except for the fact that 802.1p tagging is applied as part of the 802.1q standard for virtual LANs. This meant in order to QoS tag the packet, the packet had to be destined for a VLAN (the HDHomeRun uses VLAN 0).

By default, linux will ignore packets that are received for a VLAN unless it has been explicitly configured to do otherwise. This means that a quick and dirty patch to mythtv would break HDHomeRun functionality for anyone who doesn't have VLANs configured, as the packets from the HDHomeRun would never be handled. Obviously, this needed to be a feature that could be toggled on/off in the capture card setup of mythtv-setup. This made the patch just a tiny bit more complex, because it requires a schema change to the database so you have somewhere to store this flag. Regardless, I was quickly able to code up the patch. I'll release it soon, but I first need to run a few things by the mythtv-dev mailing list.


Enabling VLAN support under Debian

As I mentioned, linux ignores packets destined for VLANs unless explicitly configured to do otherwise. It turns out that configuring Debian to handle a VLAN wasn't all that difficult.

The first step was to install the vlan package ( apt-get install vlan ). Once that was done, you needed load the 8021q module ( modprobe 8021q ). Finally, you just needed to tell linux to accept packets for VLAN 0 on your adapter ( vconfig add eth0 0 ). Your network is now accepting VLAN 0 packets. This created an entry for eth0.0 under /proc/net/vlan/. If you view its contents ( cat /proc/net/vlan/eth0.0 ), it will give you network usage statistics for that VLAN.

That last thing you need to do is make sure your VLAN configuration survives a reboot. Simply create a script called /etc/init.d/vlan that runs your modprobe and vconfig commands. This script can then be run automatically when your eth0 interface comes up by adding the line "up /etc/init.d/vlan" to your /etc/network/interfaces file in the section for "iface eth0".

...click here to read more!

Patch to configure mythmusic exit action

I released a tiny new patch today. This patch is for the mythmusic plugin. It allows you to configure the action you want mythtv to take when exiting the mythmusic plugin while music is playing back.

Currently, when you are use the mythmusic pluging and are playing some music, if you try to exit the plugin (perhaps to do other things in myth), you get prompted whether you want to stop playback or contiue playback. For myself, if I didn't want the music to keep playing, I'd hit the stop key first, so getting prompted every time gets a bit annoying. In addition, if I hit a jumppoint key (perhaps to jump into the photo gallery), music playback stops instantly with no option to exit.

This patch gives you the option to configure the action to take when exiting. By default, it maintains the current behavior. However, you can also set it to always stop playing or to always continue playing. In either case, you can exit myth without being prompted. In addition, if you set it to always continue playing, it will do so even if you exit the plugin by using a jumppoint.

This patch will work with either myth 0.21-fixes or trunk.

You can download the patch file from Ticket #5008.

...click here to read more!