So, you've followed the instructions and are still having problems? Not to worry. Below I have compiled some useful tricks which you can use to attempt to figure out what is going wrong. I will add to these as I come across new ones. Also, if you have any which you would like to add, feel free to shoot me an email with suggestions. For ease of use, the table below shows the colors used to highlight information that you will need to enter as command line input, receive as command line output, or enter into a configuration or shell file. This will hopefully make it easier to distinguish between what different commands do.
| Command line input | . |
| Command line output | . |
| Entry for a file | . |
Installing Kernel Source and compiling LIRC for more than 2 devices
For those who either don't want to solder on an LED, or who bought an IR Blaster and don't want to risk ruining it, there is
a second method. If you have a digital camera, aim it at the IR Transmitter, and watch on the camera's little LCD
screen to see live action. The only way this works is by looking on the LCD screen of the camera; the view finder will not work.
You *should* be able to see whether or not the IR Blaster is transmitting
by running the change_chan.sh script. You can try this with a normal remote by aiming its IR transmitter
at the camera and pushing buttons on it while looking at the camera's LCD. If you see lights coming from
your IR Blaster, you know it is working, but you probably just have the wrong config. If you don't see lights,
it doesn't necessarily mean it's not working, but could indicate a setup problem (my camera never picked up light from my
IR Blaster, though it would pick up light from all my other remotes). Many people have reported success in using this method.
Also, you may be getting interference from other sources of light, especially fluorescent bulbs. To help prevent this, you can cover the
IR Blaster with aluminum foil. ONLY COVER THE SIDES OF THE IR BLASTER AND THE PART FACING AWAY FROM THE CABLE BOX. If
you put foil between the IR Blaster and the cable box's IR Receiver, it will block the signals from getting through. An added bonus to
covering the IR Blaster with foil is that it keeps your remote control from interfering with channel changing operations. I have a bad
habit of trying to adjust the volume right after I change channels. Since the cable box takes a couple seconds to change, this
causes dropped digits. With the aluminum foil, I haven't had this happen once.
When all else fails, you can use the irrecord module that comes with LIRC. Using irrecord requires that you have a remote that can currently control your cable/satellite box, as this is what irrecord will use to learn the signals. Honestly, I have messed with irrecord very little. However, it doesn't appear to be too difficult. I would do it in a dark room (light can interfere with your IR Receiver's ability to properly grab the IR signals), and sit within 2 feet of your IR Receiver. To use irrecord, open a command prompt, su to your root user, and type the following:
You'll get a message that looks similar to the following as output:
The number 2561 could be any number. It is just whatever process ID happens to be using the /dev/lirc device. You will need to kill that process. To do so, type:
Your /dev/lirc device is now freed up. You now need to launch irrecord. To do so, type the following:
The /home/mythtv/remoterec.conf file is what will be generated from the output of your remote control. You can put this wherever you'd like while you're recording it. Follow the onscreen prompts. You'll first have to hold down a single key on your remote for a LONG time. You'll see a series of dots running accross the command prompt while you do so. After that's done, you'll have to enter in the name for each key, hit enter, and IMMEDIATELY hit press the key on the remote. So, to enter the "Stop" key on the remote, you'd type "MENU" (without the quotes), press enter on the keyboard, then immediately aim your remote at your IR Receiver and hit the menu button on your remote. Repeat this process for any key on the remote that you will need your IR Blaster to send to your cable/satellite box (all the number keys, the chan+, chan-, select and direction arrows are good ones to have).
When you're done with all the remote keys you want to record, press enter (without assigning a name to a key). It will then ask you to hit a key on your remote over and over again very quickly to test for a toggle switch. I have been unable to get this to work at all. Give it a go. If after 2 or so minutes of trying there is no response from the program, you can just hit Ctrl+C on the keyboard to end the program. At this point, your file should be generated. Put its contents into your /etc/lircd.conf file as Step 2 explains, and then follow the guide and test it. You may need to redo it several times before it gets your keys reliably. I'd keep a copy of the file from each time you record it, and notice the differences within them. This should help you discover which keys are being reliably picked up (they'll be the same time after time) and which ones aren't.
As I said, I have messed with irrecord very little. You can find more information on this on the LIRC documentation page, the
LIRC mailing list archives, or the
MythTV mailing list archives.
Here's what I got for output:
/dev/lircd and /dev/lircd1 represent your two devices.
The "61" and "1" correspond to the major and minor numbers in your modules.conf file for
whatever particular module you are creating a socket for. A reboot will wipe this setting
clean, so if you find it fixes your problem, be sure to add the command to your /etc/rc.d/rc.local
file so it will be applied any time you reboot.
This should return a pretty substantial listing of what all drivers are built in.
Well, there's good news and bad news on this. The good news is it means your LIRC is working and the modules are all properly loading. The bad news is that I'm still not completely sure of the cause of this issue, or how to address it. Even more oddly is it seems to happen to people using DISH Network almost exclusively. Could just be a coincidence...
Anyway, there are a number of steps which could fix the problem. Please, if you have this issue, and either one of the steps below or one of your own creation solves this problem, e-mail me and let me know.
1) Make sure that mythtvsetup is properly pointed towards your script. Your script should be in the /usr/local/bin directory (check
to see that it is there). After that, make sure you properly typed in the path in mythtvsetup. It should be:
/usr/local/bin/change_chan.sh
2) In mythtvsetup, there is a channel editor there. Make sure that either channel frequency or channel number is loaded for each channel. Others have reported issues of this in the MythTV mailing list archives. See here, here and here.
3) It's possible the source ID for your card's input and channel are out of whack for some reason. See this post on how to fix this.
4) See what happens when your run the change_chan.sh script from the command line as both root, and your non-root mythtv user. If one can change it but not the other, there is a permissions issue that you need to address. Perhaps the directory where you have the change_chan.sh script is set for root only?
5) Try creating an alternate script and loading it into mythtvsetup's "External Channel Change command." The idea of doing this is to actually see whether or not MythTV is even attempting to call the script. I'd make a script in my /usr/local/bin directory called test_script.sh and put this in it:
Make sure you run "chmod 755" on this new script you've created to make it executable. Point MythTV's external channel change command towards this script. THEN REBOOT. After that, load up the front end and go to "Watch TV." Attempt to do a few channel changes. Exit the frontend, and open up the log that should have been created from your new channel changing script. It will be in your home directory, and it's called "test_script_output.log". If it's there, open it, and you will see a timestamp that should have been issued every time you did a channel change. If the log is not there, then MythTV is NOT calling your script. This could be a permissions issue, but is likely indicative of a bigger problem with MythTV. I currently have no suggestion on how to resolve this, other than reinstalling MythTV or rebuilding your MythBox from scratch. If you figure it out, please e-mail me your solution.
6) Check your logs (/var/log/messages and /var/log/messages/mythtv/mythbackend.log) for a message that looks similar to the one below:
2005-01-31 19:24:20 Channel::Open(): Can't open: /dev/video0
/dev/video0: No such file or directory
Couldn't find input: Composite 4 on card
It might say "Tuner0" or "SVideo0", all depending on what input you're using. If you have this message, MythTV thinks
it can't access your card for some reason. I am not sure what the cause or solution to this is. Again
e-mail me or the MythTV list and we'll try to help you through it.
