Jan
15
Filed Under (Random) by mark on 15-01-2006

News

Latest: added a version that compiles with 2.6.27 kernels.
Latest: if you are packaging this, see the note at the bottom as to why I don’t provide a simple patch.
Latest: added an updated version that compiles with 2.6.24 kernels, tested against 2.6.23.12
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)

HOWTO

  1. This is not for the MCE version of the PVR-150. This includes a USB unit which does not work the same way as the normal PVR-150, use standard lirc (and lirc_mceusb) for that.
  2. Use a recent kernel (note: the ivtv drivers have been part of the mainline kernel for a good number of revisions so no external drivers are required — sorry, I don’t know off hand which revision they were merged in), or for older kernels install ivtv-0.4.2+ (from this page). Earlier versions of ivtv _are not supported_.
  3. Get the pre-patched lirc 0.8.5-CVS-pvr150 tarball. There are also earlier versions that can be found here, should you want them. The previous revision may be required for kernels < 2.6.27 (as it is untested on lower revisions -- in theory it should work)
  4. You need the dialog package installed to use the lirc configuration GUI, so install that (apt-get install dialog, yum install dialog, whatever is appropriate for your distribution).
  5. Unpack the patched lirc:

    cd /usr/src
    tar xfj lirc-0.8.3-CVS-pvr150-2.tar.bz2
    cd lirc-0.8.3-CVS-pvr150-2
    ./setup.sh

    Choose:
    TV card
    i – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
    Save configuration & run configure

    then:

    make && make install.

  6. IR blaster only: Now you need the ‘firmware’. This is a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.

    Note that the entire firmware is kept in memory (currently 300K) so this makes the driver quite large. (I have no plans to sort this out, memory is cheap).

  7. Check everything is working so far:

    modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    Check the syslog output. This should report something like:

    Aug 28 02:09:11 soapbox kernel: lirc_pvr150: chip found with RX and TX
    Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR RX, ok]
    Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX, ok]
    Aug 28 02:09:11 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Aug 28 02:09:11 soapbox udev[5221]: creating device node ‘/dev/lirc0′
    Aug 28 02:09:11 soapbox kernel: lirc_pvr150: firmware of size 302355 loaded
    Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 743 codesets loaded
    Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.

  8. You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start with this configuration file which contains key definitions for everything in the database. Do not use other lirc configuration files for specific STBs — these simply will not work. The IR chip is only capable of sending those codes which are in the database.
  9. Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run ls -l /dev/lirc*. If you don’t see a /dev/lirc0 or similar, then try mknod /dev/lirc0 c 61 0 if the steps below fail.

    modprobe lirc_dev && modprobe lirc_pvr150 debug=1
    lircd --device=/dev/lirc0

  10. You can now check if the remote is working using irw. Run this, and press buttons on the remote. You should see some output like

    0000000000001795 00 Down Hauppauge_350.

  11. Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have send_power_new, a script that just sends the power command in every single codeset. You may find your codeset number listed here if you are lucky.

    Firstly, check that you are seeing the IR blaster blink. If you don’t have blinking lights at this stage, your cable probably isn’t in the card properly (try wiggling it around), or it may be broken.

    Next you need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position it correctly — it has a very short range (a few cm) and took me a couple of goes to get right. The best way to do this is to find the IR demodulator on the box — easiest with a torch. Note that this is _not_ the light that comes on when you press a button on the remote, they tend to look like this.

    If you can’t get this to work, please try and check it against the Windows driver if possible. If your device will work with the windows driver but not my driver, then it’s a driver bug that I should be able to fix. If it does not work with the Windows driver either then your only options are to use a different IR blaster or bug hauppauge until they add support for the box you are trying to control. At that point, I can update my
    database too.

  12. Once you know which codeset you want you can go and delete all of the rest from lircd.conf. They are named “XXX_key” so should be pretty easy to find. I also gave the keys standard names (0-9).
  13. To get mythtv to work, configure a channel change script for your device. There’s one here that should work out of the box if you
    rename the number keys.
  14. If you’re happy, you can always send me beer money. If not, add comments at the bottom :)

That’s it, good luck!

Packaging

The lirc distribution tarball is generated using `make dist-bzip2` which uses the gnu autotools to generate a configure script, and Makefile.in, etc. The contents of these generated files depends very much on the version of autotools that is installed; this varies from distribution to distribution. I don’t have the same auto* as the lirc maintainers, so producing a patch file against a distribution tarball makes a patch bigger than the original source archive. Hence I don’t bother; I just make a new dist bzip2 and drop it here.

I maintain the code by importing a current lirc CVS into a subversion repository hosted on this server. I tag each lirc import, generate a diff from the previous lirc import and apply it to my source tree, then port any fixes from lirc_i2c.c to lirc_pvr150.c, test, and generate a new .tar.bz2. To get the source tree you can do:

svn co http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc lirc

and you can get the changes I made to the CVS revision of lirc with:

svn diff http://svn.blushingpenguin.com/svn/vendor/lirc/current http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc


366 Responses to “LIRC PVR-150 IR blaster support, version 3”

  1. 1
    mikey utah Says:

    Hi Mark,
    Good show. Bought the PVR-150 card two days ago, and the ivtv update (which got the TV portion of the card working) happened yesterday, thankfully. Now having probs with the remote. Have followed your instructions to the letter. Here’s what I get in the dmesg:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found

    Any thoughts? I’m running a 2.5.15-rc6 kernel on Debian sarge, if that makes a difference.

    Grazie!

  2. 2
    mark Says:

    It can’t find the chip. Can you try a cold reboot and let me know what happens? (Turn off, unplug power cord, press power button to drain residual power, wait for a bit, plug in power cord and turn on).

  3. 3
    mikey utah Says:

    Seemingly no change.

  4. 4
    Mark Roy Says:

    Hello,

    I was trying to get patched lirc last night (the one with lirc version 0.7.2) and then I found this. Anywho, I am now having the same problems with the new patch, when I try and modprobe lirc_pvr150 it can’t find the firmware.

    I am running gentoo with 2.6.14-gentoo-r5 kernel and I have hotplug and UDEV installed. I have tried putting the firmware in multiple directories (several of the ones you listed are present on my system).

    Any ideas how I could narrow down the problem? Thanks for your help

    — Mark Roy

  5. 5
    Jesse Says:

    Works great for me on Gentoo with 2.6.14-ck6 and ivtv-0.4.2

    I’m still working on a ebuild that I’ll I post once it’s finished

  6. 6
    Xavier Says:

    First of all, thanx for all the stuff, the prepatched verion of lirc is usefull as well as the send_power_new script.
    I use to have the same problem as mikey.
    A cold boot doesn’t solve the problem.
    at the end, I unpluged and plug again the pvr150 and it seems to work.
    the only trouble is already done this for the version 2 and sometimes lirc still don’t want to work and i miss some recordings :(
    I hope it will not appeared again.
    anyway, ty for your work !
    Xavier

  7. 7
    mark Says:

    Hi, sorry for the delays, work again.

    mikey utah: Do you have a Zilog Z8F0811 CPU on the card? Can you find it with i2cdetect? Does it work with lirc_i2c? Does it work with windows? Basically, if it can’t find the chip, it’s not going to get very far. Other people have seen this and I’d be really interested in finding out what it is, so I’d really appreciate some help tracking it down.

    Mark Roy: udev/hotplug just ends up running a program, which runs a bunch of scripts. If you do cat /proc/sys/kernel/hotplug, that will give you the name of the hotplug program. That then decides what it is being asked to do, and typically ends up running some script or other. On my boxes, the script is called /etc/hotplug/firmware.agent. If you can find the firmware loader script, then you can stuff some lines in to debug it. The driver version won’t make any difference — this is a local configuration issue.

    Jesse: Great, thanks very much!

    Xavier: Glad it’s mostly working for you. I do find it odd that reseating the card solved the problem though. When you say “doesn’t work”, what precisely is the issue?

  8. 8
    mikey utah Says:

    Actually, I may have been a dunderhead here. Doing some additional research into my card lead me to find that what I have is, in fact, a MEDIA CENTER EDITION PVR-150. The difference is thus: with the MCE edition, the tranciever does not plug into the TV card but rather is a USB device. I believe my model is made by SMK, and it is *seemingly* supported by the lirc_mceusb2 driver. (I say seemingly because I still haven’t gotten it to work, but I believe this to be an issue of lirc configuration, as the driver seems to load correctly. Couldn’t get it to work under Win2K, either. Ugh.)

    More information can be found here:
    http://blatter.com/mceusb/

    Thanks for your help, Mark!

  9. 9
    Mark's Fan Club Says:

    You’re the man, Mark. Works for me on kernel 2.6.15 with ivtv 0.4.2, with lirc_pvr150 added as its own line in /etc/modules and after a cold power-off reboot.

    Any word on why this fix has not been integrated upstream into the main lirc branch?

  10. 10
    Mike Says:

    Thanks for updating the driver. I’m so close (hopefully) to getting it to work. I’ve followed the instructions, but it’s still not working.

    Here’s my syslog output when I load the modules:
    Jan 27 12:07:12 localhost kernel: [4297529.937000] lirc_dev: IR Remote Control driver registered, at major 61
    Jan 27 12:07:14 localhost kernel: [4297531.313000] lirc_pvr150: chip found with RX and TX
    Jan 27 12:07:14 localhost kernel: [4297531.313000] ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    Jan 27 12:07:14 localhost kernel: [4297531.326000] ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    Jan 27 12:07:14 localhost kernel: [4297531.330000] lirc_dev: lirc_register_plugin: sample_rate: 0
    Jan 27 12:07:14 localhost kernel: [4297531.395000] lirc_pvr150: firmware of size 229018 loaded
    Jan 27 12:07:14 localhost kernel: [4297531.395000] lirc_pvr150: 608 codesets loaded

    It’s missing the last line about the firmware version. When I check if it’s working with ‘irw’ I get nothing. Do you have any advice? Thanks.

  11. 11
    Ron Simpkin Says:

    First: Thanks for your work Mark :) it’s much appreciated – the light now flashes.

    However the send_power_new script seems to list the 2.2 beta version from Hauppauge’s site whilst the firmware you have available for download is still for 1.3, giving errors like the following when run:
    irsend: command failed: SEND_ONCE blaster 0_85_KEY_POWER
    irsend: transmission failed

    I’ll be honest and say I’m particularly interested in 1_663 for the Sky Digibox which is one of the new ones in the 2.2 beta version.

    Mark Roy:: Putting the firmware in /lib/firmware worked for me on Gentoo

  12. 12
    John Nissley Says:

    When I try to do the ./configure I get this error message.
    /configure
    which: no dialog in (/usr/kerberos/sbin:/sbin:/usr/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/mythtv/bin)
    dialog not found!
    Please read the documentation!!!

    How do I resolve this and where can I find the documentation?

  13. 13
    Ryan Says:

    Thanks for the upgraded version of lirc. I upgraded ivtv from 0.4.0 to 0.4.2, and lirc-0.7.2 to your patched 0.8.0pre4 today. Works great!

    Since I’m running AMD64, I still had to edit config_file.c and remove the lirc_t check, but after doing that it worked like a charm with my existing configuration files.

  14. 14
    Matt Says:

    Mark,

    Just wanted to say thanks for all of the work you’ve done. I installed the new ivtv a few weeks ago and the remote hasn’t cut out once since. Thanks again.

    -Matt.

  15. 15
    Andrew Barbaccia Says:

    Hello Mark,

    Great to see you’ve been making progress here. I’ve done much work with Ubuntu and mythTV so I thought getting the IRBlaster and including a how-to on my webpage would be worthwhile (giving credit where it is justly due). If you could help me out i’d appreciate it. My dmesg output is as follows.

    [4294690.212000] ivtv: ==================== START INIT IVTV ====================
    [4294690.212000] ivtv: version 0.4.2 (tagged release) loading
    [4294690.212000] ivtv: Linux version: 2.6.12-10-686 686 gcc-3.4
    [4294690.212000] ivtv: In case of problems please include the debug info between
    [4294690.212000] ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    [4294690.212000] ivtv: any module options, when mailing the ivtv-users mailinglist.
    [4294690.213000] ivtv0: Autodetected WinTV PVR 150 card (cx23416 based)
    [4294690.269000] tveeprom: ivtv version
    [4294690.269000] ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    [4294690.289000] tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
    [4294690.289000] ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    [4294690.687000] cx25840 0-0044: ivtv driver
    [4294690.687000] cx25840 0-0044: cx25841-23 found @ 0×88 (ivtv i2c driver #0)
    [4294694.499000] ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    [4294694.557000] wm8775 0-001b: ivtv driver
    [4294694.557000] wm8775 0-001b: chip found @ 0×36 (ivtv i2c driver #0)
    [4294694.567000] ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    [4294695.308000] ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    [4294695.518000] ivtv0: Encoder revision: 0×02050032
    [4294695.519000] ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    [4294695.551000] ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    [4294695.552000] ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    [4294695.554000] ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    [4294695.554000] tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
    [4294695.769000] ivtv0: Initialized WinTV PVR 150, card #0
    [4294695.769000] ivtv: ==================== END INIT IVTV ====================

    [4294695.774000] lirc_dev: IR Remote Control driver registered, at major 61
    [4294695.775000] lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    [4294695.817000] lirc_pvr150: ivtv i2c driver #0: no devices found

    Seems like it’s not picking up the chip although ivtv is. Its version 0.4.2 of ivtv and the prepatched version of lirc. Lemme know what you get of all this.

    Regards,
    Andrew

  16. 16
    JJones Says:

    what sort of debugging is available in IRW? As far as I can tell (I will post my logs a little bit later today), all of the steps work fine up until IRW comes into play, and then I don’t get any output to my console. So I load IRW, and it just sits there staring at me. Is there anything I can do for debugging, or is IRW so basic that what it outputs is all there is.

    Also, I followed this step by step, so I used the pvr150 lircd.conf and firmware file, but might this work with any remote? I have already swapped out the reciever,so put possible problems in the setup with the modules, the remote, or the card itself. Thanks for the help, so far, this tutorial has gotten be farther than any other web resource.

  17. 17
    Xavier Says:

    Sorry for the delay, I wasn’t be able to know where was my comment :)
    The version 3 is pretty stable, and I don’t have any problem with it, if I don’t stress it. I was sending a “fake” key every two secondes during the recording to be able to know if a can switch the channel on the NTL box or not, but it take to much cpu if i’m watching an other show at the same time. and sometimes the device stop to work. But since I stop this dirty script, i don’t have any problem.

    However I got a problem, sometimes I recorded on the wrong channel. And I just realise today what append. If I try to change the channel to a channel with double number, the NTL box won’t change the channel (144 -> 14) (117 -> 17), only the first number is taken. So I try to play with a bigger gap in the lircd.conf without success. I finally fix it by changing the script change_channel. so when i want to switch to 144, it send “1 4 5 CH_DOWN”. it isn’t really pretty at all, so I will be glad if you know the solution to my problem. (and it can be worth 118 -> “1 2 0 CH_DOWN” or 117 -> “1 2 0 CH_DOWN VOL_UP CH_DOWN” with a VOL_UP between CH_DOWN otherwise it doesn’t work)

  18. 18
    Xavier Says:

    I talk a bit too fast :(
    After 1 week without problem, I got this last night:
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found

    And I still don’t know how to resolve properly the repetition signal problem.

  19. 19
    Scott Says:

    Followed everything to the ‘T’ yet when I try and execute the ‘send_power_new’ script I get the following :

    irsend: command failed: SEND_ONCE blaster 1_678_KEY_POWER
    irsend: unknown remote: “blaster”

    Not sure what is going on here. The remote is working fine.

  20. 20
    mark Says:

    From the top,

    Mark’s Fan Club: fab! It’s not integrated because there are potential issues with distributing the database dump. I’m working on it, slowly, but it’s not likely to end up in the main version of lirc any time soon.

    Mike: not sure. Can you load the module with debug=1 and post the output?

    Ron: the reported firmware version is the version of the IR chip firmware, not the database. Can you post the dmesg output with the module loaded with debug=1?

    John: install the dialog package. Documentation is included with LIRC.

    Ryan: splendid. That patch should probably go back to lirc (as it’s lirc specific code) if it affects AMD64 generically.

    Andrew: Can you try ivtvctl –reset-ir before loading the module and let me know if it find it then?

    JJones: to debug IRW, you need to compile lirc with debug enabled (available from the configure dialog). You can also try loading the module with debug=1 and posting the dmesg output.

    Xavier: hmm, odd. Have you tried checking what other codesets the box will respond to, it doesn’t sound like it quite has it right. The gap parameter does affect the timing between digits AFAICR.

    Xavier#2: try running ivtvctl –reset-ir before loading the module.

    Scott: You aren’t using the right lircd.conf.

  21. 21
    Scott Says:

    Thanks, figured it out, had an extra lircd.conf laying in /etc/ and for some reason… it was using that one

  22. 22
    Xavier Says:

    Hi Mark,
    thx for the tip (ivtvctl –-reset-ir), it’s seems to work so i added this in my script when irsend failed. I will see in the future if that’s fix this problem.
    Concerning my repetition, I will try with other codeset.
    I use NTL with samsung SMT-2100-c box, if someone use it as well, please give me the codeset you use.

    Currently I use the 384 and the power button turn off the box but can’t turn it on.
    I try as well 661, same result (turn off only and repetition don’t work) and 666 (turn on only and repetition don’t work)

    I will try to find a codeset capable to turn off and on the box, but it will take me a while …

    Xavier

  23. 23
    Chris, Ohio Says:

    Hello Mark,

    First Id like to say excellent work. This is just what Ive been looking for Santa brought me a PVR-150 for Christmas but its a newer version than most of the writeups ive seen. It is not a MCE but it has both the RX and TX on the same minijack port. Ive noticed one difference in the lircd.conf it does not include the new generation 3 150 remote commands.
    Ive located these on another site that most MythTV users should already know of.
    http://wilsonet.com/mythtv/lircd-g3.conf.txt
    I noticed the codes are different.
    Any how to my point im currently formatting my server due to 2 SCSI drives failing on me (I guess 4 years is good life for 24/7 server).
    I can get my TX to blink and can use Terminal to change channels but in my frontend the remote only changes the server and not my Sat dish. In the myth setup when I type the path to the change_channel script do I require ” “? Or am I on the wrong path here?
    Sorry for being so vague but im a bit new to linux. Learning everything for the first time. Once I get it back up Ill let you know what else I run into.

    P.S. on a personal note I dont mind searching the www to locate things such as step #5 Check the syslog output. (whats the command?). I used to write up step by step instructions for Dos based programs years ago. My theroy always was pretend the person reading your walkthrough knows absolutely nothing about what he/she is doing. I know it may be a PITA but it would make everything more user friendly.

    Cheers

  24. 24
    bob Says:

    Hi guys,

    anxious to get version 3 of mark’s setup working. using gentoo. can anyone provide ebuilds for this (patched lirc).??? Thanks.

  25. 25
    bob (first bob) Says:

    Hi guys,

    Nevermind, i just created an ebuild for lirc-0.8.0_pre4 for gentoo with the patch, let me know if anyone needs it.

  26. 26
    marc Says:

    Bob can you make your ebuild available, and since I am pretty new to gentoo, tell me how to use it.

    I have got the lirc code from Mark, but I can not configure it.
    The configuration dialogue comes up nicely, but if I choose driver configuration, software configuration, save configuration & run configure, save configuration & exit, or Exit WITHOUT doing anything, then it just goes back to the Mainmenu. I don’t get any of the options. Cancel works fine.

    Has anybody seen such a thing.

  27. 27
    marc Says:

    I got build to configure after emerge’ing mythtv and lirc, and then removing lirc with “emerge -C lirc”. There probably is a dependency that is needed, that caused the problem with the menu.

    I still can’t get the remote to work. I have teases, but no joy.
    Periodically I can get irw to report a single key press, then nothing. Othertimes I get nothing. If I use cat, I get one or two strange characters (are they binary?).

    Hints appreciated.

  28. 28
    Francisco Says:

    Hi Mark,

    After almost one week tryng to configure my PVR-150 remote control for MythTV on MEPIS, thank God I found your HowTo.

    It is working now. Some adjustments and personalization tasks are nedded now.

    This note is to thank you and please continue you efforts to maintain this HowTo.

    From, Ciudad de Panamá, Panamá with nice view of the Canal de Panamá (your postcard!), again THANK S A LOT MARK!!!

    Regards.

    Francisco.

  29. 29
    fri Says:

    Mark,
    A million thanks to you and your hard work. Your instructions worked perfectly and now us pvr-150 users can have onboard ir blasting. The send power script was a smart way to find a compatible codeset, and the set top is under control again.

    Keep up the great work.
    kernel 2.6.15, mythtv .19

  30. 30
    Pucky Says:

    worked like a charm on FC 4,

    Thanks Mark

  31. 31
    Joe Says:

    Have any of you experienced “tinny” audio?

    http://www.gossamer-threads.com/lists/ivtv/devel/28418?do=post_view_threaded#28418

    I am in gentoo with ivtv 0.4.2 (package) and the prepatched lirc pre4 and I am having these problems.

  32. 32
    Yadav Says:

    Is it possible to use the IR receiver with any other remotes other than the Hauppauge remote? I tried putting info for other remotes in lircd.conf. but the remote still can’t see them. I also tried irrecord, but that didn’t work. I’m hoping that it will work, but I doubt it.

  33. 33
    Adam Says:

    I followed this up to the send_power_new script. When I run it $./send_power_new
    It scrolls through the terminal really fast and the blaster only flashes a few times once it is about half way through the script. Am I running the script right, or do I need to run it differently?

    Is the script just trying to see if it will turn the STB on? Or does the script scroll through and if it turns on the box it knows to stop and show the code? It seems like the way I am running it right now there is no why I will be able to find the codeset from running the script.

    On a side note has anyone found a list for the codesets for the supported boxs like these: http://www.hauppauge.com/pages/support/blaster_table_update_1105.html

  34. 34
    Adam Says:

    Got it figured out. I am kind of new to linux so I forgot to add #!/bin/sh as the first line in the script. After that everything worked.

    Thanks for this driver support Mark!

  35. 35
    mark Says:

    Gosh, it’s been a good long time since I’ve looked at this — I’ve been caught up in work, and other projects. So here we go, from about a month behind, and I’ll try and stay more up to date from now on.

    Xavier: I don’t have access to anything other than the hauppauge codes as a dump (and they are encrypted so there is not much chance of generating my own). Unfortunately therefore you are stuck with what they provide, good luck finding one that works.

    Chris: hope you’ve sorted yourself out now. It’s more of a mythtv question, but yes, basically you put the script path in somewhere and make sure the freqid columns have the channel numbers in the database. As mythtv-users if unsure.

    marc: I’m not sure what’s going on there, you’d have to give me some more configuration details, e.g. dmesg output with modprobe lirc_pvr150 debug=1, lircd log when compiled the with debug option.

    joe: ask ivtv-devel, it’s a known issue that is being worked on, albeit slowly.

    Yadav: if it is an RC5 remote you might be able to pick it up, but as is it’s designed to work with the remote that comes with it. A learning remote ought to work.

    Adam: must have missed that line off. To stop it, just hit CTRL+C and manually run the commands to work out which codeset it was. You can also whack “sleep 1″ lines in between the runs if it is going too fast.

    Seems to be mostly working for people, which is pretty good — I guess I’ve worked out most of the bugs now. btw if it doesn’t find the remote you might want to try modprobe ivtv newi2c=0 (after rmmod) as this has caused issues for a couple of people.

    HTH,

    Mark

  36. 36
    SteveH Says:

    Hi Mark,

    Thanks for the new release!

    Over on the hauppauge uk support forum there has been a lot of discussion about getting the IR blaster to work with SKY Digiboxes (codeset 0663). The beta they put out in Nov 05 didn’t work as advertised.

    They have released a new version of the IR Blaster software on the forum:
    http://www.hauppauge.co.uk/downloads/Forum/PVR150/2_5_24079_IRBlastWiz.EXE
    http://www.hauppauge.co.uk/downloads/Forum/PVR150/2_5_24079_IRBlast.EXE

    Would it be possible to get an updated firmware binary generated from this release? Is this something we could do, or do you have to do it?

    Regards,
    SteveH.

  37. 37
    mark Says:

    Andrew Shuttlewood kindly did the capture this time. I have updated haup-ir-blaster.bin, lircd.conf & send_power new using the new capture. Just grab all these again and follow the instructions at the top.

    I intended to do this at the weekend (I’m just letting it run on my box for a test), but as it seems fine and there is already interest I’ve done it now. Andrew reports that this works with his sky box.

    So thanks to Andrew for this release, and good luck with it!

    Mark

  38. 38
    mark Says:

    I’ve also added a list of codesets (derived from the hauppauge stuff) here.

  39. 39
    nzruss Says:

    Hi,

    Ive been following the instructions here (http://hyams.webhop.net/mythtv/myth_ubuntu.html) and everything is working great. I just need to get the IR blaster working for my DirecTV box.

    I have a couple of questions as I dont really want to undo my hard work on getting the remote working. My remote config file is coppied from Daniels Hyam’s file: http://s91928265.onlinehome.us/hfamily/mythtv/lircrc-haupgrey-g3.txt )

    I really want to keep the parameters as they are, but want to add the Blaster functionality to control my DirecTV D10

    I have ivtv-0.4.4, and lirc-0.7.2, with firmware v4l-cx25840.fw and
    v4l-cx2341x-enc.fw. (If that doesnt make sense check from the link above, as I followed it to the letter)

    Q: do I have to do all the steps you mention? or can I just do a subset? if so, where can I start?

    Any help really appreciated. I’ll be posting my build experience on my blog once done.

    Cheers!!

  40. 40
    mark Says:

    Do steps 2-10 inclusive, then cut and paste the result of step 10 (i.e. the blaster configuration) into your existing lircd.conf. That’s about as much as you can trim off it – the blaster driver is different from that provided with the standard lirc. (However you will not need to remap your keys as the IR RX portion will generate the same input codes, hence will work with your existing mappings).

  41. 41
    nzruss Says:

    Hi Mark,

    Thanks so much. Will give it a try. I really appreciate your help.

    Russ

  42. 42
    nzruss Says:

    Hi Mark. No luck. I think I had a few issues, so ive written my results at:

    http://nzruss.blogspot.com/

    just cos there are a few. If you (or anyone) can offer adivce, i’ll report back here.

    aim of my quick page was to provide feedback for your how-to. and i’ll be taking it down once ive got the issue resolved.

    cheers!

  43. 43
    mjhorn Says:

    Hi Mark,
    First of all another thanks, as until I came across your page here I was getting absolutely nowhere. Currently, I’ve followed your instructions up to testing with irw, and everything has worked perfectly. Things compiled correctly, modules loaded, correct dmesg outputs so up to there it seems everything is great. However, when I run irw, i get no response to pressing buttons on the remote whatsoever. Any ideas?
    thanks again
    Mike

  44. 44
    boggie Says:

    Hi Mark,

    Thanks for the hardwork. I have tried out your instructions. A few problems that I encounter. I am using Ubuntu Breezy with the 2.6.12-10-686 kernel.

    I have configured according to your instructions and I noticed that it created the lirc0 device node but there was no lircd and lircmd daemons in the device folder. Without the lircd daemon, it is not possible to get it to work as it will report an error “could not connect to socket”.

    I use dmesg |grep lirc and and also dmesg|grep ivtv and got those messages that you got.

    Any idea why those daemons are not generated. Also, irw did not work. Thanks for the hard work and I look forward to your solution.

    boggie

  45. 45
    boggie Says:

    Hi Mark,

    Got it working. I found some old posting exchanges between yourself and Scott. I put the following into bootmisc.sh

    modprobe lirc_pvr150
    /usr/local/sbin/lircd –device=/dev/lirc0

    That created the lircd daemon in the /dev folder on bootup. Then I removed all references to lirc_i2c in the other files.

    Thank you for the hardwork! It is much appreciated.

    boggie

  46. 46
    boggie Says:

    Hi Mark,

    Any likelihood of using the codesets via haup-ir-blaster.bin working through the serial ports for PVR-250 and PVR-350? This is the most elegant solution if it can be made to work. There are implementation using serial ports but the problem is always with locating the raw codes for the codesets.

    boggie

  47. 47
    Adam Says:

    I upgraded from FC3 to FC4 and am having problems when I issue the make command. I look at the previous problems with FC4 but it didn’t seem to help. Here is what I get when I run make:

    ***********************************************
    make[3]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_dev’
    Making all in lirc_pvr150
    make[3]: Entering directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150′
    mv Makefile Makefile.automake
    cp ../Makefile.kernel Makefile
    make -C /lib/modules/2.6.16-1.2069_FC4/build/ SUBDIRS=/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150 modules \
    KBUILD_VERBOSE=1
    make[4]: Entering directory `/usr/src/kernels/2.6.16-1.2069_FC4-i686′
    mkdir -p /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/.tmp_versions
    make -f scripts/Makefile.build obj=/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150
    gcc -m32 -Wp,-MD,/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/.lirc_pvr150.o.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.0.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -g -pipe -msoft-float -fno-builtin-sprintf -fno-builtin-log2 -fno-builtin-puts -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -mregparm=3 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DIRCTL_DEV_MAJOR=61 -DEXPORT_SYMTAB -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/../.. -I/lib/modules/2.6.16-1.2069_FC4/build//include/ -DMODULE -D”KBUILD_STR(s)=#s” -D”KBUILD_BASENAME=KBUILD_STR(lirc_pvr150)” -D”KBUILD_MODNAME=KBUILD_STR(lirc_pvr150)” -c -o /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/.tmp_lirc_pvr150.o /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1157: error: unknown field ‘name’ specified in initializer
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1157: warning: initialization makes integer from pointer without a cast
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1158: error: ‘I2C_DRIVERID_EXP3’ undeclared here (not in a function)
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1159: error: unknown field ‘flags’ specified in initializer
    /usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1159: error: ‘I2C_DF_NOTIFY’ undeclared here (not in a function)
    make[5]: *** [/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150/lirc_pvr150.o] Error 1
    make[4]: *** [_module_/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150] Error 2
    make[4]: Leaving directory `/usr/src/kernels/2.6.16-1.2069_FC4-i686′
    make[3]: *** [lirc_pvr150.o] Error 2
    make[3]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers/lirc_pvr150′
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150/drivers’
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/usr/src/lirc-0.8.0pre4-pvr150′
    make: *** [all] Error 2
    *********************************************************

    The lirc_dev driver gets made ok but not the lirc_pvr150. I have kernel 2.6.16-1.2069_FC4 installed from atrpms also gcc is installed and I just did a yum upgrade. The ivtv version is ivtv-0.6.1-109.rhfc4.at from atrpms.

    Any help?
    Thanks, Adam

  48. 48
    Dave Rose Says:

    Adam, I am seeing the exact same thing. I am running the same versions as you…hope Mark can help.

  49. 49
    mark Says:

    Sorry, haven’t had much time recently. Unfortunately I don’t get much free time to work on this due to the everyday business of work & looking after a couple of groups of ferrets (fun but time consuming ;)

    Anyway, replies in order:

    nzruss — Please uninstall whatever lirc you have installed already and then start from the beginning, making sure each step succeeds before proceeding to the next.

    mjhorn: not sure, can you load lirc_pvr150 with modprobe lirc_pvr150 debug=1 & post the output from that? Also worth checking that the jack is in the back of the card, it can take some wiggling to get it connected properly.

    boggie: glad you were able to help yourself! Sorry I didn’t get to replying before you did! Unfortunately there’s no hope of using the codesets files with any other kind of card; the binary dumps are in fact encrypted. I work basically by capturing & replaying the encrypted stream, but because I have no idea of the content of the data it’s only any use with a PVR-150.

    Adam & Dave: please try this updated file and let me know if it works. It’s based of a recent CVS dump of lirc; there is as yet no lirc release that supports the 2.6.16 kernel. Unfortunately I don’t have a 2.6.16 based machine to test the compile against at present — I’ve made the same fix as in lirc-i2c.c, so hopefully it should work.

  50. 50
    Dave Rose Says:

    Thanks Mark, but it does the same thing:

    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: error: unknown field ‘name’ specified in initializer
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: warning: missing braces around initializer
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: warning: (near initialization for ‘driver.list’)
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1166: warning: initialization from incompatible pointer type
    make[5]: *** [/usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/drivers/lirc_pvr150/lirc_pvr150.o] Error 1

    Would it help if I gave you an account to log into my box and try to compile it yourself? This way you’d have access to a 2.6.16 kernel?

  51. 51
    mark Says:

    Yup, that would certainly help. Feel free to mail me with details (mark@npsl.co.uk) — I should be able to get around to it tomorrow as I have the next few days off.

  52. 52
    Dave Rose Says:

    Mark, when you say:

    “there is as yet no lirc release that supports the 2.6.16 kernel.”

    I’m a bit confused, I am running lirc-0.8.1 on a 2.6.15/16 kernel now, I got my RPM from:

    http://atrpms.net/dist/fc4/lirc-0.8.1/

    They have a source RPM there if it helps…of course it does not contain any of your code.

  53. 53
    mark Says:

    It must be based on a CVS snapshot. See:

    http://lirc.org/

    lirc-0.8.1 is not yet released.

  54. 54
    Dave Rose Says:

    Account information has been sent to you…good luck.

  55. 55
    mark Says:

    Now fixed (& fixed package uploaded). Thanks for the help!

  56. 56
    Adam Says:

    The new package works great, thanks Mark.

  57. 57
    Dave Rose Says:

    Just trying it now, don’t know if you noticed, but the configure script spewed out a few things right at the beginning for me:

    checking whether build environment is sane… yes
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/missing: Unknown `–run’ option
    Try `/usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/missing –help’ for more information
    configure: WARNING: `missing’ script is too old or missing
    checking for gawk… gawk

  58. 58
    Dave Rose Says:

    Hmm, compiles fine, but after the install I get:

    [root@draco modules]# modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.16-1.2069_FC4smp/misc/lirc_dev.ko): Invalid module format

  59. 59
    Dave Rose Says:

    Ugh, my fault.

    I am using an SMP kernel, but I didn’t have the kernel-smp-devel RPM installed. Thus the vermagic was not right.

    Thanks.

  60. 60
    Julius Says:

    Hi,

    I have the light going on the IRblaster, (and irw getting the Hauppauge remote keys) but I don’t know which codeset to use. I have a lirc file though which is supposed to work for the STB (Pace DSR620-GM) from:
    http://lirc.sourceforge.net/remotes/pace/RC-30

    Can you tell me which codeset is associated with this STB?

    Thanks for the howto; the comments are useful too!

  61. 61
    mark Says:

    Dave/Adam: great, thanks!

    Julius: That lirc configuration file won’t work with the PVR-150.
    Please use the lircd.conf above and follow step #9 with the send_power_new script.

    Mark

  62. 62
    Dave Rose Says:

    The only codeset in the list that says Pace is 101…try that :)

    Also, instead of editing the lircd.conf and removing the unwnated entries and renaming things, I just prepended the code set to the irsend line…here is the script I use. Since I really only care about the digits…

    #!/usr/bin/perl
    #
    # Quick and dirty change channel script
    # Dave Rose (drose@drcsDOTca)
    #

    $remote_name = “blaster”;
    $irsend=”/usr/local/bin/irsend”;
    $prepend = “1_28_KEY_”; # put your codeset here
    $enter = “1_28_KEY_ENTER”;

    sub change_channel {
    my($channel_digit) = @_;
    system (“$irsend SEND_ONCE $remote_name $prepend$channel_digit”);
    sleep 1;
    }

    $channel=$ARGV[0];

    if ($channel =~ /power|select/) {
    change_channel($channel);
    } elsif (length($channel) > 2) {
    change_channel(substr($channel,0,1));
    change_channel(substr($channel,1,1));
    change_channel(substr($channel,2,1));
    } elsif (length($channel) > 1) {
    change_channel(substr($channel,0,1));
    change_channel(substr($channel,1,1));
    } else {
    change_channel(substr($channel,0,1));
    }
    system (“$irsend $options SEND_ONCE $remote_name $enter”);

  63. 63
    Julius Says:

    Sweet as. I’ll give it a crack and see when the STB’s power goes off/on and watch the numbers on the screen at the same time. (Unfortunately I don’t have the STB at my place so I’ll post in a few days).

    Thanks for the help!

  64. 64
    Julius Says:

    Unfortunately it didn’t work. I tried it in XP too with the latest IRblaster config tool. I have asked techsupport at hauppauge.com to see if they don’t support the STB and if they’ll send an update to me, but I’m not holding my breath. Does anyone know if it is likely to happen?

    Also, let’s say the following lircd.conf file is correct (http://lirc.sourceforge.net/remotes/pace/RC-30) for the STB I’m wanting to control, would I just replace all info between (and including) “bits” and “endcodes” in the section with the name blaster? Or does the blaster firmware require codes that have been created by hauppauge in a special format?

  65. 65
    mark Says:

    Unfortunately it requires specially formatted data so no other lirc configuration will work. If you can get it working under XP, it will be possible to get it to work under linux as well, but if not unfortunately there’s little to be done.

    Might be worth making sure you had the LED in the right place on the STB — it has a very short range. It’s also not always where the LED is that lights up when you press the remote (if any) — you need to look for receiver module with a torch generally as they are typically behind a filter.

    HTH,

    Mark

  66. 66
    Julius Says:

    Yeah I might try a third time. I tried it in two places. There are currently two other blaster like devices which control the STB so I’m pretty sure where to put it. I also did the torch thing. The other blaster devices are from: a VHS video player/recorder and cabling from around the house so other sky remotes can change the channel in other locations.

    Interestingly the IR transmitter’s “bulb” didn’t light up when looking through my camera. I could see the blaster “bulb” next to the LED (closer to where the wire connection than the LED) so I could figure out where to put it but it doesn’t look good. I wish I could use an irw program to test it is working. The only thing is if the LED is blinking, I guess it can’t be broken, unless it’s wired in parallel and broken inside the little plastic piece (unlikely I think!)

    Thanks for all the help. I’ll let you know if I get it going of hauppauge go good. If you know of another way to control it, using another IR blaster device (my shuttle has a serial port) I might give it a go.

    Thanks again.

  67. 67
    Sebastiaan Says:

    Hi Mark,
    I have a issue with this lircd.conf for the ir blaster. If i use your suplied lircd.conf file (placed in /etc/lircd.conf) i get following error when starting the lircd:

    lircd -n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid

    response:
    lircd: error in configfile line -2147483648:
    lircd: Segmentation fault

    I tried removing all codes, only leaving the 0_0_KEY like:
    begin raw_codes
    name 0_0_KEY_0
    0
    end raw_codes

    with this lircd.conf the blaster works, no error and the led on the blaster lites up when i do a
    irsend -d /dev/lircd1 SEND_ONCE blaster 0_0_KEY_0

    I assume there is a mismatch between with my firmware and the lircd.conf you supplied.
    When loading the drivers my syslog says:
    Apr 23 13:09:19 verena kernel: lirc_pvr150: firmware of size 248009 loaded
    Apr 23 13:09:19 verena kernel: lirc_pvr150: 637 codesets loaded
    Apr 23 13:09:19 verena kernel: lirc_pvr150: 01 60 00 01
    …. lots of numbers…..
    Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    so this seems ok with the only difference of the 637 codesets loaded compaired to 575 and the different file size of the firmware compaired to the listings you provide above

    Is there a way to create a lird.conf which fits to my firmware?

    thanks,
    Bas

  68. 68
    mark Says:

    Julius: there are stacks of other IR blaster devices, see http://lirc.org/ + the lirc list for more details.

    Seb: that’s a lirc userland daemon bug (which is actually just the standard lirc code). Can you compile lirc with debug turned on, then run it in gdb and mail me the backtrace?

    Thanks, Mark.

  69. 69
    Sebastiaan Says:

    I compiled lirc with debug turned on:
    ./configure –enable-debug –with-driver=hauppauge_pvr150
    make && make install

    then I runned lircd in gdb:
    verena:/dev# gdb /usr/local/sbin/lircd
    GNU gdb 6.4-debian
    Copyright 2005 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type “show copying” to see the conditions.
    There is absolutely no warranty for GDB. Type “show warranty” for details.
    This GDB was configured as “x86_64-linux-gnu”…Using host libthread_db library “/lib/libthread_db.so.1″.

    (gdb) set args -n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid
    (gdb) show args
    Argument list to give program being debugged when it is started is “-n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid”.
    (gdb) run
    Starting program: /usr/local/sbin/lircd -n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid
    lircd: error in configfile line -2147483648:
    lircd:
    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaac364b0 in strlen () from /lib/libc.so.6

    does this mean anything to you?? I doesn’t tell me a thing ;)

  70. 70
    Alex Says:

    Thanks!! Worked great for the Hauppauge PVR 250!

  71. 71
    Tommy Says:

    I was so excited when everything just worked so smoothly until step 9. Unfortunately it does not seem that my Scientific Atlanta Explorer 1850 is supported as this time (verified with an installation on winxp). I will try to bother Hauppauge for support. Oh well…it was fun while it lasted. Though it didn’t work for me I really appreciate the efforts that you put into this. I will let you know if I get some kind of response from Hauppauge.

    If anyone knows of any alternative method to make IR blaster work with my cable box, I would be very interested to know. I’ve done a lot of searches on google and websites but I have not been successful so far. Thanks.

  72. 72
    Mike S. Says:

    What are the chances of having a blown IR LED?

    I have successfully installed everything and get no errors when running the “send_power_new” script, but I get no blinking light on the transmitter. Should the light emitted from the transmitter be visible?

    The IR receiver, however, works fine with the PVR-150 remote (model 1045). I pulled the plastic end apart on the blaster and checked the voltage. I *do* get a small voltage increase while the script runs, but don’t see any light and can’t turn on my Motorola DCT-2224. So my conclusion is the actual LED is busted. Anyone have any advice?

    Another question: If I’m satisfied at least the software is working, how do I load this on startup. On Fedora Core 5, I’ve placed the startup script in /etc/init.d and configured it to start when booting, but what do I put in the /etc/modprobe.conf file to load the lirc kernel module on startup? Any help?

  73. 73
    Xavier Says:

    Hi!
    I come here only when I have a problem, sorry about that :)
    I change my kernel (yum automatic :( )
    I compile again the pre-patched lirc 0.8.1 CVS as of 2006-04-13 but i still have the same problem:
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.16-1.2122_FC5/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)
    I have the devel for 2.6.16-1.2122 only…
    any idea

  74. 74
    Ryan Says:

    Mark,

    Thanks for the tutorial and the code – I was on a roll…

    After getting all of this configured, while I was running your power on/off script my light was blinking (albeit very faintly… is that normal?), and now it’s not blinking any more at all… should I take this to mean that the hair-thin wire that leads to the ir blaster has broken? Or should I stick with it? If it’s broken, should I bust it open to fix it or just give up?

    Ryan

  75. 75
    Xavier Says:

    forget me, yum forgot to update ivtv-kdml ….

  76. 76
    Bill Says:

    I’ve installed KnoppMyth version R5C7 on my system, and am attempting to use these steps to get the IR blaster on my PVR 150 card working. I’m getting to step 4 and failing. Here is what my syslog output is:

    ****************************************************
    Jun 12 00:20:26 backend kernel: kobject_register failed for i2c ir driver (-17)
    Jun 12 00:20:26 backend kernel: [kobject_register+54/96] kobject_register+0×36/0×60
    Jun 12 00:20:26 backend kernel: [bus_add_driver+64/160] bus_add_driver+0×40/0xa0
    Jun 12 00:20:26 backend kernel: [driver_register+66/80] driver_register+0×42/0×50
    Jun 12 00:20:26 backend kernel: [pg0+273991046/1067881472] i2c_add_driver+0×46/0xc0 [i2c_core]
    Jun 12 00:20:26 backend kernel: [pg0+276901162/1067881472] init_module+0x5a/0×60 [lirc_pvr150]
    Jun 12 00:20:26 backend kernel: [sys_init_module+338/528] sys_init_module+0×152/0×210
    Jun 12 00:20:26 backend kernel: [syscall_call+7/11] syscall_call+0×7/0xb
    ****************************************************

    That’s what comes up as a result of the “modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1″ command.

    Anything you can suggest? I believe this version of KnoppMyth has IVTV .4.4 builtin. So I didn’t do anything for step 1. I just skipped right ahead to step 2. I haven’t rebooted or anything at any point in these steps, there was no directions indicating I needed to reboot or anything for a certain step to take effect, is this correct? Anything you can offer is muchly appreciated.

    Thanks!

  77. 77
    Kels Says:

    Hey Man you RULE! I’ve been using this patch and the instructions you provided. It works great with on my Slackware Mythbox. Thanks for taking the time to do this. I’ll send you beer money soon :)
    Kels

  78. 78
    Simon Baxter Says:

    Hi – I’ve been following all the above, have built LIRC from the lirc-0.8.1-CVS-pvr150.tar.bz2.

    IVTV 0.6.3 loads fine, but I still can’t see the IR hardware:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found

    I tried:
    [root@media firmware]# ivtvctl –reset-ir
    ioctl IVTV_IOC_RESET_IR ok

    but still the same.

    I’ve tried pulling the card, cold reboots, everything.

    Can anyone help??

  79. 79
    Simon Baxter Says:

    Any chance I’m using the wrong version of the card hardware?

    [root@media firmware]# ls -l
    total 812
    -rw-r–r– 1 root root 248009 Mar 28 05:14 haup-ir-blaster.bin
    -rw-r–r– 1 root root 376836 May 26 13:19 v4l-cx2341x-enc.fw
    -rw-r–r– 1 root root 155648 Jun 2 07:49 v4l-cx2341x-init.mpg
    -r–r–r– 1 root root 16382 May 26 13:19 v4l-cx25840.fw
    -r–r–r– 1 root root 16382 May 26 13:24 v4l-cx25848.fw

    ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)

    i2c-1 i2c ivtv i2c driver #0
    i2c-0 smbus SMBus Via Pro adapter at 5000
    [root@media firmware]# i2cdetect 1
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-1.
    I will probe address range 0×03-0×77.
    Continue? [Y/n] Y
    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: XX XX XX XX XX XX XX XX XX XX XX XX XX
    10: XX XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX
    20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    40: XX XX XX XX UU XX XX XX XX XX XX XX XX XX XX XX
    50: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    60: XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    70: XX XX XX XX XX XX XX XX

    [root@media firmware]# i2cdump 1 0×61
    No size specified (using byte-data access)
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-1, address 0×61, mode byte
    Continue? [Y/n] Y
    0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
    00: fc 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ?|||||||||||||||
    10: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    20: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    30: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    40: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    50: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    60: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    70: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    80: 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c

  80. 80
    raj Says:

    Hi,
    I did installed the package and while checking the output of the command :
    modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    it is giving an error message like
    FATAL :can’t find PVR_150…………….

    So let me know what I have to do now.

    Thanks alot!

  81. 81
    raj Says:

    Hi Mark,
    linux:~ # modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    given me the following error message……..

    FATAL:Module lirc_pvr150 not found…..

    Please suggest me regarding!

  82. 82
    Xavier Says:

    Sorry to bother you again. I installed again my computer after my harddrive died.
    But I can’t use lirc_pvr150
    when i load lirc_dev, I get:
    lirc_dev: IR Remote Control driver registered, at major 61
    but when i try to load lirc_pvr150, I’ve got no error but nothing at all as well :-(
    the device /dev/lirc* doesn’t exist.
    with lirc_i2c, everything work well, but I definitly need the IR Blaster.
    I try to dig for few days now without any clue.
    I use ivtv-0.7-115.rhfc5.at and lirc-0.8.1-cvs20060325_58.rhfc5.at. I can’t remove lirc’s rpm because of the dependance however I installed the “pre-patched lirc 0.8.1 CVS as of 2006-04-13″

  83. 83
    Duane Says:

    I recently upgraded from time warner analog cable and already have pvr-150′s but wasn’t using the IR because when I first tried it, it was so bodgy, the remote would work for 10 seconds or so then require a cold boot to start working again…

    So anyways upgraded yesterday to directv and while I had a perfectly working mythtv setup, I didn’t have a way to change the channels short of some voo doo magic using usb to serial boxes null modem cables and pci serial card at large expense on top of my existing setup.

    Then I remembered the IR ports/cables for the PVR 150′s and started googling about and thankfully came across your website and I can’t thank you enough (will send you beer money next pay cheque)…

    I use ubuntu and because of updates to hal and other systems ivtv and haupage firmware needs to go into /lib/firmware/`uname -r`/

  84. 84
    Kels Says:

    Hey Xavier,
    The patch for ivtv-.7xx is broken I beleive until Mark updates them.
    I tried upgrading too but now I’m going back to a older version of kernel and ivtv just to get back support.

  85. 85
    raj Says:

    Mark,

    I have followed all the steps mentioned, I still seem to have problems running irw command, somtimes it says directory not found, and some times “Connnection Refused” , Not sure what’s going on. I copied your
    lircd.conf file owerwriting my existing lircd.conf file.
    I think I have successfully completed all steps till Step 7, Step 8 does not seem to be working.

    Here is my demsg:

    irc_dev: module not supported by Novell, setting U taint flag.
    lirc_dev: IR Remote Control driver registered, at major 60
    lirc_pvr150: module not supported by Novell, setting U taint flag.
    lirc_pvr150: no version for “ivtv_reset_ir_gpio” found: kernel tainted.
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    SFW2-OUT-ERROR IN= OUT=eth0 SRC=192.168.1.5 DST=130.57.5.25 LEN=40 TOS=0×00 PREC=0×00 TTL=64 ID=20328 DF PROTO=TCP SPT=21036 DPT=80 WINDOW=8360 RES=0×00 ACK FIN URGP=0
    SFW2-OUT-ERROR IN= OUT=eth0 SRC=192.168.1.5 DST=130.57.5.25 LEN=40 TOS=0×00 PREC=0×00 TTL=64 ID=20330 DF PROTO=TCP SPT=21036 DPT=80 WINDOW=8360 RES=0×00 ACK FIN URGP=0
    Warning: /proc/ide/hd?/settings interface is obsolete, and will be removed soon!

    Here is my ps command output

    oot 6584 1 0 09:00 ? 00:00:00 [lirc_pvr150]
    root 6901 6245 0 09:24 ? 00:00:04 kio_file [kdeinit] file /tmp/ksocket-root/klauncherU8x7ac.slave-socket /tmp
    root 7033 1 0 09:48 ? 00:00:00 lircd –device=/dev/lirc0
    root 7034 6538 0 09:48 pts/1 00:00:00 ps -eaf

    which shows that lircd is loaded and running.

    Please help.

    Thank You

  86. 86
    raj Says:

    Mark ,

    One more thing, I am using Hauppage PVR-150 on Suse Linux
    Thanks

  87. 87
    mark Says:

    Right, so I haven’t been at this since April! Work, holidays & decorating have been consuming all of my spare time, plus having to deal with the hundreds of spam comments has kind of been putting me off ;) So I expect most of this is out of date, but I’ll reply to everybody in order.

    Sebastiaan: I think that’s a AMD64 specific lirc bug that’s been fixed in later releases. You can try http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2 if you like, that’s a sync with the latest lirc for Cecil of knoppmyth fame to test.
    Alex: cool, but mainline lirc should do just as well, this driver is really for supporting the IR blaster device that comes with the PVR-150.
    Tommy: bothering hauppauge is the best you can do. Since the data is encrypted I can’t support new devices, I can only copy what the hauppauge driver does.
    Mike S.: The light is visible, it’s just a standard LED (not an IR one, that’s why it has got such short range). I would make sure that the jack is fully in and if so connect a multimeter across the LED (the case should pop apart easily enough). If you are getting voltages on it then the LED is screwed and you should be able to get a new one from Hauppauge.
    Xavier: glad you got it sorted!
    Ryan: The light should blink — if it was going, it should carry on doing so. Try sticking a multimeter across it and making sure there is voltage on it as above.
    Bill: Can you recompile the driver with debug enabled and send the dmesg output then?
    Kels: great, glad it works for you!
    Simon: If it can’t find the IR chip, it won’t work. Best thing to do is try it in under Windows/and or in a machine with a different motherboard to confirm that the hardware is working.
    raj: driver not installed properly, did you do make install?
    Xavier: you’ll have to remove the rpms I’m afraid. You can only have one version of lirc, and if you want the IR blaster to work it has to be this one. I’d try the link higher up if you are using a 2.6.17 kernel (or go back to a 2.6.16 one.
    Duane: great!
    Kels: try the link at the top if you want to bump the kernel, that’s a resync with the latest lirc CVS
    raj: looks ok, but lircd isn’t playing. Check that it has created /dev/lircd and check the lirc log file to see what is going on. It’s possible it’s just shown up as /dev/lircd1 or some such, in which case you just need to run irw /dev/lircd1 or whatever.

  88. 88
    Xavier Says:

    Mark,
    I removed all the rpm of lirc except lirc-libs which should not be a problem.
    Kels,
    ty for your answer. which version of ivtv do you actually use ?

  89. 89
    chutzpah Says:

    I have a gentoo ebuild of this (I’m a gentoo developer) if anyone else is interested in it, I can set up an overlay and post it.

    The best way to reach me is to send me an email (just stick @gentoo.org after my handle)

  90. 90
    Simon Baxter Says:

    Thanks Mark – yip, looks like I had a faulty PVR-150 (or at least, the IR chip). Hauppauge in NY has replaced the card under RMA.

  91. 91
    Bill Says:

    “Bill: Can you recompile the driver with debug enabled and send the dmesg output then?”

    I don’t actually know how to do this. Plus, I’ve picked up another IR blaster elsewhere and have it working (A serial port blaster). I’m not so much worried about getting this one off the ground and working at this point, thanks anyways.

    Bill

  92. 92
    Simon Baxter Says:

    Hi – HOORAY – the new card from Hauppauge seems to work, for IR receive anyway.

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_i2c: chip found @ 0×71 (Hauppauge IR (PVR150))
    lirc_dev: lirc_register_plugin: sample_rate: 10

    …and all buttons on the remote work.

    IR-Blaster doesn’t seem to work though:

    irsend -d /dev/lircd SEND_ONCE blaster 1_680_KEY_POWER
    irsend: command failed: SEND_ONCE blaster 1_680_KEY_POWER
    irsend: hardware does not support sending

    This is a new machine, with fresh everything.

    Any ideas?

  93. 93
    mark Says:

    Xavier: what’s in dmesg? Does the module load properly? Can you build it with debug enabled and send the output with modprobe lirc_pvr150 debug=1?

    Simon: you are using the wrong driver — lirc_i2c vs lirc_pvr150.

  94. 94
    Xavier Says:

    ok, I build it with debug mode.
    lsmod | grep lirc : no output

    modprobe lirc_dev
    dmesg output:
    lirc_dev: IR Remote Control driver registered, at major 61

    modprobe lirc_pvr150 debug=1
    dmesg: nothing more

    lsmod | grep lirc :
    lirc_pvr150 19264 0
    lirc_dev 15524 1 lirc_pvr150
    ivtv 175760 1 lirc_pvr150
    i2c_core 22209 12 lirc_pvr150,nvidia,wm8775,via686a,cx25840,tda9887,i2c_isa,tuner,ivtv,i2c_algo_bit,i2c_viapro,tveeprom

    I build it with debug mode enabled…

    rpm -qa | grep ivtv:
    ivtv-firmware-enc-2.04.024-9.at
    ivtv-firmware-1.8a-9.at
    ivtv-firmware-dec-2.02.023-9.at
    ivtv-kmdl-2.6.17-1.2139_FC5-0.7-115.rhfc5.at
    perl-Video-ivtv-0.13-7.rhfc5.at
    ivtv-0.7-115.rhfc5.at
    ivtv-firmware-audio-0.0.1-5.at

    uname -r:
    2.6.17-1.2139_FC5

    I don’t really want to go back to 2.6.16 because i use atrpm, where this kernel is not available anymore and antway, it’s a nithgmare with other stuff

  95. 95
    mark Says:

    The only way that I can see that you would get no further output when loading lirc_pvr150 is if ir_probe doesn’t get called with the right i2c adapter id, as per this test:

    #ifdef I2C_HW_B_CX2341X
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848) ||
    adap->id == (I2C_ALGO_BIT | I2C_HW_B_CX2341X))

    Can you add:

    dprintk(“adapter id %\n”, adap->id);

    to the top of ir_probe to see what adapter ids it is being called with?

    Otherwise I can have a poke around via SSH if you want.

  96. 96
    Xavier Says:

    I might stole your time, as i don’t seem to have the same source as you:
    I2C_HW_B_CX2341X is not in my source (i use the link above http://www.blushingpenguin.com/mark/lmilk/lirc-0.8.1-CVS-pvr150.tar.bz2 )
    so at the top of ir_probe, i’ve got :
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848))
    only.
    anyway by adding the dprintk, dmesg said:
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: adapter id 0
    lirc_pvr150: adapter id 65568
    lirc_pvr150: adapter id 0
    lirc_pvr150: adapter id 0
    lirc_pvr150: adapter id 0

    Is there any change to have lirc_pvr150 added in lirc cvs ?
    could you reply on maxpower44 at tiscali.fr ? should be easier for both of us.
    thx for your help.

  97. 97
    mark Says:

    Try this one:

    http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2

    It’s a sync with the current lirc CVS which should support 2.6.17+ kernels. If it works for you I will bump the version linked to in the article.

    HTH,

    Mark

  98. 98
    Kels Says:

    Mark:
    Thanks for the new work. I’ll report once i recompile 2.6.17 again.

    Xavier:
    I’m using IVTV 0.6.2 with kernel 2.6.16.16 on Slackware 10.2

    Regards,
    Kels

  99. 99
    Xavier Says:

    seems to work pervectly with ivtv 0.7 and kernel 2.6.17-1.2139.
    thanks a lot :) again

  100. 100
    Raghu Says:

    Xavier:
    I was having the same problem with lirc_pvr150 not creating the /dev/lirc0 device. The problem is in ir_probe function in lirc_pvr150.c the condition for probing the pvr150 has changed with the kernel 2.6.17 and ivtv 0.7.0-117. Replace the the following line
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848))
    with the ones below
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848) ||
    adap->id == (I2C_ALGO_BIT | I2C_HW_B_CX2341X))
    That has fixed my i2c_pvr150.

    Mark:
    Thanks for all the work on this module.

  101. 101
    Chris Says:

    Thanks Raghu, that worked perfectly. I was getting the same problem, lirc_pvr150 not creating the device (ivtv 0.7.0, kernel 2.6.17). All good now!

    And thanks Mark for the great guide and patches. Now that my remote is once again operational, the next step is to teach it what to do with my el cheapo STB ;) .

  102. 102
    Noah Says:

    Hello. I have a PVR-150 that worked no problem in an older machine with KnoppMyth R5C7.

    I have upgraded to a shuttle with an nforce board. The remote no longer functions. I receive: lirc_pvr150: ivtv i2c driver #0: no devices found

    I have tried the original lirc (which worked before) and both packages listed in mark’s step #2. I have tried ivtvctl –reset-ir, cold booting and warm booting.

    Since it worked before, I have a feeling that it’s a hardware compatability with the new motherboard. Perhaps with the existing i2c SMBus(s)? Any suggestions on what can I do to further troubleshoot or fix the problem?

    Thanks much,

  103. 103
    mark Says:

    Try loading ivtv with newi2c=0 and see if that makes any difference. If not, run i2c-detect and post the output.

    Cheers,

    Mark

  104. 104
    Noah Says:

    Here ya go, mark, hopefully it’s readable:

    root@myth:~# rmmod lirc_pvr150
    root@myth:~# rmmod lirc_dev
    root@myth:~# rmmod ivtv
    root@myth:~# modprobe ivtv newi2c=0
    root@myth:~# modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    root@myth:~# modprobe i2c-dev
    root@myth:~# i2cdetect
    Error: No i2c-bus specified!
    Syntax: i2cdetect [-f] [-q|-r] I2CBUS [FIRST LAST]
    I2CBUS is an integer
    With -f, scans all addresses (NOT RECOMMENDED)
    With -q, uses only quick write commands for probing (NOT RECOMMENDED)
    With -r, uses only read byte commands for probing (NOT RECOMMENDED)
    If provided, FIRST and LAST limit the probing range.
    i2cdetect -l lists installed busses only
    Installed I2C busses:
    i2c-2 unknown ivtv i2c driver #0 Algorithm unavailable
    i2c-1 unknown SMBus nForce2 adapter at 5100 Algorithm unavailable
    i2c-0 unknown SMBus nForce2 adapter at 5000 Algorithm unavailable
    root@myth:~# tail -f /var/log/syslog
    Jul 18 14:06:31 myth kernel: ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    Jul 18 14:06:31 myth kernel: tuner 2-0061: type set to 50 (TCL 2002N)
    Jul 18 14:06:31 myth kernel: ivtv0: Initialized WinTV PVR 150, card #0
    Jul 18 14:06:31 myth kernel: ivtv: ==================== END INIT IVTV ====================
    Jul 18 14:06:44 myth ntpd[4646]: frequency error -512 PPM exceeds tolerance 500 PPM
    Jul 18 14:06:45 myth kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Jul 18 14:06:45 myth kernel: lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    Jul 18 14:06:45 myth kernel: lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    Jul 18 14:06:45 myth kernel: lirc_pvr150: ivtv i2c driver #0: no devices found
    Jul 18 14:07:05 myth kernel: i2c /dev entries driver

  105. 105
    Tim Schall Says:

    First off let me thank you for a very clear set of instructions that worked as they were supposed to and a piece of source code that compiled correctly. Now my problem.

    I’ve got a ‘whtie box’ computer with a Hauppauge PVR150 card. I’m using the stock IR receiver/emitter that came with the card and the stock remote. I’m using your prepatched source code. The system is running SuSE 10.0 with all updates installed and the latest version of MythTV. I’m attempting to control an external Samsung SIR-S300W DirecTV set top box. It works. Sort of. The code sets and ‘send_power now’ script indicate that I need to use the code set that appears around 1_373_. At least that’s the one that turns my receiver on and off. All I want to send is the numbers 0-9. Relevant part of the code set snipped here:

    name 1_373_KEY_0
    2171928576
    name 1_373_KEY_1
    2171928577
    name 1_373_KEY_2
    2171928578
    name 1_373_KEY_3
    2171928579
    name 1_373_KEY_4
    2171928580
    name 1_373_KEY_5
    2171928581
    name 1_373_KEY_6
    2171928582
    name 1_373_KEY_7
    2171928583
    name 1_373_KEY_8
    2171928584
    name 1_373_KEY_9
    2171928585

    Some of the numbers get sent correctly. Some do not. The receiver is consistant in its responses. I hacked up the lirc.conf.all file and came up with the following:

    name 0
    # 2171928576
    2171928583
    name 1
    # 2171928577
    2171928584
    name 2
    # 2171928578
    2171928577
    name 3
    # 2171928579
    2171928578
    name 4
    # 2171928580
    2171928579
    name 5
    2171928581
    name 6
    # 2171928582
    2171928580
    name 7
    # 2171928583
    2171928581
    name 8
    # 2171928584
    2171928582
    name 9
    2171928585

    Now, 0, 2, 3, 4, 6, 7, and 8 are all sent correctly. Using any of the channel_change scripts I’ve found and sending 1 or 5 produce no reaction from the receiver and 9 brings up the mini-guide. All of these behaivors are constant and repeatable. Using the receivers own, stock remote, produces very normal results from the receiver in all instances.

    Any thoughts on this one? I’d be glad to provide whatever info anyone would require to help resolve this.

    Tim Schall
    grover@fortgirlfriend.com

  106. 106
    raj Says:

    Hi mark,

    I can’t find /dev/lircd …it’s showing no such file or directory.
    What I have to do now.
    which driver I have to install and where could I find it?

    Thank you,

    Raj.

  107. 107
    Simon Baxter Says:

    I was using the lirc source at the top of this page, but it didn’t work with my 2.6.17 kernel. Grabbed the one above http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2

    and it works a treat!!

    A new query though. The key repeat strokes from the remote are staggered and a bit slow – especially when scrolling down long menus, or FF/REW tracking through a video clip. Is there any way to make this smoother? Or at least reduce the interval?

    Thanks!

  108. 108
    infringer Says:

    I can get the remote running but the script will not function and trying to test

    [root@localhost Desktop]# ./send_power_new
    bash: ./send_power_new: Permission denied

    its odd everytime I reboot it seems as if I have to recreate the lirc0 directory.

    It must not be working for some odd reason using ivtv 4.6 and lirc-0.8.0pre4-pvr150 and change_chan.pl for codeset for motorola DCT2244 the hardware is pvr-150 non mce…

    I know its all configured right because I do understand what is supposed to be happening

    oddly enough lircd doesnt show up in available services to start for my computer at boot

    anyways any help would be nice really

  109. 109
    infringer Says:

    by the way the remote works when I get it running flawlessly but, the irblaster fails miserably and I’m running mandriva 2006

  110. 110
    Russ Says:

    Mark,

    I am running KnoppMyth R5C7 and have not been able to get my PVR-150 irblaster working. My OVR-150 is the second of three tuner cards, the first and thir being a PVR-250. I have posted detailed findings at:

    http://mysettopbox.tv/phpBB2/viewtopic.php?t=10919

    It’s pretty long and in the interest of saving space I am posting the link rather than the entire contents here. (If you’re prefer that I post everything here please advise).

    Any of your insight to get me over the hump would be greatly appreciated!

    Best regards,
    Russ

  111. 111
    Russ Says:

    Mark/all,

    I got it working, there were two problems:

    1) when lirc_pvr150 is loaded, there is no need to specify /dev/lirc1 as it assigned the first card with an IR blaster (which was the second card in my system) as /dev/lirc.

    2) doing a make install of lirc-for-cecil.tar.bz2 placed the binaries in /usr/lical/sbin and /usr/local/bin, leaving the existing lirc binaries in /usr/sbin and /usr/bin. I renamed the old binaries and moved the new ones in their place and….

    VOILA the blaster LED now flashes and the remote works.

    Now for the next – fatal – problem:

    None of the send_power_new commands work on my Scientific Atlanta 4200. Turns out Hauppauge does not support this STB in their firmware, and I don’t believe there is any mechanism for adding unsupported codes.

  112. 112
    Dave Germiquet Says:

    Hi,

    I’m getting the same issue

    response:
    lircd: error in configfile line -2147483648:
    lircd: Segmentation fault

    With kernel 2.6.16.. from the log files it looks like the blaster is loading fine and all but when i run /usr/local/sbin/lircd –device=/dev/lirc0 /etc/lircd.conf

    i get the above error any ideas?

  113. 113
    Dave Germiquet Says:

    i think its the AMD64 bug as tha ti havesorry i missed the previous post

  114. 114
    Dave Germiquet Says:

    Hi All I am getting this error message when trying to use lircd

    i run

    lircd –device=/dev/lirc0

    lircd “2147483648″: must be valid lirc_t number
    ircd: reading config file faield (im using the for-cecil.tar.bz2 any ideas on how to fix it
    lircd appears to be running
    the modules are loaded properly…

  115. 115
    Dave Germiquet Says:

    it appears the Normal Remote control works… with the hauppauge config with lircd however… i cant get the included lircd.conf to work.. is there any updates to the lircd.conf?

  116. 116
    Dave Germiquet Says:

    Sorry for the added comments:

    I’ll make a retake. When using the lircd.conf mentioned on this page i get this error message:

    when running lircd

    lircd “2147483648″: must be valid lirc_t number
    ircd: reading config file failed

    However when I use the Hauppauge lirc config file from the irc-0.8.1-cvspvr150 directory it works
    (I do know that the blaster needs the one on this page)

    So how do i get it to work?

  117. 117
    mark Says:

    Noah: please actually run this on the ivtv-i2c bus, something like:

    i2cdetect -l (find ivtv bus number)
    i2cdetect -a [bus number]

    Tim: the only think I can say is to try another codeset. Unfortunately I can’t do anything at all with what the blaster sends to the STB; I can only copy what the hauppauge driver does.

    Raj: /dev/lircd gets created when you run lirc. Please read step 7 carefully, or if you are still stuck I don’t mind having a poke around via SSH.

    Simon: Have you tried setting repeat= down a bit in .lirrc? If you’ve already done that, then you’ve hit the rubbish firmware on the Zilog chip. I have fiddled around with it, but it appears the current IR sample is destroyed when you poll the chip, so basically if you poll it too frequently then you get no IR response at all. So you can’t improve responsiveness by checking more frequently, and you have to have quite a gap between repeats.

    infringer: chmod 0755 ./send_power_now & ./send_power_new maybe?

    Russ: I’m glad you got it working, might be worth checking with Hauppauge if they have support for the box or not yet. If they do have a driver with support the codeset dump can be updated, otherwise you are correct in that I can’t do anything with it.

    Dave: I’ve not seen that other than with really old versions, are you sure it isn’t picking up lircd from another location? (which lircd, lircd –version). If not I guess build it with DEBUG turned on (from the configure menu), and get a backtrace in gdb.

  118. 118
    Mike Says:

    I finally got my PVR-150 today. It’s not the MCE edition, but the regular one with the jacked wire to IR receiver coming out of the back.

    I tried gentoo lirc 0.8.0-r3 with “hauppauge” driver to no avail. So I surfed on over to this site.

    I just tried your lirc patched for pvr150, with similar “no luck”.

    lirc_dev says “lirc_dev: IR Remote Control driver registered, at major 61

    But other than that, none of the drivers appear to find my IR receiver. ;-( run with “debug=1″ passed to the module, and I’m getting complete silence from them.

    Do I have a bum card?

    This is a Hauppauge WinTV-PVR-150 model 1055

  119. 119
    Noah Says:

    Hello Mark,

    Thanks again for your reply. Here’s the log:

    root@myth:~# i2cdetect -l
    i2c-2 i2c ivtv i2c driver #0 Algorithm unavailable
    i2c-1 smbus SMBus nForce2 adapter at 5100 Non-I2C SMBus adapter
    i2c-0 smbus SMBus nForce2 adapter at 5000 Non-I2C SMBus adapter
    root@myth:~# i2cdetect -a 2
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-2.
    I will probe address range 0×00-0x7f.
    Continue? [Y/n] y
    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    10: XX XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX
    20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    40: XX XX XX XX UU XX XX XX XX XX XX XX XX XX XX XX
    50: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    60: XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

  120. 120
    Dave Says:

    – dmesg –

    lirc_dev: module not supported by Novell, setting U taint flag.
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: module not supported by Novell, setting U taint fla
    g.
    lirc_pvr150: no version for “lirc_unregister_plugin” found: kern
    el tainted.
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    lirc_pvr150: poll thread started
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc
    _pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr
    150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150:
    19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21
    05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7
    c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4
    3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dli
    rc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_p
    vr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr15
    0: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5
    d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Haupp
    auge PVR-150 IR blaster: firmware version 1.3.0

    – GDB doesnt show anything to me :( just spits out error message. Im positive its the right version and i did do debug mode..

    I followed what seb did exactly

    Copyright 2005 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type “show copying” to see the conditions.
    There is absolutely no warranty for GDB. Type “show warranty” for details.
    This GDB was configured as “x86_64-suse-linux”…Using host libthread_db library “/lib64/libthread_db.so.1″.

    (gdb) set args -n -device=/dev/lirc0 -Dall
    (gdb) run
    Starting program: /usr/local/sbin/lircd -n -device=/dev/lirc0 -Dall
    lircd: error in configfile line 58:
    lircd: “2147483648″: must be a valid (lirc_t) number
    lircd: reading of config file failed
    lircd: lircd(hauppauge_pvr150) ready

    output of another command:

    Type “show copying” to see the conditions.
    There is absolutely no warranty for GDB. Type “show warranty” for details.
    This GDB was configured as “x86_64-suse-linux”…Using host libthread_db library “/lib64/libthread_db.so.1″.

    (gdb) set args -n -device=/dev/lirc0 /etc/lircd.conf
    (gdb) run
    Starting program: /usr/local/sbin/lircd -n -device=/dev/lirc0 /etc/lircd.conf
    lircd: error in configfile line 58:
    lircd: “2147483648″: must be a valid (lirc_t) number
    lircd: reading of config file failed
    lircd: lircd(hauppauge_pvr150) ready

  121. 121
    Russ Says:

    Hauppauge says support for the SA 4200 just missed their June 2006 release and will be included in the next release (date TBA). Cool.

  122. 122
    Dave Germiquet Says:

    Hi,

    Mark did you receive my previous post. gdb turns out nothing it just says lircd ready.

    I’ll post it again when i get home if need be.. It is running on a lib64 platform.

    Could that be a reason?

  123. 123
    Marc Says:

    I have followed the guide through step 5, but am not able to see the IR RX and IR TX lines in the syslog (see below). I have a new PVR 150 with hauppauge ir blaster with botht hte receiver and transmitter attached to the single plug. Any advice would be appreciated!

    Jul 26 11:20:52 localhost kernel: ivtv0: Removed Hauppauge WinTV PVR-150, card #0
    Jul 26 11:20:55 localhost kernel: ivtv: ==================== START INIT IVTV ====================
    Jul 26 11:20:55 localhost kernel: ivtv: version 0.7.0 (tagged release) loading
    Jul 26 11:20:55 localhost kernel: ivtv: Linux version: 2.6.17-1.2157_FC5 mod_unload 686 REGPARM 4KSTACKS gcc-4.1
    Jul 26 11:20:55 localhost kernel: ivtv: In case of problems please include the debug info between
    Jul 26 11:20:55 localhost kernel: ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    Jul 26 11:20:55 localhost kernel: ivtv: any module options, when mailing the ivtv-users mailinglist.
    Jul 26 11:20:55 localhost kernel: ivtv0: Autodetected Hauppauge WinTV PVR-150 card (cx23416 based)
    Jul 26 11:20:55 localhost kernel: ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
    Jul 26 11:20:55 localhost kernel: tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    Jul 26 11:20:55 localhost kernel: cx25840 1-0044: cx25841-23 found @ 0×88 (ivtv i2c driver #0)
    Jul 26 11:20:58 localhost kernel: cx25840 1-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    Jul 26 11:20:58 localhost kernel: wm8775 1-001b: chip found @ 0×36 (ivtv i2c driver #0)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: Hauppauge model 26132, rev F0B2, serial# 9329711
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0×08)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: audio processor is CX25841 (idx 35)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: decoder processor is CX25841 (idx 28)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: has no radio, has IR remote
    Jul 26 11:20:59 localhost kernel: ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    Jul 26 11:20:59 localhost kernel: ivtv0: Encoder revision: 0×02050032
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    Jul 26 11:20:59 localhost kernel: tuner 1-0061: type set to 50 (TCL 2002N)
    Jul 26 11:21:00 localhost kernel: ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    Jul 26 11:21:00 localhost kernel: ivtv: ==================== END INIT IVTV ====================
    Jul 26 11:21:00 localhost kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Jul 26 11:21:00 localhost kernel: lirc_pvr150: bt878 #0 [sw]: no devices found

  124. 124
    raj Says:

    Hi mark,
    Please do that for me through SSH…I am facing big trouble as I am new to Linux OS.

    Thanks a lot

  125. 125
    raj Says:

    Hi mark,
    when i ran the command below it has shown no such directory..
    ls -l /dev/lirc*

    Then I tried :

    mknod /dev/lirc0 c 61 0

    now when i ran irw again it is showing no such file or directory!

    What should I have to do now?

  126. 126
    Marc Says:

    Mark,

    Please ignoere my previous post – I saw the link above to the lirc_for_Cecil version and that is working much better for me with the latest stock Fedore core 5 2.6.17 kernel. I can now see the transmitter flash, but my Scientific Atlanta 3250 (key 78) does not respond to the transmissions. I have the transmitter placed directly in front of the 3250′s receiver, so I’m not sure what else I can try. Any ideas?

    Thank you for your efforts on this project. I can’t wait to get it all working!

    raj,

    I had the same problems you’re having until I tried the lirc_for_Cecil version (seearch for the link above). You should try that if you’re using a 2.6.17 kernel.

    Marc

  127. 127
    Dave Germiquet Says:

    If you require ssh access that can be arranged.

  128. 128
    mark Says:

    Mike: Sounds like you have a 2.6.17 kernel, try this one: http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2

    Noah: no chip, no dice unfortunately. Like Simon, you could have a bad card, can you try it in a Windows machine and see if it works?

    Dave: sounds like a lirc bug, with ssh access and an hour or two I should be able to sort it out. If you are happy with this you can email details (mark@npsl.co.uk), obviously I’ll need root access to muck about with devices ;)

    Marc: 2.6.17 maybe, see answer to Mike? Oh right, I see you did ;) I’d try all the codesets to see if it responds to anything at all, there is often something that matches well enough. If not, then you’d have to bug hauppauge about it.

    raj: send SSH details to my email address (mark@npsl.co.uk), and I’m happy to have a go at sorting it out.

    Russ: oh dear, I hope you have access to a Windows machine ;) I don’t have a spare PVR-150 and the codeset capture process is… umm… interesting!

  129. 129
    Chris Says:

    I had this running beautifully for months until a brown out a messed everything up. So I started from scratch, installed the latest ivtv module and tried the 7.2 and 8.0 patched lirc. I even replaced the card because at first I thought it fried the card because it was in use during the brownout. But i am having problems getting the remote to work. here is the dmesg dump from modprobe lirc_pvr150 debug=1. I have recompiled both version twice from a fesh download and still have the same problem. Any ideas would be helpful. Also i tried modprobe ivtv newi2c=0 and ivtvctl –reset-ir without any results.

    lirc_dev: IR Remote Control driver registered, at major 61
    tuner 0-0061: TV freq (0.00) out of range (44-958)
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_pvr150: poll thread ended

  130. 130
    John Miller Says:

    In reference to Dave Germiquet’s post, I am having the same problem on my AMD64 system running Gentoo. I also used the lirc_for_Cecil version, so Dave you are not alone, it does sound like a lirc bug involving the x86_64 arch. I would be glad to help if there is anything I can do.

  131. 131
    mark Says:

    Chris: Sounds like an old bug, can you try the latest version?

    John: I had a poke around on Dave’s machine last night and found out what the issue was, it should be fixed now.

    Latest version: http://www.blushingpenguin.com/mark/lmilk/lirc-0.8.1-CVS-pvr150.tar.bz2

    HTH,

    Mark

  132. 132
    Noah Says:

    Mark,

    Thanks again. Yes, it works like a champ in windows – and I think I mentioned in my first post that it previously worked in linux in another machine. AIEEEEEE! :)

  133. 133
    infringer Says:

    Why in the world dont hauppauge support the many popular cable boxes is beyond me it appears that this is one of the biggest issues with lirc simply lack of support in sending IR codes. Why is it not fesible for hauppauge to allow open source support and development for there cards IR blaster? Are they afraid that someone will steal there work or give out files that will produce buffer overflow volnerabilities? Its a shame my ReplayTV sonic blue and it’s IR blaster worked flawlessly. I’m thinking that the most configureable option would be to use a serial port based device as it would beable to reproduce anything with and is very user configureable like the rest of mythtv setup. I’m thinking the best idea would be to make my own IR blaster using the serial port and a little bit of solder with an IR transmitter. Any IR device should be able technically follow suit of any other IR device if configured right correct? IR standard should be a regulated by the FCC for home use electronics therefore should have to follow guidelines and standards.

    Now anyone have a nice link to a newbie guide of some sort so I can purchase an IR transmitter and get out the soldering iron solder up most likely a few wires to the transmitter and possibly resistors if required.

  134. 134
    Chris Says:

    I gave the new CVS version a try and I am having the same exact problem.

  135. 135
    infringer Says:

    Anyone get this working with a DCT2244 by Motorola?

    If so please do explain,

    It is difficult to understand weather or not my box is supported because they dont specifically specify weather or not it is supported by the driver they specify Motorola and a set of codes all tried out in windows with no luck, To me that tells me it is an unsupported cable box which is quite a pain in the arse. You purchase a product in the event that you want it to operate in a specific manner then the son of a gun will not even operate as planned horrible and horrible support to not exactly ease of use I paid for.

    I think we should get everyone to flood hauppuge with requests for open source support! Get Google to email them for christ sakes to help the summer of code guys develop mythtv to a greater potential as well.

    I have a serial port on the back of my digital cable box but am unsure weather or not its supported to use as an IR blaster or not I have some tests yet to run on my end before I conclude my own investigation into getting this thing running but I will keep on keeping on.

    In the mean time please if you read this:

    Email

    >> Contact Us

    Hauppauge Headquarters, NY
    Hauppauge Computer Works, Inc.
    91 Cabot Court
    Hauppauge, NY 11788
    tel: 631.434.1600
    fax: 631.434.3198
    Sales:
    sales@hauppauge.com
    Tech Support:
    tel: 631.434.3197
    techsupport@hauppauge.com
    Click here to visit our support page
    Investor Relations:
    Jerry Tucciarone
    tel: 631.434.1600 ext.306
    jtucciarone@hauppauge.com

    TIA

  136. 136
    mark Says:

    Noah: hmm, well if it doesn’t work with either i2c driver (newi2c=0 or 1 which is the default), then I’m a bit stumped. It’s probably a timing issue, and you might be able to fiddle around introducing delays (in the ivtv driver). Does the rest of the ivtv hardware function ok? That chip has a software i2c implementation which is quite sensitive to timing, so it could be the case. Also, to be clear, does it work with Windows _on the same motherboard_?

    Chris: Can I have a poke via SSH? The poll thread shouldn’t be committing suicide (there was a quite old bug that did that, so I suppose that there could be something else along the same lines).

    infringer: If Hauppauge don’t support the box, the only thing you can do is bug them and hope/wait. Otherwise, see http://www.lirc.org/ for instructions on building a serial port blaster. I agree that it’s a frustrating situation, but there’s not a lot I can do about it. I’ve had direct contact with Hauppauge and they are unwilling to release any further details of the software running on the Zilog chip, I am not clear for what reason.

  137. 137
    Noah Says:

    Mark,

    Yes, the rest of the ivtv system works great. Worked in windows with this same motherboard. Worked in windows and linux with a different motherboard.

    Thanks!

  138. 138
    infringer Says:

    [root@localhost lirc-0.8.1-CVS-pvr150]# modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.12-12mdk/misc/lirc_pvr150.ko): Invalid module format

  139. 139
    infringer Says:

    Errr dang wish there was an edit button on these posts…

    I wonder if its because I most likely need an earlier version of lirc with my kernel…

    like 0.7.2 or something

    anyways the remote was working I rebooted and above this post my previous post was the error I recieved trying to get it going again … oddly enough I can try and reinstall and the whole 9yds and no such luck … Dang mandriva or something …

    Anyways the name of the chip is not familiar I wonder what kind of assembly they are using is this a simple eeprom chip I take it if so what kind of processor is being used. Maybe some folks could just simply reverse engineer there software like it or not… If they aint going to support there hardware then hack it thats the rule of the future, and the rule of now …

    Anyhow mark you have a good one.

  140. 140
    infringer Says:

    Update it appears the zilog z8 is the chip they are using and from the looks of it the z8 is an updated version of the z80 so in all actuality the z80 disassembler should work relitively well… It seems as if it is one pin programmable…

    Alls we need is for someone to build a firmware for this thing to dump the rom then we have the OS being used by hooking some routine we can force the chip to dump the rom simply by programming a nicely crafted flash we then flash the chip dump the rom disassemble it using something like IDA or TASM30 using the z80 as a common reference.

    heres some pretty basic 8bit opcodes used within the z80 as an example…

    Z80 Opcode Listing
    Z-80 CPU Instruction Set
    —- — ———– —

    ADC HL,ss Add with carry register pair ss to HL.
    ADC A,s Add with carry operand s to accumulator.
    ADD A,n Add value n to accumulator.
    ADD A,r Add register r to accumulator.
    ADD A,(HL) Add location (HL) to acccumulator.
    ADD A,(IX+d) Add location (IX+d) to accumulator.
    ADD A,(IY+d) Add location (IY+d) to accumulator.
    ADD HL,ss Add register pair ss to HL.
    ADD IX,pp Add register pair pp to IX.
    ADD IY,rr Add register pair rr to IY.
    AND s Logical AND of operand s to accumulator.
    BIT b,(HL) Test bit b of location (HL).
    BIT b,(IX+d) Test bit b of location (IX+d).
    BIT b,(IY+d) Test bit b of location (IY+d).
    BIT b,r Test bit b of register r.
    CALL cc,nn Call subroutine at location nn if condition CC is true.
    CCF Complement carry flag.
    CP s Compare operand s with accumulator.
    CPD Comapre location (HL) and acc., decrement HL and BC,
    CPDR Perform a CPD and repeat until BC=0.
    CPI Compare location (HL) and acc., incr HL, decr BC.
    CPIR Perform a CPI and repeat until BC=0.
    CPL Complement accumulator (1′s complement).
    DAA Decimal adjust accumulator.
    DEC m Decrement operand m.
    DEC IX Decrement IX.
    DEC IY Decrement IY.
    DEC ss Decrement register pair ss.
    DI Disable interrupts.
    DJNZ e Decrement B and jump relative if B=0.
    EI Enable interrupts.
    EX (SP),HL Exchange the location (SP) and HL.
    EX (SP),IX Exchange the location (SP) and IX.
    EX (SP),IY Exchange the location (SP) and IY.
    EX AF,AF’ Exchange the contents of AF and AF’.
    EX DE,HL Exchange the contents of DE and HL.
    EXX Exchange the contents of BC,DE,HL with BC’,DE’,HL’.
    HALT Halt computer and wait for interrupt.
    IM 0 Set interrupt mode 0.
    IM 1 Set interrupt mode 1.
    IM 2 Set interrupt mode 2.
    IN A,(n) Load the accumulator with input from device n.
    IN r,(c) Load the register r with input from device (C).
    INC (HL) Increment location (HL).
    INC IX Increment IX.
    INC (IX+d) Increment location (IX+d).
    INC IY Increment IY.
    INC (IY+d) Increment location (IY+d).
    INC r Increment register r.
    INC ss Increment register pair ss.
    IND (HL)=Input from port (C). Decrement HL and B.
    INDR Perform an IND and repeat until B=0.
    INI (HL)=Input from port (C). HL=HL+1. B=B-1.
    INIR Perform an INI and repeat until B=0.
    JP (HL) Unconditional jump to location (HL).
    JP (IX) Unconditional jump to location (IX).
    JP (IY) Unconditional jump to location (IY).
    JP cc,nn Jump to location nn if condition cc is true.
    JR C,e Jump relative to PC+e if carry=1.
    JR e Unconditional jump relative to PC+e.
    JR NC,e Jump relative to PC+e if carry=0.
    JR NZ,e Jump relative to PC+e if non zero (Z=0).
    JR Z,e Jump relative to PC+e if zero (Z=1).
    LD A,(BC) Load accumulator with location (BC).
    LD A,(DE) Load accumulator with location (DE).
    LD A,I Load accumulator with I.
    LD A,(nn) Load accumulator with location nn.
    LD A,R Load accumulator with R.
    LD (BC),A Load location (BC) with accumulator.
    LD (DE),A Load location (DE) with accumulator.
    LD (HL),A Load location (HL) with accumulator.
    LD dd,nn Load register pair dd with nn.
    LD dd,(nn) Load register pair dd with location (nn).
    LD HL,(nn) Load HL with location (nn).
    LD (HL),r Load location (HL) with register r.
    LD I,A Load I with accumulator.
    LD IX,nn Load IX with value nn.
    LD IX,(nn) Load IX with location (nn).
    LD (IX+d),n Load location (IX+d) with n.
    LD (IX+d),r Load location (IX+d) with register r.
    LD IY,nn Load IY with value nn.
    LD IY,(nn) Load IY with location (nn).
    LD (IY+d),n Load location (IY+d) with value n.
    LD (IY+d),r Load location (IY+d) with register r.
    LD (nn),A Load location (nn) with accumulator.
    LD (nn),dd Load location (nn) with register pair dd.
    LD (nn),HL Load location (nn) with HL.
    LD (nn),IX Load location (nn) with IX.
    LD (nn),IY Load location (nn) with IY.
    LD R,A Load R with accumulator.
    LD r,(HL) Load register r with location (HL).
    LD r,(IX+d) Load register r with location (IX+d).
    LD r,(IY+d) Load register r with location (IY+d).
    LD r,n Load register r with value n.
    LD r,r’ Load register r with register r’.
    LD SP,HL Load SP with HL.
    LD SP,IX Load SP with IX.
    LD SP,IY Load SP with IY.
    LDD Load location (DE) with location (HL), decrement DE,HL,BC.
    LDDR Perform an LDD and repeat until BC=0.
    LDI Load location (DE) with location (HL), incr DE,HL; decr BC.
    LDIR Perform an LDI and repeat until BC=0.
    NEG Negate accumulator (2′s complement).
    NOP No operation.
    OR s Logical OR of operand s and accumulator.
    OTDR Perform an OUTD and repeat until B=0.
    OTIR Perform an OTI and repeat until B=0.
    OUT (C),r Load output port (C) with register r.
    OUT (n),A Load output port (n) with accumulator.
    OUTD Load output port (C) with (HL), decrement HL and B.
    OUTI Load output port (C) with (HL), incr HL, decr B.
    POP IX Load IX with top of stack.
    POP IY Load IY with top of stack.
    POP qq Load register pair qq with top of stack.
    PUSH IX Load IX onto stack.
    PUSH IY Load IY onto stack.
    PUSH qq Load register pair qq onto stack.
    RES b,m Reset bit b of operand m.
    RET Return from subroutine.
    RET cc Return from subroutine if condition cc is true.
    RETI Return from interrupt.
    RETN Return from non-maskable interrupt.
    RL m Rotate left through operand m.
    RLA Rotate left accumulator through carry.
    RLC (HL) Rotate location (HL) left circular.
    RLC (IX+d) Rotate location (IX+d) left circular.
    RLC (IY+d) Rotate location (IY+d) left circular.
    RLC r Rotate register r left circular.
    RLCA Rotate left circular accumulator.
    RLD Rotate digit left and right between accumulator and (HL).
    RR m Rotate right through carry operand m.
    RRA Rotate right accumulator through carry.
    RRC m Rotate operand m right circular.
    RRCA Rotate right circular accumulator.
    RRD Rotate digit right and left between accumulator and (HL).
    RST p Restart to location p.
    SBC A,s Subtract operand s from accumulator with carry.
    SBC HL,ss Subtract register pair ss from HL with carry.
    SCF Set carry flag (C=1).
    SET b,(HL) Set bit b of location (HL).
    SET b,(IX+d) Set bit b of location (IX+d).
    SET b,(IY+d) Set bit b of location (IY+d).
    SET b,R Set bit b of register r.
    SLA m Shift operand m left arithmetic.
    SRA m Shift operand m right arithmetic.
    SRL m Shift operand m right logical.
    SUB s Subtract operand s from accumulator.
    XOR s Exclusive OR operand s and accumulator.

    More information can be found at:

    http://dmoz.org/Computers/Programming/Languages/Assembly/Z80/

    dunno really how to start but know where to start if you wanna have full control of this without depending on belated drivers.

    Enjoy,
    infringer

  141. 141
    Akshat Says:

    Hi Mark,

    Thanks a lot for your work. I finally managed to get my PVR 150 IR Blaster working with my cable box. For reference, the Scientific Atlanta 4200 cable box works with the codeset 41. This is the box that Cablevision uses in NY/NJ. There was someone who commented on your blog that he couldn’t get it to work with the 4200. My comment to him is to be absolutely sure that the IR led is right in front of the sensor, which you can locate by shining a bright light into the main LCD window. Even if it is a cm off, the cable box will not respond.

  142. 142
    Tor :: Mythtv and remote problem Says:

    [...] BTW. I have tried everything I can see that is relevant on Mark’s Braindump. [...]

  143. 143
    mark Says:

    infringer: not compiled against the running kernel. Unfortunately, I don’t have the time or the inclination to disassemble a bunch of Z80 assembly. The firmware is poorly written anyway, so would probably need redoing, and that’s a big task that would almost certaintely ultimately require people to modify their cards. Someone from Hauppauge contacted me offering to give me the kit to write some sane firmware about 6 months ago, I was interested but they never followed up. If you want a project then have fun, sounds like a good one ;)

    Akshat: cool, glad you got it working. Yes, the IR range is very short, that’s because it’s not an IR transmitter at all, it’s just a red LED. Shocking, eh?

    Mythtv and remote problem: er, what?

  144. 144
    Noah Says:

    Mark,

    Thanks again for the help thus far. Are they any good pages out there that document how to adjust the timing/delays? Any other suggestions?

    Thanks!

  145. 145
    Dave Says:

    Hi guys,

    I’m using a Scientific Explorer 3200 and it is in the codeset as 78 however 0_78 and 1_78 doesn’t work.

    Its rogers cable do they switch the remote control? or is it standard

  146. 146
    Dave Says:

    Oh ya the light goes on the infared when its working.

  147. 147
    Dave Says:

    woo hoo it works however i had to tape it on the box :) Cuz its short ranged.

  148. 148
    Chris K Says:

    I’ve been away for a while. I did a fresh install and gave it a try again, but no luck with the cvs version again. let me know how to send you the info to SSH into my box.

  149. 149
    Chris K Says:

    Mark,

    Let me know how to send the SSH info over to let you int. I’ll have to set the router up to let you in.

    I decided to redo the install with a extensive format but I am still having the same issue, but when you look arouind you will see what is going on.

  150. 150
    Mike Says:

    I’m having a slight newbie problem.

    When I use the channel_change script, I get the following error:

    /usr/local/bin/irsend: command failed: SEND_ONCE 0_78 5
    /usr/local/bin/irsend: unknown command: “5″

    What have I done wrong?

  151. 151
    Russ Says:

    Akshat –

    I’m the guy who is having trouble getting the 4200 to respond. I created this script which continually repeats the following two lines (which I think are the correct ones – codeset 41):

    #!/bin/sh
    while :
    do
    irsend SEND_ONCE blaster 0_41_KEY_POWER
    irsend SEND_ONCE blaster 1_41_KEY_POWER
    done

    Then while the script is running I moved the emitter in front of the ir sensor, trying to find the sweet spot, with no luck.

    I’m wondering: 1) which firmware file are you using, and 2) are the above commands the right ones for codeset 41?

    Another thought – has anyone tried replacing the red LED with a true IR LED?

    Thanks,
    Russ

  152. 152
    Russ Says:

    Futher to my last post – success!

    I replaced the red LED with an IR LED scavenged from an old VCR remote I had laying around and codeset 41 works perfectly with my 4200 now.

  153. 153
    Erland Isaksson’s blog » Blog Archive » Installation of IR receiver and VFD Says:

    [...] References venky.ws Mark’s Braindump [...]

  154. 154
    mark Says:

    Sorry for the lack of response. I haven’t had the heart to go through the >100 spam messages until now, hopefully I’ve sorted that out by adding a captcha though.

    Chris K: if you are still interested, just send it to my email address (mark@npsl.co.uk).
    Mike: what was the command line that you ran the script with?
    Russ: cool ;)

  155. 155
    Raj Says:

    Hi Mark,
    I am setting Ir Blaster for my Hauppauge pvr 150 card using ur very good site!
    I succeeded in getting the output when I press keys of remote .
    Now I am in the Trickest part.
    I am using two DVBs
    1.HUMAX ND-1000C

    2.Zenega CD-1004S

    So,What should I have to do now?
    I haven’t found the codesets for my HUMAX or Zenega in the codesets file you included.
    And one more thing,how do I have to use those change channel script and power script for my IR remote?

    Please help me regarding!

    Thank you

    Raj

  156. 156
    Raj Says:

    Hi,
    when I tried power_send script I can’t recognize the code set for my HUMAX ND-1000C.

    irsend: command failed: SEND_ONCE blaster 0_0_KEY_POWER
    irsend: unknown remote: “blaster”

    Apart from that everything is working fine and my remote is working with myth tv also.But the chage_channekl script failing and it’s giving the following message…..

    /usr/local/bin/change_channel.sh 12
    channel changing 12
    /usr/local/bin/irsend: command failed: SEND_ONCE blaster 1
    /usr/local/bin/irsend: unknown remote: “blaster”

    So help me regarding the power_send problem?!

  157. 157
    mark Says:

    You are using the wrong lircd.conf.

  158. 158
    raj Says:

    Hi mark,
    Where can I egt correct lircd.conf file??
    Please send me if u have one working.
    Or else tell me where can I find.
    Or how can I create for myself .

    Thank you very much.

    Raj

  159. 159
    mark Says:

    step 6

  160. 160
    raj Says:

    So do I have to replace this with the existing one which i have?

  161. 161
    Raj Says:

    Hi Mark,

    One more question?

    When I try to schedule Myth TV it ‘s recording blank screen only.I tried scanning channels for Tuner,Composite 0,S-video but failed to record ?!
    I can able to watch live TV well but while scheduling my favorite programs it’s recording Blank!

    What ‘s the problem might be?
    Is that the matter with IR Blaster?Do I have to have working IR Blaster to schedule programs?
    Do I have to use any channel change script?
    In my mythbackend log it’s showing message like DVB not connected to capture card?
    How can In solve this??
    Please suggest me this !

    Thanks for your help!

    Raj

  162. 162
    aviv Says:

    Hi Mark-
    huge thanks for writing this- it helps a LOT.
    i’ve followed Hymas instructions at the beginning (http://hyams.webhop.net/mythtv/myth_ubuntu.html) to isntall lirc, but now that i need the IR Blaster, I’m trying to follow your guide-
    I configured, maked and installed, placed the haup-ir-blaster.bin in /lib/firmware, where current ivtv firmware is, but when i wroet “modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1″ i got nothing back.

    any idae why?

    thanks!
    aviv.

  163. 163
    George Says:

    Mark you rock! Worked like a charm. Only glitch (aside from newbie stuff which I figured out) was I had to do a cold reboot. Very strange.

    Thanks.

  164. 164
    Adolfo Says:

    In Ubuntu Dapper, haup-ir-blaster.bin must go in /lib/modules/`uname -r`, not in /lib/firmware as the ivtv stuff.

  165. 165
    KALYAN Says:

    SIR,
    I HAVE ZENEGA CD 1004S SET TOP BOX REGISTERED WITH DISH TV INDIA(OF ZEE NETWORKS). THIS WORKED FINE WITH DISH TV PACKAGES AND ALSO I HAD NO PROBLEM IN TUNNING TO OTHER LNBs MAY IT BE C BAND OR Ku BAND THROUGH DISQC SWITCH. ON 4TH OF SEPTEMBER A AUTOMATIC SOFTWARE UPGRADE HAPPENED THROUGH DISH AND A FRESH NEW MENU HAS STARTED. HOWEVER THIS IS NO LONGER BENEFICIAL FOR ME. NOW I CANNOT TUNE TO THE OTHER LNB”S
    AND WHEN I TRIED TO CHANGE THE LNB FREQUENCY FROM 10600 TO 5150 FOR C BAND , THE SET HAS BECOME LOCKED AND NOW I CANNOT EVEN ENTER MENU. IT DISPLAYS NO SERVICE INSTALLED PLEASE SEARCH
    TP BY CONNECTING TO DISH. BUT ALREADY LNB FREQUENCY IS FOR C BAND AND SINCE I CANNOT ENTER MENU SO IT IS NOT POSSIBLE TO CHANGE THE LNB FREQUENCY ANY MORE AND THE SET CANNOT SEARCH THE TP AS THE TPs FED ARE FOR Ku BAND . PLEASE TELL ME HOW CAN I RESET THE SET TO THE PREVIOUS SOFTWARE OR FACTORY RESET BY PRESSING SOME COMBINATION OF KEYS SO THAT THE SET BECOMES USEABLE ONCE MORE. MAY CONTACT ME AT dgp_kalyan@rediffmail.com
    I WILL REMAIN THANKFULL TO YOU FOR EVER IF YOU CAN PLEASE SEND ME A SOLUTION. KALYAN

  166. 166
    Todd Says:

    Hi Mark,

    Thanks for this walkthrough. I’m currently setting it up on a debian etch system with kernel 2.6.15 and ivtv 0.4.5 (installed using module-assistant in debian). I have two 150 cards installed in the system (1 MCE version and one that comes with the blaster and remote).

    So far I can get up to step 8, but irw doesn’t return anything when I point the remote at it. It comes with the newer silver remote (red green yellow and blue buttons on the bottom). Below is my output from syslog. Any help would be greatly appreciated.

    Thanks.

    Sep 10 19:09:16 localhost kernel: lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: ivtv i2c driver #0: no devices found
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: probe 0×70 @ ivtv i2c driver #1: yes
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: probe 0×71 @ ivtv i2c driver #1: yes
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: chip found with RX and TX
    Sep 10 19:09:16 localhost kernel: ivtv1: i2c attach to card #1 ok [client=Hauppauge PVR150 IR RX, addr=71]
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: poll thread started
    Sep 10 19:09:16 localhost kernel: ivtv1: i2c attach to card #1 ok [client=Hauppauge PVR150 IR TX, addr=70]
    Sep 10 19:09:16 localhost kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Sep 10 19:09:16 localhost kernel: lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: firmware of size 248009 loaded
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: 637 codesets loaded
    Sep 10 19:09:16 localhost kernel: lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    Sep 10 19:09:36 localhost kernel: lirc_dev (lirc_pvr150[0]): open called
    Sep 10 19:09:36 localhost kernel: lirc_dev (lirc_pvr150[0]): ioctl called (0×80046900)
    Sep 10 19:09:36 localhost kernel: lirc_dev (lirc_pvr150[0]): ioctl called (0×40046911)
    Sep 10 19:09:36 localhost kernel: lirc_dev (lirc_pvr150[0]): ioctl called (0×40046912)
    Sep 10 19:09:36 localhost kernel: lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    Sep 10 19:09:36 localhost kernel: lirc_dev (lirc_pvr150[0]): poll called
    Sep 10 19:09:36 localhost kernel: lirc_pvr150: poll called
    Sep 10 19:09:36 localhost kernel: lirc_pvr150: poll result = 0
    Sep 10 19:09:36 localhost kernel: lirc_pvr150: key (0×00/0×00)
    Sep 10 19:10:00 localhost last message repeated 91 times
    Sep 10 19:10:00 localhost kernel: lirc_dev (lirc_pvr150[0]): poll called
    Sep 10 19:10:00 localhost kernel: lirc_pvr150: poll called
    Sep 10 19:10:00 localhost kernel: lirc_pvr150: poll result = 0
    Sep 10 19:10:00 localhost kernel: lirc_dev (lirc_pvr150[0]): close called
    Sep 10 19:10:00 localhost kernel: lirc_pvr150: key (0×00/0×00)

  167. 167
    Tony Says:

    The tuner and ir receiver work great. I’m running fc5, 2.6.17-1.2174_FC5smp #1 SMP and mythtv works fine as well. I think I followed your directions but I can’t seem to get lirc_pvr150 to control my Scientifc Atlanta 2100. I ran the send_power_new script but no joy. The codeset page indicated set 78 should work with my STB. I modified my lircd.conf to use 0_78.

    When I issue a command to change the STB to channel 5, the led blinks but does not change the channel. Here is the information from dmesg:

    On boot up:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    lirc_pvr150: poll thread started
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be
    32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 2
    5 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_p
    vr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0
    a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    when I issue a change_channel command:

    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: 01 60 b3 9b 2blirc_pvr150: 05 fc 06 05 78lirc_pvr150: 09 73 00 26 05lirc_pvr150: 0d 5b 90 43 dflirc_pvr150: 11 7a 58 db 04lirc_pvr150: 15 0e 9e f4 9alirc_pvr150: 19 cf cf 3a 2dlirc_pvr150: 1d 32 d4 3d 4blirc_pvr150: 21 3b 14 40 c6lirc_pvr150: 25 2b 68 15 9dlirc_pvr150: 29 0e ea 6f 29lirc_pvr150: 2d 66 59 1f 6dlirc_pvr150: 31 2e 74 26 48lirc_pvr150: 35 17 25 58 f9lirc_pvr150: 39 3c 4e 88 e8lirc_pvr150: 3d ad 7e 8b f0lirc_pvr150: 41 81 49 94 d5lirc_pvr150: 45 80 f9 fa 87lirc_pvr150: 49 8c ff d9 falirc_pvr150: 4d a4 6f bc 30lirc_pvr150: 51 95 a2 d4 fflirc_pvr150: 55 83 60 8c 24lirc_pvr150: 59 d1 30 c5 d2lirc_pvr150: 5d cd 2b aa c9lirc_pvr150: 61 00 00 00 c9lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 4)
    lirc_pvr150: sent code 78, key 5
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: key (0×00/0×00)
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: key (0×00/0×00)
    lirc_pvr150: key (0×00/0×00)
    lirc_pvr150: key (0×00/0×00)
    lirc_pvr150: key (0×00/0×00)

    I do not have access to a windows box. Is there something I am missing?

  168. 168
    Eric Says:

    I am using the Hauppage PVR-150 with IR receiver/flasher included.

    I have loaded the lircd.conf, the firmware, and also the http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2 since I have the 2.6.17 kernel.

    Running irw catches all of the button presses okay, but the flasher doesn’t work for the reasons below.

    The syslog doesn’t show any entries after running:

    modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    And running change_channel:

    root@mythtv:/usr/local/bin# change_channel 4
    channel changing 4
    /usr/local/bin/irsend: command failed: SEND_ONCE blaster 4
    /usr/local/bin/irsend: hardware does not support sending
    /usr/local/bin/irsend: command failed: SEND_ONCE blaster ENTER
    /usr/local/bin/irsend: hardware does not support sending

    Any help would be much appreciated, Thanks!
    –Eric

  169. 169
    mark Says:

    Todd: does it work without the 150MCE installed? I figure it might be looking at the wrong card or something like that.

    Tony: probably the wrong codeset for your box. You need to run through the script trying them until you find the right one.

    Kaylan: wtf?

    Eric: Sounds like you have lirc_i2c loaded or something along those lines?

  170. 170
    Eric Says:

    Hello,

    Everything appears to be working okay with the capturing of IR commands via irw for my remote. The issue I am running into is when I have downloaded and placed the lircd.conf file into /etc Now when I try to load the config file (lircd /etc/lircd.conf) into lircd I get:

    lircd: error in configfile line 58:
    lircd: “2147483648″: must be a valid (lirc_t) number
    lircd: reading of config file failed

    I am running lircd 0.8.1-CVS-pvr150 (Cecil version) on an Athlon 64 machine, debian 2.6.17-2-amd64.

    Any thoughts?
    Thanks!

  171. 171
    Eric Says:

    Don’t know what the issue was, but I built my on config file by hand, and everything works great!

    Cheers!

  172. 172
    Francisco Says:

    Hi Mark,

    Is there an available Mark’s lirc version for 2.6.18 Kernels (kanotix distribution).

    I got this compilation errors:

    /usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:54:35: error: linux/devfs_fs_kernel.h: No such file or directory
    /usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘cleanup’:
    /usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:132: warning: implicit declaration of function ‘devfs_remove’
    /usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘lirc_register_plugin’:
    /usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:381: warning: implicit declaration of function ‘devfs_mk_cdev’
    make[5]: *** [/usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev/lirc_dev.o] Error 1
    make[4]: *** [_module_/usr/src/lirc-0.8.1-CVS-pvr150/drivers/lirc_dev] Error 2

    Thanks in advance for your help.

    Francisco from Panama.

  173. 173
    nate Says:

    Thanks for your hard work. I see on the Hauppauge site that there is a new IR blaster program updated on Oct 13, 2006 that includes support for the Dish 811 receiver. Any plans to include this in your database? I got all the way through the install…light flashes and I can use remote with myth. I ran your send_power script, but none of the codes worked.

  174. 174
    Jeff Says:

    Hi Mark,

    I read through all the posts here and didn’t see anything about LIRC support for IR blasters in multiple PVR-150 (1045) cards. Is it possible? I have two of them in a Windows machine which, at the time I set it up, the win drivers would only support the blaster in the first PCI slot it found (not sure if that was ever fixed). Alternatively, could MythTV/LIRC control multiple STBs via a single blaster? I have a USB-UIRT (http://www.usbuirt.com/) which should work (http://www.mythtv.org/wiki/index.php/USB-UIRT) and multiple DishNetwork 311′s which can be configured with different “remote addresses”. Sorry if that’s a bit off topic.

    Thanks in advance,
    Jeff

    PS (sorry if I double posted – browser/captcha issues)

  175. 175
    infringer Says:

    To Mark:
    Mark if you happen to get the SDK for the Zilog based IR chip I’d very much appreciate if you upload it to rapidshare or something …

    Obviously it is poorly based firmware they should have a more dynamic firmware alls I can say is I’m fed up with hauppauges lack of support one of there biggest owners of the cards is mythtv users…

    To Everyone Reading:
    There is a lack of complaints to the company as well complain complain everyone. Even if it dont work for you pick a model they do NOT support and take a couple of seconds to help the community out and ask them to support that model.

    More and more folks fall off the track due to a lack of support we need our community to remain strong if we wish to continue advancement with myth tv.

    Do us all a favor and complain constently it dont take long eventually someone in the right place will hear us and start doing something about it!

    Email

    >> Contact Us

    Hauppauge Headquarters, NY
    Hauppauge Computer Works, Inc.
    91 Cabot Court
    Hauppauge, NY 11788
    tel: 631.434.1600
    fax: 631.434.3198
    Sales:
    sales@hauppauge.com
    Tech Support:
    tel: 631.434.3197
    techsupport@hauppauge.com
    Click here to visit our support page
    Investor Relations:
    Jerry Tucciarone
    tel: 631.434.1600 ext.306
    jtucciarone@hauppauge.com

    Thank you please take about 5 seconds of you’re free time and send them an email asking them to support more cable boxes…

    DCT2244 by motorola
    Scientific Explorer 3200

    And I’m sure there are many more…

    Please Pleas Please
    Thank You

  176. 176
    Amankhan Says:

    I second the request for an updated version of Mark’s LIRC for the 2.6.18 kernels. I’ve been able to successfully compile LIRC, but when I try to load the lirc_pvr150 module I get this error message:

    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.18-1.2849.fc6/misc/lirc_pvr150.ko): Invalid module format

    This error message usually means that I do not have the correct kernel sources installed, but I do have the 2.6.18-1.2849.fc6 kernel-dev installed.

  177. 177
    Kurt Says:

    Mark

    Thanks a bunch for all the hard work you’ve put into this!

    I had successfully followed your directions to get the IR receiver working on my PVR 150. I was able to see IR events using irw, control my myth PVR, etc. Then I installed a pchdtv HD-5500. This took over /dev/video0 and /dev/dsp, though luckily I am still able to see the PVR 150 output on /dev/video1. My IR blaster was unaffected, so I have no problems controlling my set top box. My /dev/lirc* devices were not so lucky. Something about the installation seems to have detached them from the PVR 150. /dev/lirc0 still has 61,0 device numbers, but when I run irw I no longer see IR events from the remote control. I’m assuming the HD 5500 is the culprit, especially since it has an IR receiver which according to its documentation is “not yet supported by the driver”.

    I’m very fuzzy on how the linux internals work here; can you give some advice on how to get my PVR 150′s IR receiver working again?

    Thanks!

  178. 178
    mark Says:

    Francisco, Amankhan: I have updated the package to compile with 2.6.18 kernels, can you give it a whirl and let me know if it works?

    Jeff: it works fine AFAIK, you just run more lirc daemons with –device=/dev/lirc1 –output=/dev/lircd1, etc.

    Nate: I am unable to create new codeset dumps at present. If you have a Windows machine and are willing to do a bit of work I can provide you with instructions + tools to create one though, send me an email if you feel like giving it a whirl.

    Infringer: there is no SDK and nothing will be forthcoming from Hauppauge. Sorry :/

    Kurt: that sounds very odd indeed as the receiver and transmitter are both handled through the same lirc device. Can you compile the driver with the debug option (in the ./configure menu), then load the module with modprobe lirc_pvr150 debug=1 and post the syslog output after running lircd+irw?

  179. 179
    Amankhan Says:

    Thank you so much for the update version, Mark! Its working perfect now with 2.6.18-1.2849!

  180. 180
    Jeremy Says:

    I have a PVR-350 card. I can receive no problem, when i try sending i get
    /usr/local/bin/irsend: hardware does not support sending. I need to send to an ExpressVu 3100 receiver.

    any ideas?

  181. 181
    mark Says:

    Amankhan: cool!

    Jeremy: try reading the post title.

  182. 182
    Gary Says:

    Mark…this is awsome! I got further in an hour with your instructions than I did in a week using other articles. I am at the point where I can see the signals with irw, but I cannot seem to transmit anything. send_power_new just keeps saying “irsend: unknown remote: “blaster”
    I am a relative linux newbie, so maybe I am missing something stupid. I did notice that while I have a /dev/lirc0, I do not have a /dev/lirc1, so maybe this is why I can receive, but not send?
    I am using Debian Etch, kernel 2.6.17-2-amd64. You have already helped immeasurably, but could you shed any light on this for me? Thanks in advance!

  183. 183
    mark Says:

    You are not using the right lircd.conf, please use the one linked to in step 6.

  184. 184
    Gary Says:

    Mark, First, thank you for your quick reply! I apparently have a newer remote, so the lircd.conf file at #6 did not work, however, I finally figured out how to make my own, which I combined with the appropriate codesets from your file, so that all now works(I think, haven\’t wired it to the box yet!) Now I am working onMythtv itself. It seems it needs a lircrc file in ~/.mythtv Do you have any advice for me? (BTW, I followed your instructions to the letter except for a few hardware/system specific tweaks & now have a working lircd.conf file! Thank you very much!)

  185. 185
    Scott Says:

    Mark (or anyone else),

    Using suse 10.2 with mythtv.
    I have been able to follow the directions you gave and the remote works, although it created a new problem. After I removed the lirc that came with 10.2 I now get the message frfom mythtv:
    mythtv-setup: error while loading shared libraries: liblirc_client.so.0: cannot open shared object file: No such file or directory

    I believe i tried reinstalling mythtv, but nothing changed.
    How do I re-link to your lib?

  186. 186
    Sander Says:

    Doesnt seem to work for Suse 10.2 unfortunately: modules load properly, no luck with the remote (dont need the blaster).

    But, with the info here, I at least got the remote working with Lirc 0.8.1pre4 (while keeping the Lirc 0.8.0 package Suse provides):
    ./configure –prefix=/usr –with-driver=hauppauge –enable-debug

    then move lirc_dev.ko and lirc_i2c.ko from /lib/modules/`uname -r`/misc to
    /lib/modeles/`uname -r`/updates/lirc_dev
    and
    /lib/modeles/`uname -r`/updates/lirc_i2

    In /etc/sysconfig/lirc then set:
    LIRCD_DEVICE=”/dev/lirc”
    LIRC_MODULE=”lirc_i2c”

    lircd.conf from here, at least the remote works
    modprobe lirc_dev && modprobe lirc_i2c
    rclirc restart

  187. 187
    Scott Says:

    I ended up copying the lib to \lib and it seems fine now.

  188. 188
    Jake Says:

    Hey Mark,

    Thank you for all your hard work, by the way. I’m afraid I’ve got the same question as Jeremy above. I’ve got a PVR-350, which listed in its specs that it has an IR blaster; and I’m seeing what I can do about getting it working.

    Not trying to be annoying here, but does your comment:

    “Jeremy: try reading the post title.”

    mean that this is for the PVR-150, and that you’d rather not answer questions about the PVR-350?

    Thanks much!

  189. 189
    Steve Says:

    Mark,

    Thanks so much for all your work!

    Your patch is working great on a Mythdora 3.0 installation with a DirecTV D11 tuner. The PVR-150 is a model 1045.

    Not having much experience with this, I fumbled around until it started working. Here’s a list of the things I did, although I’m not sure everything I did was necessary:

    I installed the “dialog” package so I could build the patched lirc.

    On Mythdora after ‘make install’ I manually moved lircd and lircmd from /usr/local/sbin to /usr/sbin, I moved lirc_dev.ko and lirc_pvr150.ko from /lib/modules/2.6.18-1.2239.fc5smp/misc to /lib/modules/2.6.18-1.2239.f5csmp/updates/drivers/lirc, and I changed the file /etc/sysconfig/modules/lircd.modules to load lirc_pvr150 instead of lirc_i2c.

    I used the section from your lircd.conf file with the labels 1_125_… for the D11 tuner and combined them with the lircd.conf file supplied by Mythdora for the “new grey and black remote”. In the combined lircd.conf I renamed the ‘name’ labels from ’1_125_KEY_0′ to just ’0′.

    The PVR-150 IR blaster LED needs to be very close the IR Receiver on the D11, in my case, virtually touching the box.

    Thanks again!

  190. 190
    Bo Says:

    Hi Mark

    I am trying to rmmod lirc_prv150, but get: “ERROR: Module lirc_pvr150 is in use”.

    If you have a hint re how to resolve this, I would be very thankful.

    -Bo

  191. 191
    D. Jay Says:

    I am really struggling with your mythtv script. I have mythtv working with the remote. I am even able to change the channel on my cable box but only command line. So what I don\’t understand is how to line your script and mythtv together. Any help?

  192. 192
    Dan Says:

    I get the following error when I run:

    modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    It only happens with the “modprobe lirc_pvr150 debug=1″ section.

    “Jan 2 23:48:09 MythServer kernel: kobject_add failed for i2c ir driver with -EEXIST, don’t try to register things with the same name in the same directory.”

    I don’t recieve messages in the syslog like “lirc_pvr150: chip found with RX and TX”

    …but instead get messages like:

    “Jan 2 22:59:34 MythServer kernel: tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    Jan 2 22:59:34 MythServer kernel: cx25840 1-0044: cx25841-23 found @ 0×88 (ivtv i2c driver #0)
    Jan 2 22:59:39 MythServer kernel: cx25840 1-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    Jan 2 22:59:39 MythServer kernel: wm8775 1-001b: chip found @ 0×36 (ivtv i2c driver #0)
    Jan 2 22:59:39 MythServer kernel: lirc_i2c: chip found @ 0×71 (Hauppauge IR (PVR150))
    Jan 2 22:59:39 MythServer kernel: lirc_dev: lirc_register_plugin: sample_rate: 10
    Jan 2 22:59:39 MythServer kernel: tveeprom 1-0050: Hauppauge model 26132, rev F1B2, serial# 10062800″

    Any suggestions? I think that the lirc_i2c drivers are still hanging around, how can I uninstall them for good if that is the case?

  193. 193
    Chris Says:

    Mark,
    Is the lirc_pvr150 driver intended to work with the PVR-350 card as well as the PVR-150?

  194. 194
    Dan Says:

    Please disregard my previous comment. Here is where I am now.

    I can get change_channel to change the channels from a terminal. When I add /etc/change_channel to “External channel change command”, I can use the up and down arrows of the remote to change the numbers on the screen AND make the IR blaster blinks…but whatever is coming out of the IR blaster isn’t changing the changing the channel on the STB. Placement on the IR blaster is perfect for terminal manual change_channeling, but not good in MythTV.

    Any thoughts on thought?

    My other issue is that I don’t know how to get “modprobe lirc_dev && modprobe lirc_pvr150″ to load from boot. I currently have to run a script I made manually for it all to kick in.

    Ideas on that?

  195. 195
    Tom Says:

    Mark…I’d be willing to try to get the new codesets working. You can send me the instructions and tools, and I’ll give it a shot.

  196. 196
    Cristiano Says:

    I have a pvr150 controlling a skybox so I tried your package and it seems to work with a little problem.
    When I send a command like “irsend SEND_ONCE blaster 1_663_KEY_XXXX” the IR code is generated ok but the box receives two signal instead of one and this creates some problem during the OSD navigation (es: double jump on the osd entry).
    I am using gentoo with 2.6.18-gentoo-r4 kernel and here is my logs:
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): open called
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0×80046900)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0×40046911)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0×40046912)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): write called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: 01 60 b2 a0 2alirc_pvr150: 05 b8 07 90 79lirc_pvr150: 09 fd 00 26 05lirc_pvr150: 0d 5b 90 43 ddlirc_pvr150: 11 49 5c b5 00lirc_pvr150: 15 ac 9e d3 dblirc_pvr150: 19 f7 13 c9 2dlirc_pvr150: 1d 32 d4 3d 4blirc_pvr150: 21 3b 14 40 c6lirc_pvr150: 25 2b 68 14 cflirc_pvr150: 29 6d e9 6f 2alirc_pvr150: 2d 66 5a 1c 6elirc_pvr150: 31 2e 77 25 48lirc_pvr150: 35 54 26 3b falirc_pvr150: 39 79 fd cb 94lirc_pvr150: 3d ad 7e 8b f0lirc_pvr150: 41 81 49 94 d5lirc_pvr150: 45 80 f9 fa 87lirc_pvr150: 49 8c ff d9 falirc_pvr150: 4d a4 6f bc 30lirc_pvr150: 51 95 a2 d4 fflirc_pvr150: 55 83 60 8c 24lirc_pvr150: 59 d1 30 c5 d2lirc_pvr150: 5d cd 2b 99 c8lirc_pvr150: 61 00 00 00 c8lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 4)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 5)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: sent code 33431, key 49
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): close called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: key (0×00/0×00)

    any ideas?
    thanks in advance

  197. 197
    Paul Says:

    Was wondering if anyone has experience in using these instructions with Ubunty Edgy Eft? I have tried setting up the ir blaster using the lirc and external channel changer instructions at https://help.ubuntu.com/community/MythTV_Edgy_hardware and whilst at one point I got the remote working I have had zero success with getting the ir blaster to work. As my machine is a headless mythtv backend all I need is the ir blaster. I believe edgy is slightly different from some distros as it has support for some remotes built in. Thanks

  198. 198
    Byte Surfer Says:

    I have just built a fedora core 6 box with the latest kernel. Myth TV is working fine with my PVR-150 except for the blasting. I would like this to work.

    Since I already have IRC and IVTV installed and working, do I have to remove these or just reprogram them ? Can someone give me an overview of what I need to do since I already have this stuff installed and working. I can look through the instructions and posts for details. I just want to know what steps to take. I am slightly confused by all the info here.

    I have the PVR-150 with the y-cable and two heads . Also, will all this work w/the latest kernel ? (i will post version # soon) thanks.

  199. 199
    Aravind Says:

    Mark, thanks a lot for the patched lirc – I couldn’t have setup my mythtv system without it. Do you suppose it’s possible to merge it into the lirc tree somehow? It is a bit of a bother to manually recompile lirc whenever I update my kernel. Besides, it will probably save you the trouble of updating the patches here on your blog every time kernel changes break them.

  200. 200
    Amankhan Says:

    Hi again Mark,

    Looks like the 2.6.19 kernels are having the same error that we had with the 2.6.18 kernels:

    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.18-1.2849.fc6/misc/lirc_pvr150.ko): Invalid module format

    Any chance you could update the packages again? :)

  201. 201
    Ram Says:

    Mark:
    I was using lirc_i2c and couldnt get the infrared working. Followed your steps and got it working. Wonderful job. I also wanted to know how to run this automatically when the system boots up. Any thoughts on that? I am newbie so dont know much.

    Thanks

  202. 202
    Ram Says:

    Mark,
    One more question. I have dish network dvp 311. I attached the ir blaster to the front of the box and when i issue irsend through command line it works fine. But the Hauppauge PVR-150 remote seems not working. Here is how my lircd.conf looks like. Any way i can make it work? Onething is how does my remote fall into the name blaster?

    Thanks

    #
    # this config file was automatically generated
    # using lirc-0.5.5pre8 on Sun Apr 18 11:43:45 1999
    #
    # contributed by Jens Leuschner
    #
    # brand: Hauppauge
    # model:
    # supported devices: WinTV primo; WinTV pci; WinTV radio
    #
    # This config file will work with both homebrew receivers and
    # original Hauppauge TV cards !!!
    #

    begin remote

    name blaster
    bits 32
    flags RAW_CODES
    eps 0
    aeps 0
    plead 0
    gap 333333
    repeat_bit 0
    begin raw_codes
    name 1_136_KEY_0
    2156396544
    name 1_136_KEY_1
    2156396545
    name 1_136_KEY_2
    2156396546
    name 1_136_KEY_3
    2156396547
    name 1_136_KEY_4
    2156396548
    name 1_136_KEY_5
    2156396549
    name 1_136_KEY_6
    2156396550
    name 1_136_KEY_7
    2156396551
    name 1_136_KEY_8
    2156396552
    name 1_136_KEY_9
    2156396553
    name 1_136_KEY_POWER
    2156396554
    name 1_136_KEY_CH_UP
    2156396559
    name 1_136_KEY_CH_DOWN
    2156396560
    name 1_136_KEY_MUTE
    2156396561
    name 1_136_KEY_VOL_DOWN
    2156396562
    name 1_136_CH_PREVIOUS
    2156396563
    name 1_136_KEY_VOL_UP
    2156396564
    name 1_136_KEY_DISPLAY
    2156396565
    name 1_136_KEY_EXIT
    2156396568
    name 1_136_KEY_GUIDE
    2156396571
    name 1_136_KEY_SAT
    2156396586
    name 1_136_KEY_MENU
    2156396591
    name 1_136_KEY_MUP
    2156396592
    name 1_136_KEY_MDOWN
    2156396593
    name 1_136_KEY_MLEFT
    2156396594
    name 1_136_KEY_MRIGHT
    2156396595
    end raw_codes
    end remote

    begin remote

    name Hauppauge
    bits 13
    flags SHIFT_ENC
    eps 30
    aeps 100

    one 950 830
    zero 950 830
    plead 960
    gap 89584
    repeat_bit 2

    begin codes
    TV 0x000000000000100F
    RADIO 0x000000000000100C
    FULL_SCREEN 0x000000000000102E
    CH+ 0×0000000000001020
    CH- 0×0000000000001021
    VOL- 0×0000000000001011
    VOL+ 0×0000000000001010
    MUTE 0x000000000000100D
    SOURCE 0×0000000000001022
    1 0×0000000000001001
    2 0×0000000000001002
    3 0×0000000000001003
    4 0×0000000000001004
    5 0×0000000000001005
    6 0×0000000000001006
    7 0×0000000000001007
    8 0×0000000000001008
    9 0×0000000000001009
    0 0×0000000000001000
    RESERVED 0x000000000000101E
    MINIMIZE 0×0000000000001026
    end codes

    end remote

    #
    # this config file was automatically generated
    # using lirc-0.6.6(animax) on Tue Apr 15 19:50:27 2003
    #
    # contributed by
    #
    # brand: Hauppauge
    # model no. of remote control:
    # devices being controlled by this remote: PVR 2/350
    #

    begin remote

    name hauppauge_pvr
    bits 13
    flags RC5|CONST_LENGTH
    eps 30
    aeps 100

    one 969 811
    zero 969 811
    plead 1097
    gap 114605
    toggle_bit 2

    begin codes
    Power 0x00000000000017FD
    Go 0x00000000000017FB
    1 0x00000000000017C1
    2 0x00000000000017C2
    3 0x00000000000017C3
    4 0x00000000000017C4
    5 0x00000000000017C5
    6 0x00000000000017C6
    7 0x00000000000017C7
    8 0x00000000000017C8
    9 0x00000000000017C9
    Back/Exit 0x00000000000017DF
    0 0x00000000000017C0
    Menu 0x00000000000017CD
    Red 0x00000000000017CB
    Green 0x00000000000017EE
    Yellow 0x00000000000017F8
    Blue 0x00000000000017E9
    Ch+ 0x00000000000017E0
    Ch- 0x00000000000017E1
    Vol- 0x00000000000017D1
    Vol+ 0x00000000000017D0
    Ok 0x00000000000017E5
    Mute 0x00000000000017CF
    Blank 0x00000000000017CC
    Full 0x00000000000017FC
    Rewind 0x00000000000017F2
    Play 0x00000000000017F5
    Forward 0x00000000000017F4
    Record 0x00000000000017F7
    Stop 0x00000000000017F6
    Pause 0x00000000000017F0
    Replay 0x00000000000017E4
    Skip 0x00000000000017DE
    end codes

    end remote

    #
    # this config file was automatically generated
    # using lirc-0.7.0(any) on Sun Nov 28 20:25:09 2004
    #
    # contributed by
    #
    # brand: Hauppauge 350
    # Created: G.J. Werler (The Netherlands)
    # Project: Mythtv Fedora Pundit-R http://www.mythtvportal.com
    # Date: 2004/11/28
    # model no. of remote control: Hauppauge A415-HPG
    # devices being controlled by this remote: PVR-350
    #

    begin remote

    name Hauppauge_350
    bits 13
    flags RC5|CONST_LENGTH
    eps 30
    aeps 100

    one 969 811
    zero 969 811
    plead 1097
    gap 114605
    # gap 200000
    toggle_bit 2

    begin codes
    Go 0x00000000000017BB
    Power 0x00000000000017BD
    TV 0x000000000000179C
    Videos 0×0000000000001798
    Music 0×0000000000001799
    Pictures 0x000000000000179A
    Guide 0x000000000000179B
    Radio 0x000000000000178C
    Up 0×0000000000001794
    Left 0×0000000000001796
    Right 0×0000000000001797
    Down 0×0000000000001795
    OK 0x00000000000017A5
    Back/Exit 0x000000000000179F
    Menu/i 0x000000000000178D
    Vol+ 0×0000000000001790
    Vol- 0×0000000000001791
    Prev.Ch 0×0000000000001792
    Mute 0x000000000000178F
    Ch+ 0x00000000000017A0
    Ch- 0x00000000000017A1
    Record 0x00000000000017B7
    Stop 0x00000000000017B6
    Rewind 0x00000000000017B2
    Play 0x00000000000017B5
    Forward 0x00000000000017B4
    Replay/SkipBackward 0x00000000000017A4
    Pause 0x00000000000017B0
    SkipForward 0x000000000000179E
    1 0×0000000000001781
    2 0×0000000000001782
    3 0×0000000000001783
    4 0×0000000000001784
    5 0×0000000000001785
    6 0×0000000000001786
    7 0×0000000000001787
    8 0×0000000000001788
    9 0×0000000000001789
    Asterix 0x000000000000178A
    0 0×0000000000001780
    # 0x000000000000178E
    Red 0x000000000000178B
    Green 0x00000000000017AE
    Yellow 0x00000000000017B8
    Blue 0x00000000000017A9
    end codes

    end remote

  203. 203
    Ram Says:

    3rd one. I apologize for asking so many questions. Please bear with me. How do i still have pause, rewind, control pvr and guide, right arrow key etc… control the dishbox?

  204. 204
    Cristiano Says:

    Hi mark,
    I have a pvr150 controlling a skybox so I tried your package and it seems to work with a little problem.
    When I send a command like “irsend SEND_ONCE blaster 1_663_KEY_XXXX” the IR code is generated ok but the box receives two signal instead of one and this creates some problem during the OSD navigation (double jump on the osd entry).

    I am using gentoo with 2.6.18-gentoo-r4 kernel and here is my logs:
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): open called
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0×80046900)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0×40046911)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0×40046912)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): write called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: 01 60 b2 a0 2alirc_pvr150: 05 b8 07 90 79lirc_pvr150: 09 fd 00 26 05lirc_pvr150: 0d 5b 90 43 ddlirc_pvr150: 11 49 5c b5 00lirc_pvr150: 15 ac 9e d3 dblirc_pvr150: 19 f7 13 c9 2dlirc_pvr150: 1d 32 d4 3d 4blirc_pvr150: 21 3b 14 40 c6lirc_pvr150: 25 2b 68 14 cflirc_pvr150: 29 6d e9 6f 2alirc_pvr150: 2d 66 5a 1c 6elirc_pvr150: 31 2e 77 25 48lirc_pvr150: 35 54 26 3b falirc_pvr150: 39 79 fd cb 94lirc_pvr150: 3d ad 7e 8b f0lirc_pvr150: 41 81 49 94 d5lirc_pvr150: 45 80 f9 fa 87lirc_pvr150: 49 8c ff d9 falirc_pvr150: 4d a4 6f bc 30lirc_pvr150: 51 95 a2 d4 fflirc_pvr150: 55 83 60 8c 24lirc_pvr150: 59 d1 30 c5 d2lirc_pvr150: 5d cd 2b 99 c8lirc_pvr150: 61 00 00 00 c8lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 4)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 5)
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: sent code 33431, key 49
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: poll result = 0
    Jan 16 12:30:44 LiveServer-222 lirc_dev (lirc_pvr150[0]): close called
    Jan 16 12:30:44 LiveServer-222 lirc_pvr150: key (0×00/0×00)

    any ideas?
    thanks in advance

  205. 205
    Travis with a Sore Head Says:

    Try as I might, I can’t get my driver recognized. I keep getting this in my log:

    Jan 24 22:36:18 compy kernel: lirc_pvr150: ivtv i2c driver #0: no devices found

    I started of with the binary modules from ATrpms, then downloaded your updated PVR 150 module, compiled, and attempted to load it. Here is a whole slew of potentially uninteresting information…

    [root@compy ~]# rpm -qv lirc-kmdl-`uname -r`
    lirc-kmdl-2.6.19-1.2895.fc6-0.8.1-65_cvs20061130.fc6.at

    [root@compy ~]# rpm -qv lirc
    lirc-0.8.1-65_cvs20061130.fc6.at

    [root@compy modules]# cat /etc/sysconfig/modules/lirc.modules
    #!/bin/sh

    for module in `/sbin/modprobe -c | awk ‘/^alias[[:space:]]+char-major-61+[[:space:]]/ { print $3 }’`; do
    /sbin/modprobe $module
    done

    [root@compy etc]# cat /etc/udev/rules.d/lirc.rules
    KERNEL==”lirc[0-9]*”, NAME=”lirc%n”
    KERNEL==”lirc0″, SYMLINK=”lirc”

    [root@compy etc]# cat /etc/modprobe.conf
    alias char-major-61 lirc_dev
    alias eth0 forcedeth
    alias scsi_hostadapter sata_nv
    alias snd-card-0 snd-intel8x0
    options snd-card-0 index=0
    options snd-intel8x0 index=0
    remove snd-intel8x0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r –ignore-remove snd-intel8x0
    alias char-major-81 videodev
    alias char-major-81-0 ivtv
    # nvidia kernel module
    alias char-major-195 nvidia-1_0-9746
    alias nvidia nvidia-1_0-9746
    install lirc_i2c /sbin/modprobe ivtv; /sbin/modprobe –ignore-install lirc_i2c

    ======
    After Reboot
    ======

    [root@compy ~]# cat /var/log/messages

    Jan 23 23:17:52 compy kernel: ivtv: ==================== START INIT IVTV ====================
    Jan 23 23:17:52 compy kernel: ivtv: version 0.9.1 (tagged release) loading
    Jan 23 23:17:52 compy kernel: ivtv: Linux version: 2.6.19-1.2895.fc6 SMP mod_unload 686 REGPARM 4KSTACKS
    Jan 23 23:17:52 compy kernel: ivtv: In case of problems please include the debug info between
    Jan 23 23:17:52 compy kernel: ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    Jan 23 23:17:52 compy kernel: ivtv: any module options, when mailing the ivtv-users mailinglist.
    Jan 23 23:17:52 compy kernel: hdb: ATAPI 40X CD-ROM drive, 128kB Cache
    Jan 23 23:17:52 compy kernel: Uniform CD-ROM driver Revision: 3.20
    Jan 23 23:17:52 compy kernel: eth0: forcedeth.c: subsystem: 01462:7125 bound to 0000:00:0a.0
    Jan 23 23:17:52 compy kernel: ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 20
    Jan 23 23:17:52 compy kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 20 (level, low) -> IRQ 20
    Jan 23 23:17:52 compy kernel: intel8x0_measure_ac97_clock: measured 51640 usecs
    Jan 23 23:17:53 compy kernel: intel8x0: clocking to 46916
    Jan 23 23:17:53 compy kernel: ivtv0: Autodetected Hauppauge card (cx23416 based)
    Jan 23 23:17:53 compy kernel: ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18
    Jan 23 23:17:53 compy kernel: ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    Jan 23 23:17:53 compy kernel: tveeprom 2-0050: Hauppauge model 26132, rev G1B2, serial# 9545043
    Jan 23 23:17:53 compy kernel: tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    Jan 23 23:17:53 compy kernel: tveeprom 2-0050: TV standards NTSC(M) (eeprom 0×08)
    Jan 23 23:17:53 compy kernel: tveeprom 2-0050: audio processor is CX25841 (idx 35)
    Jan 23 23:17:53 compy kernel: tveeprom 2-0050: decoder processor is CX25841 (idx 28)
    Jan 23 23:17:53 compy kernel: tveeprom 2-0050: has no radio, has IR remote
    Jan 23 23:17:53 compy kernel: ivtv0: Autodetected Hauppauge WinTV PVR-150
    Jan 23 23:17:53 compy kernel: ivtv0: reopen i2c bus for IR-blaster support
    Jan 23 23:17:53 compy kernel: tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    Jan 23 23:17:53 compy kernel: cx25840 2-0044: cx25841-23 found @ 0×88 (ivtv i2c driver #0)
    Jan 23 23:17:53 compy kernel: cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    Jan 23 23:17:53 compy kernel: wm8775 2-001b: chip found @ 0×36 (ivtv i2c driver #0)
    Jan 23 23:17:53 compy kernel: ivtv0: Encoder revision: 0×02050032
    Jan 23 23:17:53 compy kernel: ivtv0: Registered device video0 for encoder MPEG
    Jan 23 23:17:53 compy kernel: ivtv0: Registered device video32 for encoder YUV
    Jan 23 23:17:53 compy kernel: ivtv0: Registered device vbi0 for encoder VBI
    Jan 23 23:17:53 compy kernel: ivtv0: Registered device video24 for encoder PCM audio
    Jan 23 23:17:53 compy kernel: tuner 2-0061: type set to 50 (TCL 2002N)
    Jan 23 23:17:53 compy kernel: ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    Jan 23 23:17:53 compy kernel: ivtv: ==================== END INIT IVTV ====================

    [root@compy ~]# grep lirc /var/log/messages
    Jan 24 21:24:18 compy kernel: lirc_dev: IR Remote Control driver registered, at major 61

    [root@compy ~]# ls /dev/lir*
    ls: /dev/lir*: No such file or directory

    [root@compy ~]# lsmod | grep lirc
    lirc_dev 16788 0

    [root@compy ~]# modprobe lirc_dev
    [root@compy ~]# modprobe lirc_pvr150

    [root@compy ~]# tail /var/log/messages

    Jan 24 22:36:18 compy kernel: lirc_pvr150: ivtv i2c driver #0: no devices found

    [root@compy ~]# lsmod | grep lirc
    lirc_pvr150 22976 0
    lirc_dev 16788 1 lirc_pvr150
    ivtv 167696 1 lirc_pvr150
    i2c_core 26049 10 lirc_pvr150,i2c_ec,wm8775,cx25840,tuner,ivtv,i2c_algo_bit,tveeprom,i2c_nforce2,nvidia

    [root@compy ~]# mknod /dev/lirc c 61 0
    [root@compy ~]# ln -s /dev/lirc /dev/lirc0
    [root@compy ~]# ls -l /dev/li*
    crw-r–r– 1 root root 61, 0 Jan 24 22:39 /dev/lirc
    lrwxrwxrwx 1 root root 9 Jan 24 22:39 /dev/lirc0 -> /dev/lirc

    [root@compy ~]# /sbin/service lircd start
    Starting infrared remote control daemon: [ OK ]
    Starting infrared remote control mouse daemon: [ OK ]

    [root@compy ~]# tail /var/log/messages

    Jan 24 22:42:33 compy lircd-0.8.1-CVS[3311]: lircd(userspace) ready
    Jan 24 22:42:33 compy lircd-0.8.1-CVS[3311]: accepted new client on /dev/lircd
    Jan 24 22:42:33 compy lircd-0.8.1-CVS[3311]: could not open /dev/lirc
    Jan 24 22:42:33 compy lircd-0.8.1-CVS[3311]: default_init(): No such device
    Jan 24 22:42:33 compy lircd-0.8.1-CVS[3311]: caught signal

    [root@compy ~]# ps -e | grep lircd
    [root@compy ~]#

  206. 206
    Travis with a Sore Head Says:

    By way of a second try, I removed all of the lirc packages I had downloaded from ATrpms. I then cleaned up all of the old lirc stuff I could find lying around (removing /dev/lirc*, /etc/sysconfig/lircd, so and and so forth). When I was done, I had what I felt was a pristine ivtv 0.91 environment with no lirc contamination.

    I then reconfigured the source and turned debugging on. Cleaned, compiled, and installed. During the compile, I got this error a couple of times (but it didn’t stop the compilation):

    ]make[4]: Entering directory `/usr/src/kernels/2.6.19-1.2895.fc6-i686′
    test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
    echo; \
    echo ” ERROR: Kernel configuration is invalid.”; \
    echo ” include/linux/autoconf.h or include/config/auto.conf are
    missing.”; \
    echo ” Run ‘make oldconfig && make prepare’ on kernel src to fix
    it.”; \
    echo; \
    /bin/false)

    I then went on to steps 4 and 5. When I did the modprobe, I cried…

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found

    Could card placement in the PCI bus make a difference? I think I’m going to swap the card with another PVR150 I have to rule out hardware somewhat.

    *sniff* I want my toy to work.

  207. 207
    Travis with a Sore Head Says:

    Ugh, one last: I turned debugging on in the code configuration, but I don’t see where it actually gives any of that debugging. :) Is there more information I can provide you from that?

    Thanks.

    Travis

  208. 208
    Ram Says:

    For my second question above, here is my lircrc file and change_channel script. My Hauppauge remote works now with mythtv but if I do channel up or down, prev channel (whichever has to send signal through ir transmitter), doesnt work. infact I dont see the red light blinking. But, when i do it from command line using irsend … blaster … then I can see it working. when i track the /var/log/mythtv/myth.log, it says
    /usr/local/bin/irsend: command failed: SEND_ONCE blaster 7
    /usr/local/bin/irsend: unknown command: “7″

    What is happening here?

    cat .mythtv/lircrc

    begin
    prog = mythtv
    button = Off
    config = Esc
    end

    begin
    prog = mythtv
    button = Go
    # Swap the PiP windows
    config = N
    end

    begin
    prog = mythtv
    button = 1
    config = 1
    end

    begin
    prog = mythtv
    button = 2
    config = 2
    end

    begin
    prog = mythtv
    button = 3
    config = 3
    end

    begin
    prog = mythtv
    button = 4
    config = 4
    end

    begin
    prog = mythtv
    button = 5
    config = 5
    end

    begin
    prog = mythtv
    button = 6
    config = 6
    end

    begin
    prog = mythtv
    button = 7
    config = 7
    end

    begin
    prog = mythtv
    button = 8
    config = 8
    end

    begin
    prog = mythtv
    button = 9
    config = 9
    end

    begin
    prog = mythtv
    button = Back/Exit
    config = Esc
    end

    begin
    prog = mythtv
    button = 0
    config = 0
    end

    begin
    prog = mythtv
    button = Menu/i
    config = M
    end

    # Below are keys used with the Hauppauge Grey remote

    begin
    prog = mythtv
    # This is the Red key
    # We’ll use it for “Delete”
    button = Red
    config = D
    end

    begin
    prog = mythtv
    button = Asterix
    config = I
    end

    begin
    prog = mythtv
    button = Videos
    config = Ctrl+V
    end

    begin
    prog = mythtv
    button = Music
    config = Ctrl+M
    end

    begin
    prog = mythtv
    button = Pictures
    config = Ctrl+D
    end

    begin
    prog = mythtv
    button = Radio
    config = Ctrl+W
    end

    begin
    prog = mythtv
    button = Prev.Ch
    config = Alt+M
    end

    # Note the “repeat =” strings in the volume and channel.
    # This means that if you hold down the key, every nth instance will be
    # passed. This depends on your system, so you may want to increase or
    # decrease this and see what happens. repeat = 1 is probably too
    # fast.

    begin
    prog = mythtv
    button = Ch+
    # This is the “up” on the central diamond
    repeat = 3
    config = Up
    end

    begin
    prog = mythtv
    button = Ch-
    # This is the “down” on the central diamond
    repeat = 3
    config = Down
    end

    begin
    prog = mythtv
    button = Vol-
    # This is the “left” on the central diamond
    repeat = 3
    config = Left
    end

    begin
    prog = mythtv
    button = Vol+
    # This is the “right” on the central diamond
    repeat = 3
    config = Right
    end

    begin
    prog = mythtv
    button = Up
    repeat = 3
    config = Up
    end

    begin
    prog = mythtv
    button = Down
    repeat = 3
    config = Down
    end

    begin
    prog = mythtv
    button = Left
    repeat = 3
    config = Left
    end

    begin
    prog = mythtv
    button = Right
    repeat = 3
    config = Right
    end

    begin
    prog = mythtv
    # Middle button on the diamond
    button = Ok
    config = Return
    end

    begin
    prog = mythtv
    button = Mute
    config = F9
    end

    begin
    prog = mythtv
    # Change focus for PiP (to change channel in the other window)
    button = Blank
    config = B
    end

    begin
    prog = mythtv
    # Toggle PiP on/off
    button = Full
    config = V
    end

    begin
    prog = mythtv
    button = Rewind
    config = Left
    end

    begin
    prog = mythtv
    button = Play
    config = P
    end

    begin
    prog = mythtv
    button = Forward
    config = Right
    end

    begin
    prog = mythtv
    button = Record
    config = R
    end

    begin
    prog = mythtv
    button = Stop
    config = Esc
    end

    begin
    prog = mythtv
    button = pause
    config = P
    end

    begin
    prog = mythtv
    button = Green
    repeat = 3
    config = PgUp
    end

    begin
    prog = mythtv
    button = Blue
    repeat = 3
    config = PgDown
    end

    cat /usr/bin/change_channel

    #!/usr/bin/perl

    # make sure to set this string to
    # the corresponding remote in /etc/lircd.conf
    $remote_name = “blaster”;

    # Let’s assume you don’t need to press enter after you punch in a
    # channel number. Change this to 1 if your cable box expects you press
    # enter after each command
    $needs_enter = 0;

    # Change this to point to your rc executable
    $rc_command = “/usr/local/bin/irsend”;

    # This subroutine actually sends the signal to the cable box
    sub change_SIGNAL {
    my($SIGNAL) = @_;
    system (“$rc_command SEND_ONCE $remote_name $SIGNAL”);
    }

    $SIGNAL=$ARGV[0];
    open F, “>> /var/log/channel.log”;
    print F “channel changing $SIGNAL\n”;
    close F;
    print “channel changing $SIGNAL\n”;

    # Checks if $SIGNAL begins with a digit
    # If it detects that the string is made up of digits, then it puts
    # spaces between the digits. Ex. 1234 becomes 1 2 3 4
    if ( $SIGNAL =~ /^\d+$/ )
    {
    my $length = length($SIGNAL);
    my $counter = 0;
    my $temp;

    while( $counter

  209. 209
    Travis with a Sore Head Says:

    Nevermind…freaking hardware problem. Put in a different PVR150 and it worked like a charm. Thanks for your efforts on this! It is much appreciated.

  210. 210
    John Says:

    I noticed lirc release lirc-0.8.1 on 07-Jan-2007, can we use this version for the PVR-150 now instead of the CVS version?

  211. 211
    Allison Says:

    Mark,

    First of all, thanks for all of your work on this!

    I’m having some problems getting it to run properly. I’m using kernel 2.6.17-10 and using what I think is the most current lirc source available on your site: http://www.blushingpenguin.com/mark/lmilk/lirc-0.8.1-CVS-pvr150.tar.bz2 .
    I’m getting errors similar to what have been reported before, when I’m using irsend:Jan 29 17:13:46 ajones-desktop lircd-0.8.0[5979]: error in configfile line 58:
    Jan 29 17:13:46 ajones-desktop lircd-0.8.0[5979]: “2147483648″: must be a valid (lirc_t) number
    Jan 29 17:13:46 ajones-desktop lircd-0.8.0[5979]: reading of config file failed
    Jan 29 17:13:46 ajones-desktop lircd-0.8.0[5980]: lircd(userspace) ready

    Do you have any suggestions/advice? Thanks in advance!

  212. 212
    Morten Says:

    Thanks alot Mark. This is working great for me. ;-)

  213. 213
    Barry Says:

    If I test with a simple script like:

    echo 1_28_KEY_MUTE
    irsend SEND_ONCE blaster 1_28_KEY_MUTE

    it works fine, the STB mutes. When I try the perl script, I get:

    # ./change_bev 123
    channel changing 123
    /usr/bin/irsend: command failed: SEND_ONCE blaster 1
    /usr/bin/irsend: unknown command: “1″

    It always barfs after the first digit. Maybe this is real obvious, but not to me. Can’t find a lot of related web support either.
    I’m using a PVR150, and latest Knoppmyth.
    Thanks for any help.

    Barry

  214. 214
    David Hawks Says:

    Hauppauge has a new version of IR Blaster titled:

    Beta version 4.0 (October 13, 2006) with a new list of set top boxes.

    This new version supports my box (the DirecTV R10). Any chance of getting the new codesets added?

  215. 215
    Octavian Says:

    I also had this, Did you make clean first?

    However, I cannot use the remote since
    /usr/bin/ivtvctl –reset-ir
    does not work. Still investigating.

  216. 216
    John Says:

    Hey,
    I tried installing the blaster using this howto on Ubuntu Edgy with IVTV 0.7.0,
    however I get FATAL: Module lirc_pvr150 not found. everytime I do modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    I tried to copy haup-ir-blaster.bin to /lib/firmware/`uname -r`/ and /lib/modules/`uname -r`/ but that didnt change anything!

    Help would definately be appreciated

  217. 217
    mark Says:

    Shitsticks!

    I moved this off to a nice new server and broke mail notifications at the same time. Hence the lack of replies, I thought everybody was all settled down and things were working perfectly. Oh well, obviously not! This is a bit much for me all at the same time, so I’ll start plodding through tomorrow.

    Sorry about that,

    Mark

  218. 218
    John Says:

    I gave it a new try and this time I get FATAL: Module lirc_dev not found when I do modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1.

    I am getting desperate, I can get my receiver working in 2 seconds, but the IR Blaster seems impossible to set up for me, I also have a serial IR Blaster never got it to work either.
    I have been working on this for a couple of months now, but no success at all. If somebody can help me get this to work Id be very thankful

  219. 219
    Dan Says:

    You can disregard my questions from above. I’m all set with that stuff. Right now I’m trying to figure out a better workaround to set my PVR-150′s default volume. I have to use a crontab job every 5 seconds to re adjust the volume level. MythTV likes to put it back to the default, and the default is way to low…

    Example:
    * * * * * /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 5; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 10; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 15; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 20; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 25; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 30; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 35; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 40; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 45; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 50; /usr/bin/v4l2-ctl –set-ctrl=volume=63500
    * * * * * /bin/sleep 55; /usr/bin/v4l2-ctl –set-ctrl=volume=63500

  220. 220
    Jeff Says:

    From the Edgy How to

    Ubuntu Edgy introduces support in the kernel to directly manage some remotes via the i2c bus. For remotes like this, the kernel is deprecating the use (and requirement) of lirc. You should be able to press keys on the remote and have them recognized as ordinary keyboard keys. If you don’t like the way that the keypresses that are recognized for certain buttons on the remote, their behavior can be changed using Xmodmap.

    Alternatively, if you would like to still use lirc to manage your i2c device, hexion has written a howto explaining how to install lirc from source and replace the ir_common module in the kernel causing this behavior. See his howto here: HOWTO: Lirc in Edgy.

    I will try setting this up tonight

  221. 221
    Chris K Says:

    Trying the send power script, will not find a codeset but it has worked before.
    dmesg output after running ut;
    lirc_pvr150: 01 60 a6 58 2alirc_pvr150: 05 87 06 05 78lirc_pvr150: 09 73 00 26 05lirc_pvr150: 0d 5b 90 43 dclirc_pvr150: 11 77 55 32 00lirc_pvr150: 15 81 9c 7c 9clirc_pvr150: 19 37 cb 2b 80lirc_pvr150: 1d 81 d4 3d 4blirc_pvr150: 21 3b 96 51 a6lirc_pvr150: 25 28 68 15 9dlirc_pvr150: 29 0d e9 6c 29lirc_pvr150: 2d 66 59 1f 6dlirc_pvr150: 31 2d 74 25 48lirc_pvr150: 35 14 26 58 falirc_pvr150: 39 3c 4c 3a 19lirc_pvr150: 3d 23 f3 06 7dlirc_pvr150: 41 0c c4 18 a8lirc_pvr150: 45 7b 13 c5 fblirc_pvr150: 49 8c ff d9 falirc_pvr150: 4d a4 6f bc 30lirc_pvr150: 51 95 a2 d4 fflirc_pvr150: 55 83 60 8c 24lirc_pvr150: 59 d1 30 c5 d2lirc_pvr150: 5d cd 2b ce 0elirc_pvr150: 61 00 00 00 0elirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 4)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 5)
    lirc_pvr150: sent code 32777, key 0
    lirc_pvr150: key (0×00/0×00)
    lirc_dev (lirc_pvr150[0]): poll called
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_dev (lirc_pvr150[0]): close called

  222. 222
    mark Says:

    Well, if you’ve not all given up by now here are the replies that I meant to send before it went right out of my head. If you post anything here and I don’t reply it’s probably worth dropping me a mail (mark@npsl.co.uk) as I tend to respond to those a bit faster.

    In other news I have purchased another PVR-150 from ebay so when it turns up I will update the codesets to the latest hauppauge version. It is not easy for me to do this at the moment as it means disassembling my mythtv box (which does not make me popular).

    So, hopefully not missing anything:

    jake: this is specific to the PVR-150, the PVR-350 doesn’t have the same hardware (AFAIK). I don’t have a PVR-350, and don’t know anything about them. Sorry!
    steve: yes, it’s an LED not a proper IR device so the range is just a few cm.
    bo: kill lircd
    d. jay: in mythtv-setup just set the change channel script
    dan: you have got lirc_i2c loaded, these both try to claim the same hardware. Uninstall whatever prepackaged lirc you have and start again from the top.
    chris: no, sorry.
    dan: list the modules in /etc/modules
    tom: sorry I missed that. Drop me a mail if you are still interested.
    cristiano: try another codeset, other than that there is not a lot that I can do, sorry
    paul: probably something is conflicting, try unloading the kernel module that provides the remote driver. Other than that, I need a bit more information about the specific issue that you are having.
    byte surfer: yes, you have to remove the current lirc first
    aravind: I’m afraid it was rejected due to licensing issues (with the firmware blob that it requires, not the software on this site)
    amankhan: I will try and do this at some point soon
    ram: for starting on boot, /etc/modules, /etc/rcX.d/script ? Other than that I need some more information — ‘not working’ doesn’t tell me much.
    travis: glad you sorted it out
    john: no
    allison: that bug was fixed a while ago, did you pick up an old copy of the software from somewhere?
    morten: cool!
    barry: rename the keys in lircd.conf (1_28_KEY_1 -> 1), or change the channel changing script to add the 1_28_KEY_ prefix
    david: will do as soon as I get my new card
    octavian: thread out of order maybe? Not sure what you are referring to.
    john: depmod -a?
    chris: hmm, the i2c layer is borked. Try loading ivtv with the option newi2c=0.

  223. 223
    Vish Says:

    Trying to the backend box up with transmitter only.
    output of modprobe:
    ——————-
    Mar 8 11:42:57 mythtv kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Mar 8 11:42:57 mythtv kernel: lirc_pvr150: chip found with RX and TX
    Mar 8 11:42:57 mythtv kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Mar 8 11:42:57 mythtv kernel: lirc_pvr150: firmware of size 248009 loaded
    Mar 8 11:42:57 mythtv kernel: lirc_pvr150: 637 codesets loaded
    Mar 8 11:42:57 mythtv kernel: lirc_pvr150: ivtv i2c driver #1: no devices found

    ———————————-
    # dmesg | grep lirc
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    lirc_pvr150: poll thread started
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #1: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #1: no
    lirc_pvr150: ivtv i2c driver #1: no devices found

    Look at the other posts from Simon and Travis.
    Hardware problem ?
    Using ivtv-kmdl-2.6.18-1.2257.fc5-0.10.1-126.fc5.at

    Thanks
    Vish

  224. 224
    mark Says:

    It looks like you have 2xPVR-150s and it is finding an IR chip on one of them? PVR-500 maybe? If it’s a PVR-500 and it has 1 IR chip then I can’t see a problem here (disclaimer: I don’t actually know what hardware is on the PVR-500s, I don’t own one). What’s the actual issue?

  225. 225
    Vish Says:

    That was quick reply .. really appreciate it.
    I have 2 PVR-150ss.
    One has an IR chip, one does not.
    1042 and 1062.

    So there’s no issue here ?
    I just freaked out when i saw the message and my dmesg didn’t look anything like yours.

    Thanks
    # /sbin/lspci | grep -i mpeg
    01:04.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01)
    01:06.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01)

  226. 226
    mark Says:

    In that case it looks fine.

  227. 227
    Octavian Says:

    Hi Mark,

    Yes my post was out out of order.

    I was trying to answer to:
    John Says: February 8th, 2007 at 3:41 pm

    I have another annoying issue. It works but only when it wants :-) .

    I used to fix it by issuing ivtvctl –reset-ir, as you nicely mentioned in a post.
    Since I have updated to 2.6.19 it does not work anymore :-( . Here is a small listing:

    mythtv ~ # ivtvctl –reset-ir
    ioctl VIDIOC_INT_RESET failed: Invalid argument

    mythtv ~ # uname -a
    Linux mythtv 2.6.19-gentoo-r5 #4 Mon Mar 5 22:50:57 CET 2007 i686 VIA Esther processor 1200MHz CentaurHauls GNU/Linux

    As you can notice the ivtvctl –reset-ir does not work anymore. Could it be because of the kernel or ivtv? Has anyone seen this before?

    Thank you in advance for your answer,
    Octavian

  228. 228
    waldo Says:

    Okay. I got about halfway through the comments and gave up. So I’m sorry if I missed this answer.

    I have a computer running Ubuntu 6.10 with kernel 2.6.17-10-generic. These instructions worked great, the card wasn’t detected, i powered the computer off, powered it back on, and everything worked great.

    Then I ran apt-get update / apt-get upgrade.

    The kernel version didn’t change, but now lirc won’t detect the hardware. I tried both 0.8.1-CVS-pvr150 and the for-cecil versions, and they both resulted in

    Mar 8 19:38:58 pedro kernel: [17181781.636000] lirc_dev: IR Remote Control driver registered, at major 61
    Mar 8 19:38:58 pedro kernel: [17181781.708000] lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    Mar 8 19:38:58 pedro kernel: [17181781.732000] lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    Mar 8 19:38:58 pedro kernel: [17181781.732000] lirc_pvr150: ivtv i2c driver #0: no devices found

    when I modprobed.

    Any advice is more than welcome. SSH access or further information from my computer are readily available.

    Thanks!
    waldo

  229. 229
    mark Says:

    Octavian: I believe that ioctl was removed from the ivtv driver in later versions, you can ask on the ivtv-devel list to be sure. There are stability issues with the crappy software running on the zilog chip that handles the IR, mostly related to timing. I would check that:

    1. you are loading ivtv with newi2c=1 (this should be the default if the card has the IR chip, but you can force it)
    2. if this does not work, please hack up the driver source ;) Here is what the new hauppauge windows driver does:

    - the ivtv_scldelay equivalent function has changed from polling SCL 5 times to polling SCL 5 times + HcwI2CSpeedAdjust. I am not sure how the value of HcwI2CSpeedAdjust is determined
    - ivtv_scldelay, ivtv_waitscl, ivtv_waitsda all take an extra adjustment parameter which is added to to the total amount (but is only ever set to -1 in one place AFAICT)
    - there are some extra ivtv_scldelay() calls dotted about

    Basically you can increase the delay lengths. If this does help get back to me, I am still waiting on a guy from hauppage for an answer to where this magic delay parameter comes from.

    Waldo: try powering it off, then yanking the power cord from the wall (seriously, we want it _absolutely_ powered off), waiting for about a minute, then plugging it back in and powering it up again. If that doesn’t work let me know.

    hth,

    Mark

  230. 230
    waldo Says:

    Waldo: try powering it off, then yanking the power cord from the wall (seriously, we want it _absolutely_ powered off), waiting for about a minute, then plugging it back in and powering it up again. If that doesn’t work let me know.

    I tried this. Like I said, it solved the problem pre-upgrade, but alas, not this time. Sorry. I unplugged it. Punched the power button. Wandered off and did laundry and made dinner. hit the power button again. Plugged it in. No dice.

  231. 231
    Patrick Says:

    Mark,

    First I’d like to thank you for your time with this. I’ve used your driver for a while now.

    Ok – Like a idiot i’ve upgraded to Ubuntu Fiesty. This uses kernel 2.6.20. This meant I had to use IVTV 10.1. Well your driver compiles fine but won’t load.
    Searching through dmesg shows;
    [ 3369.491982] lirc_pvr150: disagrees about version of symbol ivtv_reset_ir_gpio
    [ 3369.491992] lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

    Any Ideas?


    Patrick

  232. 232
    Patrick Says:

    Hi again.

    Discovered I don’t need to compile an IVTV driver for Fiesty. It already comes with one.
    I reinstalled the linux-image now the IVTV is working fine, but I still get the error;

    [ 3369.491982] lirc_pvr150: disagrees about version of symbol ivtv_reset_ir_gpio
    [ 3369.491992] lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio


    Patrick

  233. 233
    mark Says:

    waldo: if it can’t find the hardware then there isn’t much to do. Can you check to ensure that lirc_i2c is not hanging around anywhere (you should be able to see this from dmesg), as if it has grabbed the hardware first then the lirc_pvr150 driver won’t be able to see it. If not, can you try loading ivtv with newi2c=0 and newi2c=1 to see if that makes any difference? I can’t think of anything else that might cause it at the moment.

    patrick: can you remove the sections of the code in drivers/lirc_pvr150/lirc_pvr150.c that call ivtv_reset_ir? It seems this has been killed off so we will have to do without it, I will look into the latest ivtv driver soon as I now have my spare PVR-150 (I just need to build a machine to put it in!)

  234. 234
    Patrick Says:

    Hi Mark,

    Yep that got me up and running.

    Now I’ve just got to solve the picture breakup in Mythtv.

  235. 235
    waldo Says:

    Tired of re-posting when captcha eats my comment.

    All is working again, needed to switch ivtv to newi2c=1 and to use lirc_i2c instead of lirc_pvr150 (i used to use pvr150)

  236. 236
    Simon Says:

    Has anyone got this working with Ubuntu Edgy?

    I keep running into problems when doing make install, similar to problems encountered by other posters above. However I can’t find how people fixed those problems.

    Thanks,

    Simon

  237. 237
    mark Says:

    patrick: cool!
    waldo: sorry about captcha, but I couldn’t deal with the volume of spam I was getting without it. Glad you’ve got it working in the end though.
    simon: you need to be more specific, what’s the exact error message you are encountering?

  238. 238
    Simon Says:

    Mark,

    Sorry, my info was a bit scant.

    Running Ubuntu Edgy with IVTV 0.7.4, which seems to be working fine in that I can watch output from the PVR-150 through Myth.

    I followed the instructions on the mythtv wiki to install lirc in Ubuntu Edgy to get the remote working.
    I then found your excellent instructions to install the blaster. I keep getting stuck at point 3, which then means that point 5 fails. Make seems to work, make install fails with output very similar to that posted by Adam on April 13th 2006.

    I’ve tried the original pre-patched lirc 0.8.1-CVS-pvr150 tarball, the for cecil version and the updated version you created for Adam and Dave.
    I’ve also tried uninstalling all the versions of lirc I can find on my machine and starting from scratch, but no joy.

    Any suggestions gratefully appreciated.

    Thanks,

    Simon

  239. 239
    mark Says:

    Simon, please try this one and see if it fixes your issue:

    lirc-0.8.2-CVS-pvr150.tar.bz2

    I have finally updated the codeset dump using the latest software on hauppauge’s site. There are now 654 codesets — which is an increase of just 20. Would those who asked for it please give it a try and let me know?

    Thanks,

    Mark

  240. 240
    mark Says:

    *cough*link*cough*

    Also the send_power new script has been updated:

    send_power_new

    And the codesets page:

    IRcodesets.html

  241. 241
    Kevin Gray Says:

    Mark,

    I tried installing MythDora (FC5), and it installed very simply and saved a lot of hassle; however, the one thing that doesn’t seem to work for me out of the box is the IR Blaster for my PVR-150.

    My first issue is that when I try to send with “irsend”, I get the following error:

    “irsend: hardware does not support sending”

    From your site, it appears this is due to the lirc_i2c module being installed, versus the lirc_pv150 being installed. When I successfully compile the pvr150 module though, when I modprobe it, I get the error that I’m installed two things with the same name (due to lirc_i2c being installed). In one of your comments to another user, I see that you mention that i2c has to be removed and pvr150 installed. I can’t see to find a way to do this cleanly.

    Could you point me in the right direction? Also, does removing the i2c module and inserting the pvr150 module require any changes to the ivtv module?

    Hope this question makes sense,
    kg

  242. 242
    mark Says:

    Just uninstall the lirc package first. Something like:

    rpm -qa |grep lirc
    rpm -e lirc-package

    should do. wrt to ivtv, any version >= 0.4.2 should work.

  243. 243
    Don Says:

    Mark,

    Looks like your permissions are wrong on the firmware files. I can read download them.

  244. 244
    mark Says:

    You were spot on — I have now fixed this. Sorry for the mistake!

  245. 245
    Mickey Says:

    hi mark and others

    I had a lot of problems with my PVR150 and lirc, but after reading hundreds of sites and comments I was somehow able to made lirc recognize my remote. I used lirc from cvs and ivtv 0.10.1 with newi2c=1.

    and that was working for a few days. today I made a mistake to recompile my kernel. that cleaned the /lib/modules/2.6.20.1 and deleted ivtv and lirc_* modules. I thought that is not such a big deal and I recompiled my lirc and ivtv modules. But now the remote is again not being recognized, and I have the same situation like a few days before.

    I tried you modules, but nothing changed:
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found

    I checked my yesterday’s syslog and found this:
    lirc_i2c: no version for “lirc_unregister_plugin” found: kernel tainted.
    lirc_i2c: chip found @ 0×71 (Hauppauge IR (PVR150))

    How can this happen? Any ideas or suggestions? I never had such a stupid problem in all these years.

    I am able to watch TV with pvr150 but there is no remote. I tried newi2c=0 and =1 without success.

    Is it somehow possible to tell lirc_i2c that PVR150 is on “0×71″ and that is should not try to recognize it? Or something else?

    Thanks.

  246. 246
    mark Says:

    Try something like ivtvctl –reset-ir && rmmod lirc_pvr150 && modprobe lirc_pvr150

  247. 247
    Mickey Says:

    No changes. And –reset-ir gives this error:

    ioctl VIDIOC_INT_RESET failed: Invalid argument

    dmesg after loading ivtv and lirc_pvr150:
    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.10.1 (tagged release) loading
    ivtv: Linux version: 2.6.20.1 SMP mod_unload K8
    ivtv: In case of problems please include the debug info between
    ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    ivtv: any module options, when mailing the ivtv-users mailinglist.
    ivtv0: Autodetected Hauppauge card (cx23416 based)
    ACPI: PCI Interrupt 0000:03:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 22
    ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
    ivtv0: Encoder revision: 0×02060039
    tveeprom 5-0050: Hauppauge model 26134, rev F1B3, serial# 10233063
    tveeprom 5-0050: tuner model is TCL M2523_3DB_E (idx 113, type 55)
    tveeprom 5-0050: TV standards PAL(B/G) PAL(D/D1/K) (eeprom 0×44)
    tveeprom 5-0050: audio processor is CX25842 (idx 36)
    tveeprom 5-0050: decoder processor is CX25842 (idx 29)
    tveeprom 5-0050: has no radio, has IR receiver, has IR transmitter
    ivtv0: Autodetected Hauppauge WinTV PVR-150
    tuner 5-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    cx25840 5-0044: cx25842-23 found @ 0×88 (ivtv i2c driver #0)
    cx25840 5-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    wm8775 5-001b: chip found @ 0×36 (ivtv i2c driver #0)
    ivtv0: Registered device video0 for encoder MPEG (4 MB)
    ivtv0: Registered device video32 for encoder YUV (2 MB)
    ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    tuner 5-0061: type set to 55 (TCL 2002MB)
    ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    ivtv: ==================== END INIT IVTV ====================
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found
    lirc_pvr150: ivtv i2c driver #0: no devices found
    lirc_pvr150: ivtv i2c driver #0: no devices found

    I was really loving it for a last few days, but I almost hate it at the moment.

    Is this lirc or ivtv problem?

  248. 248
    mark Says:

    –reset-ir should work, try asking ivtv-devel and see if Hans can help you out.

    It is basically an i2c issue, either lirc_i2c or lirc_pvr150 will work, but only if they can talk to the hardware. The IR chip on the PVR-150 is very sensitive to timing issues, and once it has crashed you can either reset it (if –reset-ir works), or you can power off the machine, disconnect the power cord, wait for a minute or so, then power it up again.

    Please try either/both of the above and get back to me; if you are still having trouble and are willing I will have a poke via SSH (won’t be until later this week though, I have a lot of work on up to about Thursday).

    HTH,

    Mark

  249. 249
    Mickey Says:

    I send the question to ivtv-devel and I will report back if I get some new ideas.

    cold reboot didn’t work, but I will try to change the PCI slot with my sound card. I will test it today in the evening. I will try –reset-ir once more after moving to another PCI slot.

    I was using ivtv-0.10.1 (and lirc-cvs) because I got some compile errors with ivtv-cvs (missing v4l2…. files, it looked like dvb support. i will check/try it one more time).

    thanks a lot

    M.

  250. 250
    Mickey Says:

    I tried cold reboot once more, but without succes. Still the same.
    —————-
    lirc_dev: IR Remote Control driver registered, at major 61
    cx2388x v4l2 driver version 0.0.6 loaded
    lirc_i2c: probe 0x1a @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×18 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×71 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0x4b @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×64 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×30 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0x6b @ ivtv i2c driver #0: no
    —————-

    also no success with your lirc_pvr150. I would be ready to give you root password for SSH, if you think that you can do something to repair this. I am thinking about giving back this card or I will maybe try to replace it.

    Ideas?

    Thanks a lot one more time.

  251. 251
    Mickey Says:

    I am spamming your blog :( . Moving PVR150 to a new PCI slot did not help. Same problem.

    –reset-ir also still does not react.
    —————–
    ivtvctl –reset-ir
    ioctl VIDIOC_INT_RESET failed: Invalid argument
    —————–

    I tried old versions of ivtvctl was not able to recognize itvt device …

    M.

  252. 252
    Yadav Says:

    Hey, how long do you estimate it will be until 2.6.19 support is available? Sorry to bother you, it´s the last thing left until I finish my PC.

  253. 253
    Mickey Says:

    Man … and I think that I hate this PVR …

    It is working again … And I did nothing. I went to sleep yesterday after giving up and today after reboot, that card is working … I got some new messages after modprobe debug=1:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_dev ([-1]): open called
    lirc_dev ([-1]): open result = -ENODEV
    lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    lirc_pvr150: poll thread started
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    And I have a bad feeling about rebooting my computer :) ). I will this PVR a chance until weekend, and if I/you don’t find a working solution to be able always to use it, I get a new one.

  254. 254
    Mickey Says:

    Hi … me again and again and again …

    It worked for two days. But now I booted, and the remote is again not recognized.

    —————————-
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found
    —————————-

    I hope that you find time to help me with this really stupid problem. Thanks a lot. I will send you ssh login data if you have enough time.

    Thanks a lot.

  255. 255
    Mickey Says:

    I am using your homepage as a chat :( . I am really sorry to interrupt you, but I it is working again. I put the computer to sleep (echo mem > /sys/power/state) and I “re-modprobed” the modules and everything was OK.

    –reset-ir still gives the same error:
    ioctl VIDIOC_INT_RESET failed: Invalid argument

    my “offer” to give you a chance to help is still open :) . Thanks.

  256. 256
    Kellen Says:

    Hello,

    Thanks for the driver! It works for a wintv-go card after much fiddling with kernel modules and I was wondering if it is possible to make the ir driver independent of ivtv. ivtv has a nasty habit of destabilizing my system and it would be great if I didn’t have to load it.

    Thanks again for the effort!

  257. 257
    Octavian Says:

    Hi Marc,

    Long time no comment.

    After a lot of trials I’ve concluded that the remote only works after a reset. Looks like trivia section.

    This is very annoying since one has to reset the computer several times until the remote starts working.

    In the past it ALWAYS worked by issuing a ivtvctl –ir-reset. With the latest drivers this is not possible anymore.
    I have tried to write a feature request to the ivtv team biut I could not find the palce. Only developers can write tickets?

    Best regards,
    Octavian

  258. 258
    Octavian Says:

    BTW.
    1. I had to submit the text several times until it got published.
    2. I never mentioned it before, but you give excellent support to the poor users. GOOD JOB

    P.S. One error was:
    WORLD PRESS
    Error: please type a comment.

  259. 259
    deon stoltz Says:

    Hi
    It seems your lircd.conf does not contain the (blaster) cmd for codeset 682 (Dstv) although it is listed in your IRcodesets page (we are lucky!). I am not sure how to add this. Do ou have an updated copy?
    Thx
    Deon
    (ps. second post, got only a black screen last time so not sure if it went thru or not)

  260. 260
    Dave Rose Says:

    Any chance of getting a 2.6.20 kernel to work:

    [root@draco lirc-0.8.1-CVS-pvr150]# modprobe lirc_dev
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_dev.ko): Invalid module format
    FATAL: Error running install command for lirc_dev
    [root@draco lirc-0.8.1-CVS-pvr150]# modprobe lirc_pvr150
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_dev.ko): Invalid module format
    WARNING: Error running install command for lirc_dev
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_dev.ko): Invalid module format
    WARNING: Error running install command for lirc_dev
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_pvr150.ko): Invalid module format
    FATAL: Error running install command for lirc_pvr150

    lirc_dev: disagrees about version of symbol struct_module
    lirc_dev: disagrees about version of symbol struct_module
    lirc_dev: disagrees about version of symbol struct_module
    lirc_pvr150: disagrees about version of symbol struct_module

  261. 261
    richard joss Says:

    Mark – what a great set of stuff on your site. I want to try and get the remote and ir blaster that comes with the pvr150 to change channels on my pace 2600N sky digibox. I’m running mythtv on fedora fc6 and have managed to get mythtv to show sky output OK. Also, the haup remote works ok with the PC.

    My question is: The fc6 kernel is 2.6.20-1 and therefore more uptodate than the kernels your stuff relates to. I can do a bit of compiling but not much more than that. Will your files run ok with this kernel, or should I wait for your next updates? It has taken me ages to get mythtv to work and i don’t want to try installing older kernels!

    Can you help?

    Thanks.

    PS – get my remote to change channels on a sky box and you definitely have a contribution on the way .

    Regards

    Richard

  262. 262
    richard joss Says:

    mark

    PS – tried the email address in earlier posts (nspl) but it bounced – probably a bit out of date?

  263. 263
    richard joss Says:

    Sorry Mark, my bad. I sent a copy of the above to your email address in an ealier post but typed it wrongly. Have now resent it.

    Richard

  264. 264
    mark Says:

    Hi Mickey, wrt to the ivtvctl –reset-ir, we are still waiting on a resolution from Hans, the ivtv driver developer, who says it should be straightforward. He’s still out of action for a bit though as he’s moving house.

    Kellen: I am surprised it works for a non PVR-150 card. Does that thing have an IR blaster? What driver is the card using? If ivtv is not in use I can’t see how it would destabilise your system.

    Deon: I have updated the lircd.conf linked above, I missed this the first time around, please download it again.

    To all those using 2.6.20 kernels please try this port. It is linked to in the comments above somewhere, but I am awaiting feedback from somebody to let me know it works before updating the main post text.

    HTH,

    Mark

  265. 265
    Amankhan Says:

    Hi Mark,

    I just tested out the port of your driver for the 2.6.20 kernel, and I’m getting this response when I run the intial ./configure:

    configure: error: no driver specified, try ./configure –help

    Can’t get as far as the choosing of a TV card, h – Hauppauge PVR-150 TV card, etc.

  266. 266
    mark Says:

    The GUI has been renamed to setup.sh, run that instead.

  267. 267
    Amankhan Says:

    Thanks, Mark. That did the trick.

    I completed the rest of the install, and everything is working perfectly now. Thanks again for all your hard work!

  268. 268
    Peter Says:

    Ok, so I am having some issues…obviously J I have a 150 MCE card with an IR Blaster. I can get the remote to send commands and can see them on irw. I have compiled the cvs version of lirc, because I could not get your version to compile. I am running Fedora Core 6 [2.6.20-1.2944]. Should I try to compile the version you made for cecil? I have a Philips STB on Surewest cable.

    Output of dmesg | grep lirc
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_mceusb2: no version for “lirc_get_pdata” found: kernel tainted.
    lirc_mceusb2: Philips eHome USB IR Transciever and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.28 $
    lirc_mceusb2: Daniel Melander , Martin Blatter
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_mceusb2[3]: Topseed eHome Infrared Transceiver on usb1:3
    usbcore: registered new interface driver lirc_mceusb2
    usbcore: deregistering interface driver lirc_mceusb2
    lirc_mceusb2[3]: usb remote disconnected
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_mceusb2: Philips eHome USB IR Transciever and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.28 $
    lirc_mceusb2: Daniel Melander , Martin Blatter
    lirc_mceusb2: debug mode enabled
    lirc_mceusb2: usb probe called
    lirc_mceusb2: acceptable outbound endpoint found
    lirc_mceusb2: acceptable inbound endpoint found
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_mceusb2[3]: Topseed eHome Infrared Transceiver on usb1:3
    lirc_mceusb2[3]: receive request called (size=0×10)
    lirc_mceusb2[3]: receive request complete (res=0)

    Output of dmesg | grep ivtv
    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.10.1 (tagged release) loading
    ivtv: Linux version: 2.6.20-1.2944.fc6 SMP mod_unload 686 4KSTACKS
    ivtv: In case of problems please include the debug info between
    ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    ivtv: any module options, when mailing the ivtv-users mailinglist.
    ivtv0: Autodetected Hauppauge card (cx23416 based)
    ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
    ivtv0: Encoder revision: 0×02060039
    ivtv0: Autodetected Hauppauge WinTV PVR-150
    tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    cx25840 1-0044: cx25843-23 found @ 0×88 (ivtv i2c driver #0)
    wm8775 1-001b: chip found @ 0×36 (ivtv i2c driver #0)
    ivtv0: Registered device video0 for encoder MPEG (4 MB)
    ivtv0: Registered device video32 for encoder YUV (2 MB)
    ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    ivtv: ==================== END INIT IVTV ====================

    It is not loading the firmware that you made. How can I go about getting it to load. Where does it need to go? Do I need to send a command to ivtv to tell it to use a different firmware?

    When I send a command to the irblaster with irsend it sends successfully but It does not blink.

    Any help would be great!!! Thanks.

  269. 269
    Greg Says:

    Hey Mark-

    Your solution worked great on Ubuntu 7. I only had a few problems because I had previously set it up to just use the receiver. Removing the i2c module fixed it all. The only thing I am wondering now is if I can use this blaster to turn my TV on and off via the remote. Any thoughts on if that is possible, and if so, how?

    Thanks!
    Greg

  270. 270
    greg Says:

    I did a little more playing and see that my TV responds to some of the commands, but only by flashing a green light. I assume this just means it is seeing some sort of IR that it recognizes, but doesn’t know what to do with it. I also set up irw to listen to the current TV remote to see what the power command was. When it listens to the power command, it shows 0x000000000000100C. I was thinking that maybe if I was able to convert this into one of the raw codes that the blaster seems to deal with, maybe it would control the TV. Straight up hex->dec conversion does not seem to work with the blaster. Any ideas on how to get the power code for my TV into the blaster configuration file?

    Thanks again,
    Greg

  271. 271
    Arvedui Says:

    Similar to Amankhan, I am having trouble getting started building the driver. I am running 64-bit Fedora Core 6, kernel version 2.6.20 as root. I have tried ./configure and ./setup.sh, and several other permutations. The errors returned include the path that is being searched and behave like it cannot find the script processor.

    Any ideas?

  272. 272
    mark Says:

    Peter: this is not for the MCE version, I don’t know anything about that.
    Greg: As I’ve repeated many times above, you can only send what’s in the Hauppauge database. If none of the codesets work with your TV, it’s unfortunate, but that’s it, you’re stuffed.
    Arvedui: Can’t tell anything without the error message.

  273. 273
    Peter Says:

    Mark:

    I did get the blaster to work, turns out that I had the ir cable plugged into port 1 instead of port 2…go figure. After a few days it stopped working after I did a cold boot…damn!

    I think that your port of lirc does work with the mce version, I just reinstalled and am trying again. One question still remains in my head unanswered, how does lirc know about the .bin firmware. What loads it and when?

    Anyone else have luck getting the mce version to work?

  274. 274
    mark Says:

    The tarball contains the whole of lirc, there wasn’t any point chopping it out, with the addition of a specific driver for the vanilla PVR-150. lirc_mceusb is a totally different piece of hardware and does not use my driver, full stop. I would suggest a) using the vanilla lirc package and b) asking on the lirc lists about any issues (you want the vanilla package because they almost certainly will not want to support it if you are using some random development snapshot of the driver, which basically you are). Since this piece of hardware is in their main distribution they are _much_ more likely to be able to help you out than I am. I don’t possess an MCE flavour card and so really am not going to be able to diagnose any issues with it.

  275. 275
    Peter Says:

    Mark:

    I will try to emulate my actions that led up to the successful changing of channels on my STB last week. By the vanilla release, I take it you mean the plain distro of lirc? I will let you know I I can get this working tonight. I am really pissed since it was working. I was able to use ircrecord to get the raw codes and the channels were getting changed…

  276. 276
    mark Says:

    Yes, see http://lirc.org.

  277. 277
    Mike Says:

    Mark,

    I have followed your instructions, and everything seems to be working OK except certain codes on the IR blaster.

    The blaster blinks merrily as it works its way through your script, but when it hits certain codes I get errors and the LED does not blink.

    I compiled lirc with the debug assertions enabled. Here is what I get when I try to send one of these codes:

    root@mythtv:/usr/bin# irsend SEND_ONCE blaster 1_125_KEY_POWER
    buffer: -BEGIN-
    buffer: -SEND_ONCE blaster 1_125_KEY_POWER-
    buffer: -ERROR-
    irsend: command failed: SEND_ONCE blaster 1_125_KEY_POWER
    buffer: -DATA-
    buffer: -1-
    buffer: -transmission failed-
    irsend: transmission failed
    buffer: -END-

    This is accompanied by a syslog message like this:

    lirc_pvr150: failed to get data for code 32893, key 10 — check lircd.conf entries

    I am pretty certain my lircd.conf is fine.

    As coincidence would have it, I think one of these codes (1_125) will control my DirecTV set-top box, thus leaving me with a bit of a problem. From reading the Hauppauge site, I think this blaster ought to work OK with DirecTV boxes.

    Can you offer any guidance? My system is a new KnoppMyth install, version R5F1.

  278. 278
    Ziggy Says:

    Hi Mark,

    First off, thanks for all the work you’ve put into this. I’m trying to get the IR blaster to work for the WinTV-PVR-USB2 which i read on mythtv’s website should in theory be able to work just like the PVR-150. Do you know if this is in fact the case? Sorry if someone’s already mentioned this on the replies, but i didn’t notice anything after a quick search.

    Anyway, it looks like the chip is being found, but things still don’t work. Here’s my output from dmesg:

    [ 44.340000] lirc_pvr150: chip found with RX and TX
    [ 44.340000] lirc_dev: lirc_register_plugin: sample_rate: 0
    [ 44.376000] lirc_pvr150: firmware of size 258140 loaded
    [ 44.376000] lirc_pvr150: 654 codesets loaded
    [ 44.400000] lirc_pvr150: i2c_master_send failed with -5

    Is there a way to get more information on what the last line means? Any help would be appreciated. Thanks.

    Ziggy

  279. 279
    Jason Says:

    Just wanted to stop in and say thanks! Your PVR-150 package worked great.

    I hope you don’t mind I wrote up a blog post with some instructions on how to get it to work with MythDora 4.0 and a Scientific Atlanta Explorer 2200. I referred back to your site for the files and module installation instructions and if a different receiver was to be used. I just wanted make it easy for people that want to switch to the new MythDora 4.0 setup. Keep up the good work!!!

    http://charles.hopto.org/blog/?p=24

  280. 280
    Paul Says:

    Greg, could you give more details of how you installed in Ubuntu 7 ( feisty) and removing the i2c module. Thanks

  281. 281
    Jason Says:

    Just wanted to stop in and say thanks! Your PVR-150 package worked great.

    I hope you don’t mind I wrote up a blog post with some instructions on how to get it to work with MythDora 4.0 and a Scientific Atlanta Explorer 2200. I referred back to your site for the files and module installation instructions and if a different receiver was to be used. I just wanted make it easy for people that want to switch to the new MythDora 4.0 setup. Keep up the good work!!!

  282. 282
    Amankhan Says:

    Hi again, Mark.

    Just wanted to let you know that the 2.6.20 version does not work with the new Fedora 7 kernel. (2.6.21-1.3228.fc7). I didn’t exactly expect it to work, but just thought it might be good to let you know that I did attempt it. Here’s the error message I’m getting when trying to modprobe lirc_dev:
    a
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.21-1.3228.fc7/misc/lirc_dev.ko): Invalid module format

  283. 283
    ryan Says:

    I just bought a pvr-150, and I’ve followed all the guides, and at this point, the card works. I can tune in TV, get sound and so on. (has same remote and IR blaster I’ve seen in pictures).

    So I wanted to get the remote to work next. Followed this guide. As far as my problem, everything works except I can’t get any response when using irw. I can see junk appear if I “cat /dev/lirc/0″, or if I use mode2 I can see the codes come up as I hit buttons on the remote. I tried using irrecord, but no matter what I do, it gives me a junk lircd.conf file (the codes in the created file are all 0). None of the lircd.conf files I’ve found anywhere work. Im assuming the problem must be with the configuration somewhere as the computer knows when the remote is being hit.

    dmesg output
    [code]ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.10.1 (tagged release) loading
    ivtv: Linux version: 2.6.18-gentoo-r3 SMP mod_unload gcc-4.1
    ivtv: In case of problems please include the debug info between
    ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    ivtv: any module options, when mailing the ivtv-users mailinglist.
    ivtv0: Autodetected Hauppauge card (cx23416 based)
    ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
    GSI 20 sharing vector 0xD1 and IRQ 20
    ACPI: PCI Interrupt 0000:05:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 20
    ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
    nvidia: module license 'NVIDIA' taints kernel.
    ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
    ivtv0: Encoder revision: 0x02060039
    tveeprom 2-0050: Hauppauge model 26152, rev E5B2, serial# 10317213
    tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08)
    tveeprom 2-0050: audio processor is CX25843 (idx 37)
    tveeprom 2-0050: decoder processor is CX25843 (idx 30)
    tveeprom 2-0050: has no radio, has IR remote
    ivtv0: Autodetected Hauppauge WinTV PVR-150
    ivtv0: reopen i2c bus for IR-blaster support
    tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
    cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
    ivtv0: Registered device video0 for encoder MPEG (4 MB)
    ivtv0: Registered device video32 for encoder YUV (2 MB)
    ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    tuner 2-0061: type set to 50 (TCL 2002N)
    ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    ivtv: ==================== END INIT IVTV ====================
    ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
    GSI 21 sharing vector 0xD9 and IRQ 21
    ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 21
    PCI: Setting latency timer of device 0000:01:00.0 to 64
    NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9755 Mon Feb 26 23:16:31 PST 2007
    EXT3 FS on md2, internal journal
    usbcore: registered new driver usbserial
    drivers/usb/serial/usb-serial.c: USB Serial Driver core
    drivers/usb/serial/usb-serial.c: USB Serial support registered for Handspring Visor / Palm OS
    drivers/usb/serial/usb-serial.c: USB Serial support registered for Sony Clie 3.5
    drivers/usb/serial/usb-serial.c: USB Serial support registered for Sony Clie 5.0
    usbcore: registered new driver visor
    drivers/usb/serial/visor.c: USB HandSpring Visor / Palm OS driver
    it87: Found IT8712F chip at 0x290, revision 7
    it87-isa 9191-0290: Detected broken BIOS defaults, disabling PWM interface
    md: md0 stopped.
    md: bind
    md: bind
    raid1: raid set md0 active with 2 out of 2 mirrors
    Adding 1011832k swap on /dev/md1. Priority:-1 extents:1 across:1011832k
    eth0: no IPv6 routers present
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: chip found with RX and TX
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 258140 loaded
    lirc_pvr150: 654 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 2.1.0
    [/code]

    current versions of everything are (this is all on gentoo):
    whatever is on mark’s site
    ivtv 0.10.1-r1
    lirc 0.8.2_pre2 (and 0.8.1)
    kernel 2.6.18r3

  284. 284
    mark Says:

    Mike: the config file is wrong/mismatched with the dump file. Please check what you have got is what is linked above.

    Amankhan: Thanks for the info, I will update it at some point.

  285. 285
    Damian Says:

    Mark : Thanks! I got my feisty set up controlling my BSkyB box nicely.

    I just want to follow up on a previous post and merging your patch with LIRC. You said it was due to the firmware BLOB. Have Happauge not opened this up since? Or what is the situation? It would be great to not have to worry about a recompile every kernel change. All I would need is my lirc.conf! Also does ivtv being included in 2.6.22 make things easier?

    Thanks for all your effort on this.
    D.

  286. 286
    Seth Says:

    I’ve got the LIRC part working, and am even able to control Myth TV using the remote. However, when I try to send a command to my Dish 301 box, it fails. Here is the whole transcription:
    DVR:/home/mythtv# modprobe lirc_dev
    DVR:/home/mythtv# modprobe lirc_pvr150 debug=5
    DVR:/home/mythtv# lircd –device=/dev/lirc0
    DVR:/home/mythtv# exit
    exit
    schuyler@DVR:~$ irw
    00000000000017a1 00 Ch- hauppauge
    00000000000017a1 00 Ch- hauppauge
    00000000000017a0 00 Ch+ hauppauge
    00000000000017a0 00 Ch+ hauppauge
    0000000000001791 00 Vol- hauppauge
    0000000000001790 00 Vol+ hauppauge
    0000000000001790 01 Vol+ hauppauge

    mythtv@DVR:~$ irsend SEND_ONCE blaster 1
    irsend: command failed: SEND_ONCE blaster 1
    irsend: transmission failed

    And here is how it looks in /var/log/lircd:
    Jul 10 18:46:50 DVR lircd: lircd(hauppauge_pvr150) ready
    Jul 10 18:46:57 DVR lircd: accepted new client on /dev/lircd
    Jul 10 18:48:17 DVR lircd: removed client
    Jul 10 18:49:01 DVR lircd: accepted new client on /dev/lircd
    Jul 10 18:49:01 DVR lircd: write failed
    Jul 10 18:49:01 DVR lircd: Protocol error
    Jul 10 18:49:01 DVR lircd: error processing command: SEND_ONCE blaster 1
    Jul 10 18:49:01 DVR lircd: transmission failed
    Jul 10 18:49:01 DVR lircd: removed client

    I checked the permissions:
    DVR:~$ ls -l /dev/lirc*
    crw-rw—- 1 root video 61, 0 2007-07-09 21:49 /dev/lirc0
    srw-rw-rw- 1 root root 0 2007-07-10 18:46 /dev/lircd

    It is frustrating being so close, yet so far. Any ideas?

  287. 287
    phoner Says:

    I\’m trying to get the ir blaster to work with the motorola vip1200 (u-verse stb). The hauppauge software successfully learns the codes, how can I get them for use in lirc?

  288. 288
    Seth Says:

    I followed your instructions, and I’ve been able to get lirc working, but I can’t get the IR Blaster working. This is what I get.
    DVR:/home/mythtv# modprobe lirc_dev debug=1
    DVR:/home/mythtv# modprobe lirc_pvr150 debug=1
    DVR:/home/mythtv# lircd –device=/dev/lirc0
    DVR:/home/mythtv# irsend SEND_ONCE blaster 1
    irsend: command failed: SEND_ONCE blaster 1
    irsend: transmission failed

    I didn’t see any clues in the syslogs, but I’ve included them in case you see something I don’t.
    From /var/log/lircd:
    Jul 15 20:11:57 DVR lircd: lircd(hauppauge_pvr150) ready
    Jul 15 20:21:15 DVR lircd: accepted new client on /dev/lircd
    Jul 15 20:21:15 DVR lircd: write failed
    Jul 15 20:21:15 DVR lircd: Protocol error
    Jul 15 20:21:15 DVR lircd: error processing command: SEND_ONCE blaster 1
    Jul 15 20:21:15 DVR lircd: transmission failed
    Jul 15 20:21:15 DVR lircd: removed client
    From /var/log/messages:
    Jul 15 20:06:30 DVR kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: chip found with RX and TX
    Jul 15 20:09:52 DVR kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: firmware of size 258140 loaded
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: 654 codesets loaded

    Any thoughts?

  289. 289
    Seth Says:

    I’m have a problem that seems related to Andrew Barbaccia’s and Mickey’s.

    I tried the cold reboot and the reset and still got:
    ivtvctl –reset-ir
    ioctl VIDIOC_INT_RESET failed: Invalid argument

    In /var/log/messages I get:
    Jul 28 22:26:04 DVR kernel: lirc_dev: IR Remote Control driver registered, at m\
    ajor 61
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: no version for “lirc_unregister_plugin\
    ” found: kernel tainted.
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: chip found with RX and TX
    Jul 28 22:26:19 DVR kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: firmware of size 258140 loaded
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: 654 codesets loaded

    I think this is why I was getting a protocol error when trying an IRsend.

    The “kernel tainted” and lack of “firmware version 1.3.0″ message is what makes me think it is related, but since I didn’t see a response after a request was put in to Hans, I was wondering if Hans ever got back to you.

  290. 290
    Lance Says:

    Mark, thanks for all your hard work on this site. I feel as though you may be one of the few people who can help me get my PVR-150 remote to work.

    I am having the same issues as Noah. However, I didn’t see where the solution was for him or if it was fixable. I have not however, got the remote to work with a Linux release. I have tried both Ubuntu Edgy and Feisty. I can watch live TV no problem with MythTV in either release.

    Here is everything I have tried:

    Same hardware, different hard drive, the remote works with WinXP. So hardware should be ruled out.

    rmmod ivtv then modprobe ivtv with newi2c=0 and newi2c=1, no go.

    Tried both lirc_i2c and lirc_pvr150. Neither works with newi2c=0 nor newi2c=1.

    i2cdetect, looks the same as Noah’s, nothing appearing for 0×71.

    I have also set the BIOS PCI Latency Timer to 64 and 128. I have also set it at 32 and then overrode ivtv’s desire to set it to 64. No go here either.

    I have also downloaded your lirc-0.8.2-CVS-pvr150.tar.bz2 and tried it as well instead of the Ubuntu packages. No dice.

    Actually I do not need the blaster portion of the PVR-150 at this point. Going to use the built in tuner. I assume I can still use the lirc_pvr150 module.

    Any of the above attempts have all resulted in the usual messages from either lirc_i2c or lirc_pvr150 giving the following message(s):

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_i2c: probe 0x1a @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×18 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×71 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0x4b @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×64 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×30 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0x6b @ ivtv i2c driver #0: no

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no

    I even went to the trouble of adding some of my own debug code to lirc_i2c.c to verify where the issue is. The call to the i2c_master_recv function never returns a successful probe for any of the addresses it is checking.

    Any suggestions on how to get the IR chip to respond?

  291. 291
    Michael Evans Says:

    There is a know issue with kernel 2.6.22 and higher… Something about a structure’s string area becoming truncated and the end of the string over-writing a mutex. I seem to have that same issue and wonder if the pvr150 driver requires a similar patch.

    http://bugs.gentoo.org/show_bug.cgi?id=187822

    It would also be nice to know which patch-set to apply against gentoo’s sources so I could instead create my own portage overlay package with just the additional patch, instead of just saying grab the CVS tarball you’ve prepatched.

  292. 292
    Michael Evans Says:

    I highly suspect that mutex issue mentioned above. I tried configuring it your way, then doing a slightly modified gentoo style ./configure && make && make install. Locks up when I try to modprobe -v lirc_pvr150 . It prints absolutely nothing useful, except for it loading lirc_dev and lirc_pvr150.

    Here’s the ./configure, and the only additional patch I made was the one from the gentoo bugzilla thread linked in my prior post.

    /configure –prefix=/usr –host=x86_64-pc-linux-gnu –mandir=/usr/share/man –infodir=/usr/share/info –datadir=/usr/share –sysconfdir=/etc –localstatedir=/var/lib –localstatedir=/var –with-syslog=LOG_DAEMON –enable-sandboxed –with-kerneldir=/usr/src/linux –with-moduledir=/lib/modules/2.6.22-gentoo-r3/misc –disable-debug –with-x –with-driver=hauppauge_pvr150 –with-transmitter –libdir=/usr/lib64 –build=x86_64-pc-linux-gnu

  293. 293
    Michael Evans Says:

    (Hope this isn’t a duplicate, it seemed to dislike it the other two times.)

    This may also be useful.

    [ 124.698229] ivtv: ==================== START INIT IVTV ====================
    [ 124.698233] ivtv: version 1.0.0 (2.6.22-gentoo-r3 SMP mod_unload ) loading
    [ 124.874633] PM: Adding info for No Bus:pcmC1D2c
    [ 124.874688] PM: Adding info for No Bus:pcmC1D1p
    [ 124.874712] PM: Adding info for No Bus:pcmC1D1c
    [ 124.874735] PM: Adding info for No Bus:adsp1
    [ 124.874757] PM: Adding info for No Bus:pcmC1D0p
    [ 124.874777] PM: Adding info for No Bus:pcmC1D0c
    [ 124.874800] PM: Adding info for No Bus:dsp1
    [ 124.874820] PM: Adding info for No Bus:audio1
    [ 124.874846] PM: Adding info for No Bus:controlC1
    [ 124.874875] PM: Adding info for No Bus:mixer1
    [ 124.892854] ivtv0: Autodetected Hauppauge card (cx23416 based)
    [ 124.893243] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
    [ 124.893247] ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
    [ 124.893256] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
    [ 124.919298] nvidia: disagrees about version of symbol struct_module
    [ 125.514430] PM: Adding info for No Bus:0000:01:08.0
    [ 125.581285] PM: Removing info for No Bus:0000:01:08.0
    [ 125.592592] ivtv0: loaded v4l-cx2341x-enc.fw firmware (-139637039960496 bytes)
    [ 125.814350] ivtv0: Encoder revision: 0×02060039
    [ 125.814371] PM: Adding info for No Bus:i2c-2
    [ 125.814843] PM: Adding info for i2c:2-0050
    [ 125.863002] tveeprom 2-0050: Hauppauge model 26132, rev F1B2, serial# 10258732
    [ 125.863005] tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    [ 125.863009] tveeprom 2-0050: TV standards NTSC(M) (eeprom 0×08)
    [ 125.863011] tveeprom 2-0050: audio processor is CX25841 (idx 35)
    [ 125.863014] tveeprom 2-0050: decoder processor is CX25841 (idx 28)
    [ 125.863016] tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter
    [ 125.863019] ivtv0: Autodetected Hauppauge WinTV PVR-150
    [ 125.863021] ivtv0: reopen i2c bus for IR-blaster support
    [ 125.863030] PM: Removing info for i2c:2-0050
    [ 125.863040] PM: Removing info for No Bus:i2c-2
    [ 125.863063] PM: Adding info for No Bus:i2c-2
    [ 125.863453] PM: Adding info for i2c:2-0050
    [ 125.933426] tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    [ 125.933437] PM: Adding info for i2c:2-0061
    [ 126.108854] cx25840 2-0044: cx25841-24 found @ 0×88 (ivtv i2c driver #0)
    [ 126.108867] PM: Adding info for i2c:2-0044
    [ 126.122467] PM: Adding info for No Bus:2-0044
    [ 126.126518] PM: Removing info for No Bus:2-0044
    [ 129.007925] cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    [ 129.099783] wm8775 2-001b: chip found @ 0×36 (ivtv i2c driver #0)
    [ 129.106546] PM: Adding info for i2c:2-001b
    [ 129.136105] tuner 2-0061: type set to 50 (TCL 2002N)
    [ 129.441627] ivtv0: Registered device video0 for encoder MPEG (4 MB)
    [ 129.441778] ivtv0: Registered device video32 for encoder YUV (2 MB)
    [ 129.441940] ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    [ 129.442007] ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    [ 129.460301] ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    [ 129.460324] ivtv: ==================== END INIT IVTV ====================

  294. 294
    Lance Says:

    Well I solved my own problem. Turns our the IR part of the card was bad in some aspect. For whatever reason, it would work under WinXP on two different PCs, but not under Linux (Ubuntu) on either PC. Got a new PVR-150, put it in and it instantly worked.

    The new and old cards both had the same model and revision numbers as well.

  295. 295
    mark Says:

    long time, no update. Got married, that took some time ;)

    Damian: partly that (the driver cannot go into lirc because of the licensing issues), and partly that lirc is not in the kernel. The ivtv driver has not caused any issues, having it integrated into the kernel just makes it easier for distros to support the hardware, but doesn’t do anything for lirc. Shame, but there you go!
    phoner: it doesn’t learn, you must have a different card?
    Seth: looks like the wrong /dev/lircX?
    Lance: is it an MCE or something? If it can’t talk i2c it’s not going to work, I guess be sure you have the correct chip. Other than that, it could be timing. There are some timing hacks in the newer hauppauge windows drivers but I can’t figure out where the values come from.
    MEvans: I have updated the driver to current LIRC CVS, you can try this one. Apparently they have fixed the overwrite issue already. As patches go, you can get them with something like svn diff svn://svn.blushingpenguin.com/usr/local/svnroot/vendor/lirc/current svn://svn.blushingpenguin.com/usr/local/svnroot/trunk/lirc/ — however if you want a patch against the lirc distribution tarball you are a bit out of luck unless you want to generate your own — I gave up on that as they use a different version of the gnu autotools to me, and that makes larger patches than the tarball!

  296. 296
    Rusty Dog Says:

    Thanks for all of the hard work over the years. And for the update. A small typo that shouldin’t matter. During setup.sh the pvr-150 has moved from h to i

  297. 297
    mark Says:

    Thanks — now fixed.

  298. 298
    Rusty Dog Says:

    Okay, I actually have something to post about! I am sure that I am being a moron somewhere.
    Running gentoo, 2.6.22-gentoo-r5 ivtv-1.0.1
    I get a segfault when I do modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    The system did use to work with older versions so I am pretty sure the hardware is fine.
    Here is the syslog
    Aug 28 17:12:57 mythical lirc_pvr150: chip found with RX and TX
    Aug 28 17:12:57 mythical BUG: unable to handle kernel paging request at virtual address 801f831f
    Aug 28 17:12:57 mythical printing eip:
    Aug 28 17:12:57 mythical c034a5df
    Aug 28 17:12:57 mythical *pde = 00000000
    Aug 28 17:12:57 mythical Oops: 0000 [#1]
    Aug 28 17:12:57 mythical PREEMPT
    Aug 28 17:12:57 mythical Modules linked in: lirc_pvr150 lirc_dev snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq wm8775 cx25840 tuner ivtv cx2341x tveeprom i2c_viapro vt8623fb fb svgalib cfbcopyarea vgastate cfbimgblt cfbfillrect snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore
    Aug 28 17:12:57 mythical CPU: 0
    Aug 28 17:12:57 mythical EIP: 0060:[] Not tainted VLI
    Aug 28 17:12:57 mythical EFLAGS: 00010206 (2.6.22-gentoo-r5 #1)
    Aug 28 17:12:57 mythical EIP is at __i2c_check_addr+0×9/0×33
    Aug 28 17:12:57 mythical eax: 00008122 ebx: dd005852 ecx: 801f831f edx: 00000071
    Aug 28 17:12:57 mythical esi: dd005852 edi: fffffff0 ebp: dddba400 esp: d9be1d48
    Aug 28 17:12:57 mythical ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
    Aug 28 17:12:57 mythical Process modprobe (pid: 14350, ti=d9be0000 task=dcd97530 task.ti=d9be0000)
    Aug 28 17:12:57 mythical Stack: dddba474 c034a656 d9be1dd3 71fe2600 d9be1da8 00000000 00000246 00000001
    Aug 28 17:12:57 mythical dddba474 dddba474 dddba400 e2c0e416 dddba474 e2c0f22e dddba48f e2c0e60c
    Aug 28 17:12:57 mythical e2c0f1f6 e2c0f1dc d9be1da8 00000001 00000001 dd3becd8 00000000 00000000
    Aug 28 17:12:57 mythical Call Trace:
    Aug 28 17:12:57 mythical [] i2c_attach_client+0×24/0x15f
    Aug 28 17:12:57 mythical [] i2c_attach+0×12/0×42 [lirc_pvr150]
    Aug 28 17:12:57 mythical [] ir_attach+0x1c6/0×309 [lirc_pvr150]
    Aug 28 17:12:57 mythical [] ir_probe+0×109/0x12e [lirc_pvr150]
    Aug 28 17:12:57 mythical [] i2c_register_driver+0xad/0xce
    Aug 28 17:12:57 mythical [] init_module+0×46/0x4a [lirc_pvr150]
    Aug 28 17:12:57 mythical [] sys_init_module+0×89/0×133
    Aug 28 17:12:57 mythical [] syscall_call+0×7/0xb
    Aug 28 17:12:57 mythical =======================
    Aug 28 17:12:57 mythical Code: b8 b0 1c 4a c0 c7 85 bc 00 00 00 00 01 10 00 c7 41 04 00 02 20 00 83 c4 1c 5b 5e 5f 5d e9 d1 8d 07 00 53 8b 88 94 01 00 00 89 c3 01 0f 18 00 90 8d 83 94 01 00 00 39 c1 74 16 0f b7 81 76 fe
    Aug 28 17:12:57 mythical EIP: [] __i2c_check_addr+0×9/0×33 SS:ESP 0068:d9be1d48

    Any suggestion about what I am doing wrong?

    Thanks
    Rusty

  299. 299
    mark Says:

    I guess it’s probably the struct IR name length reduction — my names are one byte too long. I have fixed it up and uploaded a new tarball, can you try it and let me know if it helps? If not I will install 2.6.22 on my mythtv box and try to reproduce it.

  300. 300
    Damian Says:

    I see from https://help.ubuntu.com/community/Install_Lirc_Gutsy that they have support for blaster in Lirc. Is this using your patched lirc or what is the difference?

    PS. Congrats (I think!!) on get married!

  301. 301
    mark Says:

    I guess it is my code, the page links to the firmware, etc. on this site. I don’t know what changes have been made to it from the code I provide. I guess just try it — if it works, fine — it’s usually easier to use your distribution’s package.

    Thanks!

    Mark

  302. 302
    Rusty Dog Says:

    Got a slightly different error, the virtual address is zeroes. Here are the first few lines. Let me know if I can help

    Aug 29 05:24:32 mythical lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    Aug 29 05:24:32 mythical lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    Aug 29 05:24:32 mythical lirc_pvr150: chip found with RX and TX
    Aug 29 05:24:32 mythical BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
    Aug 29 05:24:32 mythical printing eip:
    Aug 29 05:24:32 mythical c03c33d4
    Aug 29 05:24:32 mythical *pde = 00000000
    Aug 29 05:24:32 mythical Oops: 0002 [#1]
    Aug 29 05:24:32 mythical PREEMPT

  303. 303
    mark Says:

    Did you get a backtrace this time? I guess you could try inserting printk’s every so often to figure out what line is causing it to fall over.

    In the meantime I have tried the code against 2.6.22-5 (stock kernel.org) and it is working for me.

  304. 304
    Rusty Dog Says:

    Sure, I have the trace, just didn’t want to clutter up your page.
    Aug 29 05:24:32 mythical lirc_dev: IR Remote Control driver registered, at major 61
    Aug 29 05:24:32 mythical lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    Aug 29 05:24:32 mythical lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    Aug 29 05:24:32 mythical lirc_pvr150: chip found with RX and TX
    Aug 29 05:24:32 mythical BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
    Aug 29 05:24:32 mythical printing eip:
    Aug 29 05:24:32 mythical c03c33d4
    Aug 29 05:24:32 mythical *pde = 00000000
    Aug 29 05:24:32 mythical Oops: 0002 [#1]
    Aug 29 05:24:32 mythical PREEMPT
    Aug 29 05:24:32 mythical Modules linked in: lirc_pvr150 lirc_dev snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq wm8775 cx25840 tuner ivtv cx2341x tveeprom snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore i2c_viapro vt8623fb fb svgalib cfbcopyarea vgastate cfbimgblt cfbfillrect
    Aug 29 05:24:32 mythical CPU: 0
    Aug 29 05:24:32 mythical EIP: 0060:[] Not tainted VLI
    Aug 29 05:24:32 mythical EFLAGS: 00010202 (2.6.22-gentoo-r5 #1)
    Aug 29 05:24:32 mythical EIP is at __mutex_lock_slowpath+0×23/0×98
    Aug 29 05:24:32 mythical eax: dd005882 ebx: dd00587e ecx: 00000000 edx: 00000000
    Aug 29 05:24:32 mythical esi: d0c11590 edi: fffffff0 ebp: dd52a800 esp: d1077d30
    Aug 29 05:24:32 mythical ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
    Aug 29 05:24:32 mythical Process modprobe (pid: 10580, ti=d1076000 task=d0c11590 task.ti=d1076000)
    Aug 29 05:24:32 mythical Stack: dd005882 dd2cecd8 00000035 c0115935 dd52a874 dd005852 c03c33a6 c034a64a
    Aug 29 05:24:32 mythical d1077dd3 71fe2600 d1077da8 00000000 00000246 00000001 dd52a874 dd52a874
    Aug 29 05:24:32 mythical dd52a800 e3b93416 dd52a874 e3b9422e dd52a88f e3b9360c e3b941f6 e3b941dc
    Aug 29 05:24:32 mythical Call Trace:
    Aug 29 05:24:32 mythical [] vprintk+0x23e/0×248
    Aug 29 05:24:32 mythical [] mutex_lock+0×9/0xa
    Aug 29 05:24:32 mythical [] i2c_attach_client+0×18/0x15f
    Aug 29 05:24:32 mythical [] i2c_attach+0×12/0×42 [lirc_pvr150]
    Aug 29 05:24:32 mythical [] ir_attach+0x1c6/0×309 [lirc_pvr150]
    Aug 29 05:24:32 mythical [] ir_probe+0×109/0x12e [lirc_pvr150]
    Aug 29 05:24:32 mythical [] i2c_register_driver+0xad/0xce
    Aug 29 05:24:32 mythical [] init_module+0×46/0x4a [lirc_pvr150]
    Aug 29 05:24:32 mythical [] sys_init_module+0×89/0×133
    Aug 29 05:24:32 mythical [] syscall_call+0×7/0xb
    Aug 29 05:24:32 mythical =======================
    Aug 29 05:24:32 mythical Code: 7f 05 e8 99 00 00 00 c3 56 53 83 ec 10 89 c3 89 e0 25 00 e0 ff ff 8b 35 00 00 48 c0 ff 40 14 8d 43 04 8b 50 04 89 04 24 89 60 04 22 89 54 24 04 89 74 24 08 83 c8 ff 87 03 48 74 2d c7 06 02
    Aug 29 05:24:32 mythical EIP: [] __mutex_lock_slowpath+0×23/0×98 SS:ESP 0068:d1077d30
    Aug 29 05:24:32 mythical note: modprobe[10580] exited with preempt_count 1
    Aug 29 05:24:32 mythical BUG: scheduling while atomic: modprobe/0×10000001/10580
    Aug 29 05:24:32 mythical [] __sched_text_start+0×56/0×556
    Aug 29 05:24:32 mythical [] unmap_page_range+0xb2/0×100
    Aug 29 05:24:32 mythical [] min_pages_to_free+0xd/0x1c
    Aug 29 05:24:32 mythical [] __cond_resched+0×16/0×34
    Aug 29 05:24:32 mythical [] cond_resched+0×26/0×31
    Aug 29 05:24:32 mythical [] unmap_vmas+0x14b/0x1a5
    Aug 29 05:24:32 mythical [] exit_mmap+0×66/0xe6
    Aug 29 05:24:32 mythical [] mmput+0x1f/0x7c
    Aug 29 05:24:32 mythical [] do_exit+0x1c6/0x38b
    Aug 29 05:24:32 mythical [] die+0x1c0/0x1c8
    Aug 29 05:24:32 mythical [] do_page_fault+0x45f/0×539
    Aug 29 05:24:32 mythical [] do_page_fault+0×0/0×539
    Aug 29 05:24:32 mythical [] error_code+0x6a/0×70
    Aug 29 05:24:32 mythical [] __mutex_lock_slowpath+0×23/0×98
    Aug 29 05:24:32 mythical [] vprintk+0x23e/0×248
    Aug 29 05:24:32 mythical [] mutex_lock+0×9/0xa
    Aug 29 05:24:32 mythical [] i2c_attach_client+0×18/0x15f
    Aug 29 05:24:32 mythical [] i2c_attach+0×12/0×42 [lirc_pvr150]
    Aug 29 05:24:32 mythical [] ir_attach+0x1c6/0×309 [lirc_pvr150]
    Aug 29 05:24:32 mythical [] ir_probe+0×109/0x12e [lirc_pvr150]
    Aug 29 05:24:32 mythical [] i2c_register_driver+0xad/0xce
    Aug 29 05:24:32 mythical [] init_module+0×46/0x4a [lirc_pvr150]
    Aug 29 05:24:32 mythical [] sys_init_module+0×89/0×133
    Aug 29 05:24:32 mythical [] syscall_call+0×7/0xb
    Aug 29 05:24:32 mythical =======================

  305. 305
    mark Says:

    I guess sticking printk’s in various strategic places would help narrow it down a bit. It definitely shouldn’t be the i2c name length change causes overwriting structure issue any more (I changed it to use strlcpy, so it should truncate at worst), therefore something else is going on. Do gentoo just use stock kernels or they patched? Also, I can have a poke via SSH if you are happy with that and don’t mind the box being reboot copiously at some point (let me know if you want that and I will send you my ssh key). Can’t think of anything else OTOMH, this is the first time I’ve seen a crash bug for years so I suspect it’s due to some kernel interface change.

  306. 306
    Rusty Dog Says:

    The gentoo kernel that I am using is patched. I can give you access, but will have to spend some time changing a few permissions and stuff on the box first.

  307. 307
    mark Says:

    Just for reference, this is resolved. The old code was being used by mistake, so it looks like things are all good with 2.6.22 now. Plus now my mythtv box is finally running something newer than 2.6.15, which will make it easier to test against future kernels.

    Next job is to find some kind of paging extension for the comments, this is _way_ too long now.

  308. 308
    alex Says:

    First: thanks so much Mark. I’m so close to send beer money! If only it worked…

    I have a mediasat max top box (france, canalsat), and none of the code sets will work (either Windows or Linux). I tried also my old mediasat box… no luck.

    I was hoping someone else had succeeded before with a mediasat box, before I start to bug Hauppauge support…

    Thanks, alex.

  309. 309
    mark Says:

    There is a new codeset dump from hauppauge, I will try and sort it out early next week. Unfortunately I don’t know if this includes a code that will control your box. At the moment, I cannot get to the Windows box I use for codeset dumps — it is in storage because the house is being decorated at the moment.

  310. 310
    Michael Evans Says:

    lircd: error in configfile line 291:
    lircd: “2150039562″: must be a valid (lirc_t) number
    lircd: reading of config file failed

    I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)

    logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x = n 8027000a => 8027000a =

  311. 311
    Michael Evans Says:

    lircd: error in configfile line 291:
    lircd: “2150039562″: must be a valid (lirc_t) number
    lircd: reading of config file failed

    I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)

    logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x == %lx”,line,val,n,h,((unsigned long) h));

    lircd: DBG s_strtolirc_t: 291: 2150039562 => n 8027000a => 8027000a == ffffffff8027000a

    The problem is that when a signed int is cast to a larger unit, the sign bit is extended.

    (Note, each line should start with a space, and the indentation should be one or two tabs instead of spaces… I copied right off my console and tabs probably won’t post correctly here anyway.)
    — daemons/config_file.c.old 2007-08-31 21:43:48.120382951 -0700
    +++ daemons/config_file.c 2007-08-31 21:59:38.503700384 -0700
    @@ -200,7 +200,7 @@ lirc_t s_strtolirc_t(char *val)

    n=strtoul(val,&endptr,0);
    h=(lirc_t) n;
    - if(!*val || *endptr || n!=((unsigned long) h))
    + if(!*val || *endptr)
    {
    logprintf(LOG_ERR,”error in configfile line %d:”,line);
    logprintf(LOG_ERR,”\”%s\”: must be a valid (lirc_t) “

  312. 312
    Daveg Says:

    Hi Guys,

    The patch that the guy gave at the end with the diff file fixed the problem.

  313. 313
    mark Says:

    Thanks for the patch, I have uploaded a revised tarball.

  314. 314
    Bone Says:

    Did anyone get the ir blaster to work with a motorola vip1200. I saw someone post about it awhile back. It does work in windows using AT&T code 130 or 0130, cant remember which. I think I just need to wait until the firmware gets updated.

    Thanks again Mark I have been using this for a year or two and am now adding an additional stb to the mix.

  315. 315
    Bo Says:

    Hi Mark

    I get much the same behaviour as Xavier reported in entry 20. Codesets 384, 661 and 666 work partially with my satbox (Triax 40S): sometimes the satbox accepts the code sent, sometimes not.

    However, using the Hauppauge Windows program for setting up the blaster, all three codesets work perfectly.

    Mark, is there any parameter (e.g. in lircd.conf) that I could try tweaking to get the same ir signal sent, as with the Windows program?

    Xavier, how did you solve this problem? The idea of appending a vol_up command or similar does not work with my satbox.

    Best regards,
    Bo

  316. 316
    Bo Says:

    Correction: I was referring to Xavier\’s entry no 17.

  317. 317
    Eric Barnett Says:

    HELP!!! I just re-re-re-installed Mythdora and after following the very awesome config that you have here plus the one on http://charles.hopto.org/blog/?p=24 I’m getting a hardware does not support sending error when I try to use the irsend SEND_ONCE blaster POWER command to test. I’m a very frustrated newb right now. I’ve tried two separate versions of myth and I ACTUALLY had this thing working on a previous install. I’m looking at over 60 hours of toiling on trying to get a box up and running and of course, this is the last #*$@ thing that I need to make this work. I tried looking at the syslog after doing the commands to test, but it didn’t put anything in the log or I’m looking at the wrong one. HELP!!!

  318. 318
    Ben Says:

    Hey Mark, Great job works perfect for me with a SA 1840 with codeset 41.

    Quick question, I also have an ATI usb Remote wonder that previous worked with the lirc_atiusb module but now I can’t seem to load it. Short of compiling a 2nd instance of lirc is there a way to include it when building this package? I know on other distros i’ve seen the option to include more than one module when building lirc but I can’t seem to find it here.

    thanks again,
    Ben

  319. 319
    Paul Says:

    I don\\\’t know if this process is correct for my 2setup. I have a PVR150 with a USB IR Receiver.. I want to set up a serial IR blaster to change channel2s on my sat bo/x.. if I run this LIRC compile etc.. will it work for me?

  320. 320
    Akriss Says:

    Mark… Thanks a bunch.

    I was haveing a nightmare geting my 150 blaster to work in Ubuntu 7.10 Gusty. found this little slice of heaven and no more nightmares.

    Thanks

  321. 321
    Andrew Says:

    Mark,

    I was able to get lirc_pvr150 working without a hitch in ubuntu feisty but when I upgrade to gutsy I run into some problems (kernel 2.6.22).

    The code compiles fine but then it segfaults when I go to load the module.

    dmesg reports:
    [ 81.548000] lirc_dev: IR Remote Control driver registered, at major 61
    [ 81.592000] lirc_pvr150: chip found with RX and TX
    [ 81.592000] BUG: unable to handle kernel paging request at virtual address 52540013
    [ 81.592000] printing eip:
    [ 81.592000] c02f31bb
    [ 81.592000] *pde = 00000000
    [ 81.592000] Oops: 0002 [#1]
    [ 81.592000] SMP
    [ 81.592000] Modules linked in: lirc_pvr150 lirc_dev binfmt_misc rfcomm l2cap bluetooth ppdev ipv6 powernow_k8 cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand freq_table container button sbs dock ac video battery af_packet nvram nxt200x saa7134_alsa saa7134_dvb dvb_pll saa7134 compat_ioctl32 ir_kbd_i2c ir_common video_buf_dvb dvb_core video_buf tda1004x sbp2 lp wm8775 cx25840 tuner snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ivtv snd i2c_algo_bit soundcore cx2341x tveeprom videodev v4l2_common snd_page_alloc i2c_nforce2 parport_pc parport serio_raw v4l1_compat nvidia(P) k8temp psmouse pcspkr agpgart i2c_core evdev ext3 jbd mbcache sg sd_mod usb_storage libusual ide_cd cdrom sata_nv ata_generic amd74xx ide_core ehci_hcd ohci1394 ieee1394 libata scsi_mod forcedeth ohci_hcd usbcore dm_mirror dm_snapshot dm_mod thermal processor fan fuse apparmor commoncap
    [ 81.592000] CPU: 1
    [ 81.592000] EIP: 0060:[] Tainted: P VLI
    [ 81.592000] EFLAGS: 00010206 (2.6.22-14-generic #1)
    [ 81.592000] EIP is at __mutex_lock_slowpath+0x2b/0×90
    [ 81.592000] eax: ffffffff ebx: f6005882 ecx: 00000000 edx: 52540013
    [ 81.592000] esi: f6005886 edi: ebf86000 ebp: f600588a esp: e6557c20
    [ 81.592000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
    [ 81.592000] Process modprobe (pid: 6871, ti=e6556000 task=ebf86000 task.ti=e6556000)
    [ 81.592000] Stack: f600588a 23493400 00000246 f6005882 e8c25878 f6005852 fffffff0 c02f3084
    [ 81.592000] e6557e7c f8997f79 f604ed78 f604ed58 00000001 f8997237 e6557c70 f604ed58
    [ 81.592000] f6005882 e6557e7c e8c25878 e8c25800 e8c25800 f8e3a67d e6557e7c f8e3c840
    [ 81.592000] Call Trace:
    [ 81.592000] [] mutex_lock+0×14/0×20
    [ 81.592000] [] i2c_attach_client+0×29/0×190 [i2c_core]
    [ 81.592000] [] i2c_transfer+0×47/0×60 [i2c_core]
    [ 81.592000] [] i2c_attach+0x1d/0×60 [lirc_pvr150]
    [ 81.592000] [] ir_probe+0x4d3/0×910 [lirc_pvr150]
    [ 81.592000] [] i2c_register_driver+0xd5/0×120 [i2c_core]
    [ 81.592000] [] init_module+0×48/0×50 [lirc_pvr150]
    [ 81.592000] [] sys_init_module+0×151/0x1a00
    [ 81.592000] [] prio_tree_insert+0x1f/0×250
    [ 81.592000] [] sysenter_past_esp+0x6b/0xa9
    [ 81.592000] =======================
    [ 81.592000] Code: 55 57 56 53 89 c3 8d 70 04 83 ec 0c 89 f0 64 8b 3d 00 90 43 c0 e8 a6 0c 00 00 8d 6b 08 b8 ff ff ff ff 8b 55 04 89 2c 24 89 65 04 22 89 54 24 04 89 7c 24 08 87 03 83 e8 01 74 2a 8d 74 26 00
    [ 81.592000] EIP: [] __mutex_lock_slowpath+0x2b/0×90 SS:ESP 0068:e6557c20

    Do you think its a problem with my configuration, or something with the code itself?

    Thanks in advance,

  322. 322
    Raj Says:

    I followed the doc above and able to turn on my set top box. Now I am also lost at the step 11 how to use this change_channel script in the mythtv and what is the rename the number keys?

    I have not modified the script other than changing it name to change_channel.pl script.

    Below is the error that I get.

    [mythtv@localhost bin]$ change_channel.pl 220
    channel changing 220
    irsend: command failed: SEND_ONCE blaster 2
    irsend: unknown command: “2″

    Please let me know what should I do to fix it.

    Thanks,
    Raj

  323. 323
    chris Says:

    irsend is throwing the error…
    irsend: hardware does not support sending

    I’m running:

    gentoo-2.6.22-r9
    ivtv-1.0.3-r1
    lirc-0.8.3_pre1

    I have the firmware haup-ir-blaster.bin in /lib/firmware but I don’t think it’s loading

    Nov 26 05:29:17 mythtv ivtv: ==================== START INIT IVTV ====================
    Nov 26 05:29:17 mythtv ivtv: version 1.0.0 (2.6.22-gentoo-r9 mod_unload PENTIUM4 ) loading
    Nov 26 05:29:17 mythtv ivtv0: Autodetected Hauppauge card (cx23416 based)
    Nov 26 05:29:17 mythtv ACPI: PCI Interrupt 0000:02:0e.0[A] -> GSI 17 (level, low) -> IRQ 18
    Nov 26 05:29:18 mythtv ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
    Nov 26 05:29:18 mythtv ivtv0: Encoder revision: 0×02060039
    Nov 26 05:29:18 mythtv tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    Nov 26 05:29:18 mythtv cx25840 0-0044: cx25843-24 found @ 0×88 (ivtv i2c driver #0)
    Nov 26 05:29:22 mythtv cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    Nov 26 05:29:22 mythtv wm8775 0-001b: chip found @ 0×36 (ivtv i2c driver #0)
    Nov 26 05:29:22 mythtv lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
    Nov 26 05:29:22 mythtv lirc_dev: lirc_register_plugin: sample_rate: 10
    Nov 26 05:29:22 mythtv tveeprom 0-0050: Hauppauge model 26152, rev E5B2, serial# 10296113
    Nov 26 05:29:22 mythtv tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    Nov 26 05:29:22 mythtv tveeprom 0-0050: TV standards NTSC(M) (eeprom 0×08)
    Nov 26 05:29:22 mythtv tveeprom 0-0050: audio processor is CX25843 (idx 37)
    Nov 26 05:29:22 mythtv tveeprom 0-0050: decoder processor is CX25843 (idx 30)
    Nov 26 05:29:22 mythtv tveeprom 0-0050: has no radio, has IR receiver, has IR transmitter
    Nov 26 05:29:22 mythtv ivtv0: Autodetected Hauppauge WinTV PVR-150
    Nov 26 05:29:22 mythtv ivtv0: reopen i2c bus for IR-blaster support
    Nov 26 05:29:22 mythtv tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    Nov 26 05:29:22 mythtv cx25840 0-0044: cx25843-24 found @ 0×88 (ivtv i2c driver #0)
    Nov 26 05:29:26 mythtv cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    Nov 26 05:29:26 mythtv wm8775 0-001b: chip found @ 0×36 (ivtv i2c driver #0)
    Nov 26 05:29:26 mythtv lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
    Nov 26 05:29:26 mythtv lirc_dev: lirc_register_plugin: sample_rate: 10
    Nov 26 05:29:26 mythtv tuner 0-0061: type set to 50 (TCL 2002N)
    Nov 26 05:29:26 mythtv ivtv0: Registered device video0 for encoder MPEG (4 MB)
    Nov 26 05:29:26 mythtv ivtv0: Registered device video32 for encoder YUV (2 MB)
    Nov 26 05:29:26 mythtv ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    Nov 26 05:29:26 mythtv ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    Nov 26 05:29:26 mythtv ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    Nov 26 05:29:26 mythtv ivtv: ==================== END INIT IVTV ====================
    Nov 26 05:29:26 mythtv kobject_add failed for i2c ir driver with -EEXIST, don’t try to register things with the same name in the same directory.
    Nov 26 05:29:26 mythtv [] kobject_shadow_add+0×141/0×173
    Nov 26 05:29:26 mythtv [] kobject_register+0×19/0×30
    Nov 26 05:29:26 mythtv [] bus_add_driver+0×50/0x16d
    Nov 26 05:29:26 mythtv [] i2c_register_driver+0×58/0xcb [i2c_core]
    Nov 26 05:29:26 mythtv [] init_module+0×48/0x4c [lirc_pvr150]
    Nov 26 05:29:26 mythtv [] sys_init_module+0x11f1/0×1327
    Nov 26 05:29:26 mythtv [] lirc_register_plugin+0×0/0x41d [lirc_dev]
    Nov 26 05:29:26 mythtv [] do_sync_read+0×0/0×109
    Nov 26 05:29:26 mythtv [] sysenter_past_esp+0x5f/0×85
    Nov 26 05:29:26 mythtv [] ipt_register_table+0×25/0xa4
    Nov 26 05:29:26 mythtv =======================

    Any help would be greatly appreciated.

  324. 324
    Michael Evans Says:

    I was planning to wait for 2.6.24 to upgrade the kernel on my mythtv system again… but a storm caused a nice 30 min power failure and that was more then the UPS could handle… so I reboot in to 2.6.23… and find that I can get ivtv to compile but not lirc…

    I have tried looking in to this, but Makefiles are things I don’t even have a clue where to begin with. From the source lines, it looks like either kernel-functions or the macros for the major/minor numbers aren’t being filled in.

    make all-recursive
    make[1]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150′
    Making all in drivers
    make[2]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers’
    Making all in lirc_dev
    make[3]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
    Makefile:8: **************************************************
    Makefile:8: *** Makefile trick not undone, trying to recover *
    Makefile:8: **************************************************
    mv Makefile.automake Makefile
    make all
    make[4]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
    mv Makefile Makefile.automake
    cp ../Makefile.kernel Makefile
    make -C /lib/modules/2.6.23-gentoo-r3/build/ SUBDIRS=/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev modules \
    KBUILD_VERBOSE=1
    make[5]: Entering directory `/usr/src/linux-2.6.23-gentoo-r3′
    test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
    echo; \
    echo ” ERROR: Kernel configuration is invalid.”; \
    echo ” include/linux/autoconf.h or include/config/auto.conf are missing.”; \
    echo ” Run ‘make oldconfig && make prepare’ on kernel src to fix it.”; \
    echo; \
    /bin/false)
    mkdir -p /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.tmp_versions
    rm -f /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.tmp_versions/*
    make -f scripts/Makefile.build obj=/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev
    gcc -Wp,-MD,/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.lirc_dev.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DIRCTL_DEV_MAJOR=61 -DEXPORT_SYMTAB -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/../.. -I/lib/modules/2.6.23-gentoo-r3/build//include/ -I/lib/modules/2.6.23-gentoo-r3/build//drivers/media/video/ -DMODULE -D”KBUILD_STR(s)=#s” -D”KBUILD_BASENAME=KBUILD_STR(lirc_dev)” -D”KBUILD_MODNAME=KBUILD_STR(lirc_dev)” -c -o /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.tmp_lirc_dev.o /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c
    /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘lirc_dev_init’:
    /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:883: error: void value not ignored as it ought to be
    /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘cleanup_module’:
    /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:910: error: void value not ignored as it ought to be
    make[6]: *** [/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.o] Error 1
    make[5]: *** [_module_/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev] Error 2
    make[5]: Leaving directory `/usr/src/linux-2.6.23-gentoo-r3′
    make[4]: *** [lirc_dev.o] Error 2
    make[4]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
    make[3]: *** [all] Error 2
    make[3]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers’
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150′
    make: *** [all] Error 2

  325. 325
    Pascal Says:

    Hi Mark,

    Many, Many thanks for your GREAT work ! I’m really near to use my IR blaster now :-)

    I encounter two troubles :
    At the time of make, on my system (Kernel 2.6.23.1, I suspect that the reason of the trouble is somewhere here), I run in this trouble :
    /home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘lirc_dev_init’:
    /home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:883: erreur: valeur void n’a pas été ignorée comme elle aurait dû l’être
    /home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘cleanup_module’:
    /home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:910: erreur: valeur void n’a pas été ignorée comme elle aurait dû l’être

    Sorry, my system is in french, but in English, the error message should be “void value not ignored as it ought to be”

    I’m a C newbee, but Google told me that this has to do to a call to a function, waiting a return, but the function don’t want to give something back.

    So I did this (crude) hack :
    ———————————————————————
    diff -u drivers/lirc_dev/lirc_dev.c ../../lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c
    — drivers/lirc_dev/lirc_dev.c 2007-03-18 10:05:10.000000000 +0100
    +++ ../../lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c 2007-12-02 19:03:35.000000000 +0100
    @@ -880,8 +880,9 @@
    return SUCCESS;

    out_unregister:
    - if(unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME))
    - printk(KERN_ERR “lirc_dev: unregister_chrdev failed!\n”);
    + unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
    + /* if(unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME))
    + printk(KERN_ERR “lirc_dev: unregister_chrdev failed!\n”); */
    out:
    return -1;
    }
    @@ -907,7 +908,7 @@
    {
    int ret;

    - ret = unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
    + unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
    class_destroy(lirc_class);

    if(ret)
    —————————————————————————

    With this hack, the driver compiles and seems to be OK, as I can see the led blinking when I start send_power_new.

    And now, I cone to my second trouble :
    It seems that send_power_new to my ADSL TV Box (it’a a freebox, free is one of the three big ISP in France), I cannot wake up my box.
    Switching to Windows XP, and using the latest irblaster soft, I can drive (not totally, but fairly good) my freebox by selecting the 706 model.

    I think I read that in this case, you could eventually do something for us (read : me ;-) ). as I said, I have also a Windows XP part on this system, if you need some other informations.

    Thanks again,
    Pascal

  326. 326
    Pascal Says:

    Hi Mark and all,

    Forget the second part of my preceding message :

    The keycode for a ’706′ type remote are presents in the lircd.conf file, and are working with my freebox (For the record, if someone else does research about freebox, I’m owning a Freebox V4).

    But now, I encounter another trouble :

    On this box, to select a channel number with more than one digit, (saying channel 12), I have to depress continuously the key 1 around
    1 or 2 second, until the cursor on the screen move right, and then, I have to depress the key 2.

    I didn’t find the trick to mimic this behaviour with irsend (nor was I able to do that on Windows).

    Here is what I tried :

    irsend SEND_START blaster 1_706_KEY_1 ; sleep 2 ; irsend SEND_STOP blaster 1_706_KEY_1 ; irsend SEND_ONCE blaster 1_706_KEY_2

    and

    for i in 1 2 3 4 5 ; do irsend SEND_ONCE blaster 1_706_KEY_1; done ; irsend SEND_ONCE blaster 1_706_KEY_2

    But in the two cases, it seems that the data flow simply stop to long and my box understand that as many shorts depress of the 1 key, f
    ollowed by one press on the 2 key.

    Any ideas on how to change that (if this is possible) ?

    Thanks,
    Pascal

  327. 327
    Pascal Says:

    Hi Mark and all,

    Forget my preceding message :-)

    I found a solution :

    The gap (time between two action is long by default in the configuration file : gap = 333333 (I don’t know what kind of time this is ???)

    I changed the gap to 5000, and now I can change to the channel 199 like that :

    irsend –count=5 SEND_ONCE blaster 1_706_KEY_1 ; sleep 1 ; irsend –count=5 SEND_ONCE blaster 1_706_KEY_9; sleep 1 ; irsend SEND_ONCE blaster 1_706_KEY_9

    So, for now, everything is OK :-D

    Thanks,
    Pascal

  328. 328
    PB Says:

    I’m having difficulty compiling the patch.

    I’m using Linux 2.6.23.9-85.fc8 i686 athlon i386 GNU/Linux

    I ./setup.sh and choose ‘i’ from the tv card menu. then save and configure.
    that seems to go well, but when I make:

    /usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function âlirc_dev_initâ:
    /usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:883: error: void value not ignored as it ought to be
    /usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function âcleanup_moduleâ:
    /usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:910: error: void value not ignored as it ought to be
    make[5]: *** [/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.o] Error 1
    make[4]: *** [_module_/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev] Error 2
    make[4]: Leaving directory `/usr/src/kernels/2.6.23.9-85.fc8-i686′
    make[3]: *** [lirc_dev.o] Error 2
    make[3]: Leaving directory `/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/usr/src/lirc-0.8.3-CVS-pvr150/drivers’
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/usr/src/lirc-0.8.3-CVS-pvr150′
    make: *** [all] Error 2

    I’ve made sure that i have gcc and devel libs and anything else I could dig up on the net, but I can’t get past this point.

    Thank for you help, and thanks for making this patch.

    PB

  329. 329
    Mike Says:

    I have been having difficulty getting this to work on 2.6.23, but it might just be my incompetence in prepping the kernel sources. Has anyone else been able to make this work?

  330. 330
    mark Says:

    Mike, PB, anyone else: I have updated the driver to compile with 2.6.24/2.6.23, and tested it on a 2.6.23.12 kernel.org release. Please let me know if you still have trouble, (poke me via email if I don’t respond).
    Pascal: glad you fixed yourself up, the gap is in microseconds and is just a standard lirc parameter. It is tuned for my STB I believe ;)

  331. 331
    gbr Says:

    Mythbuntu seems to come with your patched software. However, when I modprobe lirc_pvr150, it freezes and I never get the command prompt back.

    syslog:Jan 23 13:58:45 mythslave lircd-0.8.2[5247]: lircd(userspace) ready
    syslog:Jan 23 14:02:36 mythslave kernel: [ 287.538038] lirc_dev: IR Remote Control driver registered, at major 61
    syslog:Jan 23 14:02:36 mythslave kernel: [ 287.590861] lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    syslog:Jan 23 14:02:36 mythslave kernel: [ 287.591350] lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    syslog:Jan 23 14:02:36 mythslave kernel: [ 287.591353] lirc_pvr150: chip found with RX and TX

    Any ideas?

  332. 332
    mark Says:

    Please uninstall the packaged software and use the version above. If you still have trouble, then get back to me. (Alternatively, you could ask the package maintainer).

  333. 333
    Jeff Says:

    I’m trying to install this in mythbuntu, since following their instructions to get the pvr-150 blaster working didn’t work but everytime I try ./setup.sh and select "Save configuration &amp; run configure" it runs through a big list of checks and then exits on "configure: error: *** you need to have the Linux kernel source installed for this driver" but I tried installing the linux source from synaptic and that still didn’t remedy the problem. Any Ideas?

    Oh, and when I tried to get the blaster working the mythbuntu way i’d run "irsend SEND_ONCE POWEROFF command and it’d tell me that my hardware didn’t support transmitting or something like that… now it’s telling me ‘could not connect to socket’ ‘Connection refused’

    gah! and on top of that I’m supposed to be working :/ Any help is very much appreciated!

  334. 334
    mark Says:

    > “configure: error: *** you need to have the Linux kernel source installed for this driver” but I tried
    > installing the linux source from synaptic and that still didn’t remedy the problem. Any Ideas?
    If that’s ubuntu derived, then you need to install the linux-headers package that matches your kernel flavour,
    e.g. linux-headers-generic to build out of tree modules.

  335. 335
    Jeff Says:

    Okay, I got that sorted out, thank you very much for responding. but now I’m back to square 1 with irsend reporting ‘hardware does not support sending’

    I’m a total linux idiot, so bare with me, but I think it has something to do with the lirc_pvr150 module. after running #modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1 I ran #dmesg | grep lirc and got the following

    [ 91.598330] lirc_dev: IR Remote Control driver registered, major 61
    [ 92.055473] lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
    [ 92.056018] lirc_dev: lirc_register_plugin: sample_rate: 10
    [ 187.794746] lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    [ 187.858473] [] init_module+0×48/0×50 [lirc_pvr150]

    *as a side note, your CAPTCHA is very hard to decipher most times (has taken me > 2 tries each time now) you might look at reCaptcha or a honeypot style anti-spam method if you would like help setting either of those up, I’d be happy to help

  336. 336
    mark Says:

    > but now I’m back to square 1 with irsend reporting
    > ‘hardware does not support sending’

    > [ 91.598330] lirc_dev: IR Remote Control driver registered, major 61
    > [ 92.055473] lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)

    You’ve loaded the wrong driver. Uninstall the distribution package.

    > as a side note, your CAPTCHA is very hard to decipher most times
    > (has taken me > 2 tries each time now) you might look at reCaptcha
    > or a honeypot style anti-spam method if you would like help setting
    > either of those up, I’d be happy to help

    Thanks for the offer, but just send me mail if it bugs you ;)

  337. 337
    Chris Says:

    Hi Mark, thanks for your work on this, I used it to get my pvr_150 going on MythBuntu, worked great until I got to the blaster portion, I also get the invalid remote “blaster” when running your test script, I have come to the conclusion that it is because there is no “blaster” remote listed in the conf file.. now this may have been answered before but I cannot find it if it has… I have looked all over the net for the config file which lists the blaster remote with all the codesets in the file. I found one rather old and it does not have my codeset in it.. the DirecTV R10 which is 112 and 125. Do you have the latest file and does it contain the R10 codeset(s) in it? Thanks in advance..

    Chris..

  338. 338
    mark Says:

    It’s linked above in step 8, and has both 112/125 codesets in it.

  339. 339
    Chris Says:

    Thanks Mark, I knew it had to be a oversite on my end.. Question, has anyone ever gotten this to work with the DirecTV R10 box, if so whats the secret?

  340. 340
    mark Says:

    I can’t help without more information. Are you saying that none of the 0_112, 1_112, 0_125 or 1_125 codesets work with your box?

  341. 341
    truekaiser Says:

    not asking for a newer firmware.
    I want to know what is the date of the driver you pulled the above firmware from?

  342. 342
    Jeff Says:

    I had this working wonderfully with my direcTV box, but now I\\\\\\\\\\\\\\\’ve just switched to digital cable and have a Scientific Atlanta Explorer 3100 that doesn\\\\\\\\\\\\\\\’t seem to respond to any of the codes provided (0_78 is the codeset for this box, but i\\\\\\\\\\\\\\\’ve also run send_power_new). Do you suppose this is a \\\\\\\\\\\\\\\’firmware\\\\\\\\\\\\\\\’ problem, or a setup problem? I also tried to get this working with standard LIRC and a serial IR blaster that I managed to get my hands on and it\\\\\\\\\\\\\\\’s the same thing, the light flashes, the right codes are configured, but nothing happens with my box…

  343. 343
    Dan Says:

    Sorry if this is a double comment – my last one didn’t seem to go through.

    Firstly, thanks for the effort you’ve put in to this. I’ve got the remote side working (irw works), but have yet to have success with the blaster or irsend commands. Doing a single irsend command tells me that my device doesn’t support it.

    I’ve put the .bin in my /lib/firmware// dir, successfully installed your version of lirc, but I DO get a slightly different output when looking at the syslog and grepping for ‘lirc’:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
    lirc_dev: lirc_register_plugin: sample_rate: 10
    [] init_module+0×48/0×50 [lirc_pvr150]

    I’m pretty new to the linux stuff, so if there’s a no-brainer step in your instructions (do I need to do anything beyond adding the .bin to the directory? since I’m running a mythbuntu install, do I need to somehow remove the old version of lirc, or did it just get stepped upon?), I may have missed it.

    Any ideas?
    - Dan

  344. 344
    mark Says:

    > (Dan)
    > Sorry if this is a double comment – my last one didn’t seem to go through.

    Only got it once!

    > Firstly, thanks for the effort you’ve put in to this.

    Cheers!

    > lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)

    You are loading the wrong module, you need lirc_pvr150. Probably you have a
    distribution package installed, if so uninstall it first. Otherwise a simple

    killall lircd && rmmod lirc_i2c && modprobe lirc_pvr150

    should get the right module loaded.

    > (Jeff)
    >…have a Scientific Atlanta Explorer 3100 that doesn’t seem to respond
    > to any of the codes provided (0_78 is the codeset for this box, but
    > i’ve also run send_power_new).

    check if it’s actually on the transmitter (use a torch, see the instructions above).
    Other than that if it doesn’t respond, and the LED is blinking when you send stuff,
    then I guess you must be sending it the wrong thing. It should certainly be possible
    to get it to work with a serial IR blaster (since you can basically send anything).

    > (truekaiser)
    > not asking for a newer firmware.
    > I want to know what is the date of the driver you pulled the above firmware from?

    Not sure, sorry. It was last updated on 2007-09-27, if there is a newer release from hauppauge
    then I am happy to update it. (I don’t really look unless someone prods me).

  345. 345
    James Says:

    Mark,

    I know I’ve said it before, but you really do rock with all this! :) That said, I’m hoping you can help.

    I recently had everything working fine in a box running Gutsy (7.10) and then I’ve had to move to a new box. Now, for some reason, I can’t get it to work! Any thoughts? Specifically, I’ve tried installing mythbuntu (and then uninstalling it), and I’ve installed ivtv 1.03 and followed your instructions to the letter. I usually get as far as running irw and it all looks good, but when I run the blaster script it says “hardware does not support sending”. So, I uninstall any lirc packages I can see, then run your killmod command and it comes back saying irw can’t work because “connect: No such file or directory”. When I reboot and try again, irw doesn’t let me run and the send_power_new returns “irsend: could not connect to socket” and “irsend: Connection refused”.

    Help?!?!

  346. 346
    mark Says:

    You probably have lirc_i2c loaded, check dmesg/syslog.

  347. 347
    James Says:

    Nope – it wasn’t loaded.

    So, here’s where I’m at. I’ve removed any myth related packages and rebooted my machine. I then started to follow your steps from the top. So, I went into the /usr/src/lirc… directory and re-ran setup.sh. I then ran make and make install and it seemed to go fine. Then I put in ‘modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1′ and it didn’t return to the prompt – it just sat there (kinda like irw used to when it worked).

    So, I Ctrl+C but that wouldn’t quit it! I opened another terminal and killed the process and typed dmesg. The last line in the dmesg output is:

    “[ 284.272776] lirc_pvr150: chip found with RX and TX

    It goes no further than that.

    ?!?

  348. 348
    James Says:

    Fixed it! There is a documented bug in Gutsy – http://ubuntuforums.org/showthread.php?t=587732 for the fix!

  349. 349
    Francisco Says:

    Hi Marc,

    I have just upgraded your pre-patched lirc 0.8.3-CVS-pvr150-2 version for my Sidux BOX with this kernel:

    2.6.24-2.6.24.3.slh.8-sidux-686

    this kernel includes the ivtv driver, works ok for mythtv.

    In previous version everything was ok. I put my previous files on /etc/lircd.conf and ~/mythtv/.mythtv/lircrc

    Now only ir-blaster is working to change channels in mythtv. It seems irw does not receive signals from remote control (no messages).

    When driver is loading I received the following info (dmesg) additional to your Howto,

    Thanks for your help or ideas. Francisco

    lirc_dev: IR Remote Control driver registered, major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 302355 loaded
    lirc_pvr150: 743 codesets loaded
    lirc_pvr150: 01 60 00 01 5blirc_pvr150: 05 02 04 4b 1alirc_pvr150: 09 79 88 b1 1flirc_pvr150: 0d 87 f5 16 61lirc_pvr150: 11 a6 d9 ec 9alirc_pvr150: 15 0f a7 ab 27lirc_pvr150: 19 48 9d 7e 1alirc_pvr150: 1d d9 0c 0e 48lirc_pvr150: 21 91 77 d6 3dlirc_pvr150: 25 09 44 18 60lirc_pvr150: 29 e5 12 c6 6clirc_pvr150: 2d ba 32 c4 26lirc_pvr150: 31 e3 76 01 48lirc_pvr150: 35 a2 7d 81 59lirc_pvr150: 39 90 28 8f 48lirc_pvr150: 3d 79 61 b4 0alirc_pvr150: 41 0b 57 21 6elirc_pvr150: 45 00 78 ad 62lirc_pvr150: 49 b5 68 a2 27lirc_pvr150: 4d 42 4e da 6clirc_pvr150: 51 94 63 0e 2alirc_pvr150: 55 1a 30 3b 45lirc_pvr150: 59 fa 34 25 e5lirc_pvr150: 5d cb 1e c1 eelirc_pvr150: 61 00 00 00 eelirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_pvr150: 01 60 79 29 d9lirc_pvr150: 05 ea 0e 48 91lirc_pvr150: 09 77 d6 3d 09lirc_pvr150: 0d 44 18 60 f5lirc_pvr150: 11 03 c1 5f bblirc_pvr150: 15 fe c7 bf edlirc_pvr150: 19 10 01 48 a2lirc_pvr150: 1d 7d 81 59 90lirc_pvr150: 21 28 0d 48 68lirc_pvr150: 25 13 c6 78 7alirc_pvr150: 29 26 53 1c 71lirc_pvr150: 2d 09 dc 10 c7lirc_pvr150: 31 19 d3 56 30lirc_pvr150: 35 3c ab 1d e6lirc_pvr150: 39 11 7c 5b 69lirc_pvr150: 3d f0 b8 ba 05lirc_pvr150: 41 cb 81 e5 26lirc_pvr150: 45 f3 f1 b7 6elirc_pvr150: 49 88 29 c2 f6lirc_pvr150: 4d bb e7 9f 1alirc_pvr150: 51 ed 39 93 45lirc_pvr150: 55 cd 3b d9 1clirc_pvr150: 59 89 fe b7 5dlirc_pvr150: 5d 82 7e 64 0elirc_pvr150: 61 00 00 00 0elirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)

  350. 350
    Dave Says:

    First off, I appreciate your work on this. I’ve been using it for a few years now.

    I’ve just recently ran into a problem with my latest rebuild of my Myth box. The problem is that I have to restart lircd several times for it to work. I’m not sure if this is a timing thing or what, but I initially start lircd using /etc/rc.local with the following commands:

    #Reset ivtv ir
    #I have to do this with the latest build, or /etc/lircd.conf doesn’t get loaded
    /usr/local/bin/ivtvctl –reset-ir

    #Start lirc and fix permissions
    if [ ! -c /dev/lirc0 ]; then
    mknod /dev/lirc0 c 61 0
    chmod a+rw /dev/lirc*
    fi

    modprobe lirc_dev && modprobe lirc_pvr150
    lircd –device=/dev/lirc1

    #For some reason I have to kill and restart lircd — not sure why
    kill -9 `cat /var/run/lircd.pid`
    lircd –device=/dev/lirc1

    In the script I use to automatically start mythfrontend I also kill and restart lircd. Unfortunately, I have to run the script 2x before the remote will start responding. So, basically, the 3rd time is the charm.

    The logs don’t say anything different when the remote works, and when it doesn’t. I can post some logs if necessary, but I didn’t want to clutter things up.

    Does anyone else have to load lircd multiple times before the remote will respond? Do I need to let something finish loading before starting lircd? Any suggestions would be appreciate as I’m not really sure where to go from here.

    I am running Fedora 8 x86_64 on 2.6.23.15-137.fc8

    Thanks,
    Dave

  351. 351
    Cody Says:

    Marc, I am having exact same issue as post # 349 by Francisco. Irblaster works great with the test script, but IRW does not work at all. I am running Fedora, btw.

  352. 352
    Steve Says:

    Hope this isn’t a dup, as my last comment didn’t seem to show up.

    I noticed that there’s a new IRBlasterWizard on the Hauppauge website as of Oct 2007 that claims to support 50 new devices, and since I can’t seem to get my BEV 4100 to work, I was wondering if we can get those new codesets? My card (actually an HVR1600) is in a Linux-only box at the moment, but if neccessary, I might be able to find some windows hardware to move it to and help the process…

    Thanks in advance,
    Steve

  353. 353
    Jason Antman Says:

    For anyone else who is having problems with this under OpenSuSE 11.0, I’ve gotten it working!

    The instructions are at:
    http://blog.jasonantman.com/2008/09/lirc-and-hauppauge-pvr-150-on-opensuse.html

  354. 354
    kai Says:

    Hi Mark,

    Thanks for the great work on this driver. It’s worked beautifully for me on a Debian 2.6.22 system. However, I now upgraded to 2.6.26 (on an AMD64, stock debian kernel), and the latest version from your site wouldn’t compile until I included the patch at http://svn.debian.org/viewsvn/pkg-lirc/lirc/trunk/debian/patches/20_kcompat-2.6.26.patch

    With the modifications from that patch I was able to compile, but the module won’t load. modprobe lirc_pvr150 gives:
    [ 2686.524689] lirc_pvr150: no symbol version for lirc_register_plugin
    [ 2686.524691] lirc_pvr150: Unknown symbol lirc_register_plugin

    Trying to force the load with modprobe -f gives:
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.26-1-amd64/misc/lirc_pvr150.ko): Invalid module format

    Am I missing something? Or does this require some more work on the source?

    Thanks so much!

  355. 355
    kai Says:

    Mark,

    Thanks so much for your work on this. The lirc_pvr150 module has been working flawlessly for me on a stock Debian 2.6.22-amd64 kernel.

    However, I recently upgraded to the stock 2.6.26-amd64 kernel and haven’t been able to get the module to work since.

    It wouldn’t compile, until I made the changes described in this patch: http://svn.debian.org/viewsvn/pkg-lirc/lirc/trunk/debian/patches/20_kcompat-2.6.26.patch

    After that, it compiles, but doesn’t let me load the driver.

    modprobe lirc_pvr150 gives:
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.26-1-amd64/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)
    (and the system log shows
    [44272.757096] lirc_pvr150: no symbol version for lirc_unregister_plugin
    [44272.757102] lirc_pvr150: Unknown symbol lirc_unregister_plugin
    [44272.757503] lirc_pvr150: no symbol version for lirc_register_plugin
    [44272.757505] lirc_pvr150: Unknown symbol lirc_register_plugin )

    Trying to force the load over the unknown symbols with
    modprobe -f lirc_pvr150 results in
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.26-1-amd64/misc/lirc_pvr150.ko): Invalid module format (no additional entry in the system log)

    Am I missing something or is this something that needs to be fixed in the driver code?

    Thanks again!

  356. 356
    terrapin Says:

    Dear Mark,
    I’ve been using your pvr150 module for months, and it’s great, but after an update to kernel 2.6.26, I can’t get it to compile anymore. It complains about a missing autoconf.h, due to a different kernelsource layout??

    Any chance you could help me?

  357. 357
    cienanos Says:

    I was wondering if the ir-blaster firmware has been updated to include all of the codes that are in the ir-blaster setup version 6 from hauppauge? If not, is there any way to get the codes from this version?

  358. 358
    Moisha Says:

    Hi, Mark,

    Any plans to update for the latest 2.6.26 kernels ?
    Compiling on Fedora8 2.6.26.5-28.fc8, I receive the error, related to a bug described here http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg551064.html

  359. 359
    mark Says:

    I have updated the driver to 2.6.27 kernels.

    Sorry for the massive delays in getting around to this, I’ve been quite a bit side tracked. The good news is that work is being done to get lirc+this driver in the mainline kernels, so hopefully things will all work out of the box for people in future.

  360. 360
    mark Says:

    In terms of the ‘firmware’, I’ve not updated it in a while, I will try and do it in the next couple of weeks. I assume it’s probably been updated since the last revision.

  361. 361
    Travis J Says:

    Not sure the right place for this, but I’m hoping you can point me in the right direction. My running Mythbuntu 8.10, trying to get lirc running with my pvr-150. Actually, I got it working, sending and receiving, except…

    My satellite receiver is a Dish Networks 3xx. That means the codes used for the blaster start at 2156396544. These codes cause lircd to segfault at startup. When I use a code less than 2147483648 (2^31), it works fine; once I pass 2^31, I get a segfault trying to start lircd.

    I don’t even know where to report this bug. :) Is it with the lirc folks, with the Ubunut folks, or here?

    Anyway, a year ago, I had everything working fine on a “Myth on Fedora” install hand-patching with your code. Am I going to break things, make things better, or have no change if I take your tarball and install it?

    Thanks.

    tj

  362. 362
    mark Says:

    Try it I guess. Sounds like a really old bug that was fixed some time ago, but it might have got reintroduced somewhere along the way.

  363. 363
    al Says:

    Sci-Atlanta Explorer 4250 – codeset 41 works as long as the emitter is directly over the receiver. If it\’s off by 1mm it will not work.

  364. 364
    mark Says:

    it’s an led on the end of the wire, not an ir transmitter, so the range is short. 1mm is surprisingly short but at high frequencies the distance will be shorter. In summary, it’s not something i can do anything about — it’s just hauppauge using dirt cheap components!

  365. 365
    Gary Says:

    I am having problems installing this with Ubuntu 8.10 and kernel 2.6.27-9-generic

    Following instructions and running modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1 gives this output

    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.27-9-generic/kernel/ubuntu/lirc/lirc_pvr150/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)

    based on messages 231 233 I ried commenting out the line(s) with ivtv_reset_ir_gpio in lirc_pvr150.c (Had to comment out 3 lines for the compile to work)

    but I still get the same module load failure

    dmesg | grep lirc gives

    449.106114] lirc_pvr150: disagrees about version of symbol ivtv_reset_ir_gpio
    [ 449.106121] lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

  366. 366
    Scott Says:

    lirc fails to load already a process running.. how do I stop the other instance of lirc running? I thinh Mythbuntu 8.10 loads lirc, however my pvr150 would’nt work out of the box. this is the message I get when I run modprobe lirc_pvr150 debug=1

    Feb 7 02:30:50 mythbuntu kernel: [ 2412.417405] lirc_dev: IR Remote Control driver registered, major 61
    Feb 7 02:30:50 mythbuntu kernel: [ 2412.639299] bttv: driver version 0.9.17 loaded
    Feb 7 02:30:50 mythbuntu kernel: [ 2412.639317] bttv: using 8 buffers with 2080k (520 pages) each for capture
    Feb 7 02:30:51 mythbuntu kernel: [ 2412.839785] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
    Feb 7 02:30:51 mythbuntu kernel: [ 2412.870248] lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
    Feb 7 02:30:51 mythbuntu kernel: [ 2412.870992] lirc_dev: lirc_register_plugin: sample_rate: 10
    Feb 7 02:30:51 mythbuntu lircd-0.8.3[7312]: lircd(userspace) ready
    Feb 7 02:30:51 mythbuntu kernel: [ 2413.133587] Error: Driver ‘i2c ir driver’ is already registered, aborting…

    Any sugeestions?
    Thanks :)

Leave a Reply


nine * 1 =