Final update
I have forward ported the code to the latest lirc release, fixed some bugs, and the i2c fixes have been merged into the ivtv-0.4.2. Please see this separate post, where I have removed all of the irrelevant history and only describe steps that are currently useful.
All new update
I’ve updated the ‘firmware’ file to include the new codesets recently released by hauppauge. This was a bit of a pain, as I had to disassemble my myth box to do it (bah, closed source). I hope they don’t do this too often in future! If anyone has got a spare PVR-150 or is willing to stick it in a windows machine and run wacky software then that would be nice the next time around 🙂 Alternatively you can bribe me I guess!
Update
Quick update: I have been working with the ivtv driver to see if I can resolve the root cause of the problem with the IR chip locking up and needing to be reset. I think that I have done so, but I can’t be sure until I get more testing feedback. I’ve updated the howto below to point at this post which contains the details of how to install the patch to ivtv. If you’ve followed all of the steps below and are still experiencing intermittent remote drop-out issues (as a couple of people have noted), you might want to try this out. I realise that this is quite a long and complicated procedure, so I’m working towards getting all fixes into the release versions of ivtv & lirc eventually. Obviously I’ll keep this updated as things progress. Slight update: up to about 28 hours now with no remote issues. Very encouraging. Further update: it works. Has been for months, and for others too. It’s in the 0.4.2 candidate release, so hopefully this issue should just die at some point. It also looks like hauppauge have put this in their mainline driver, which was updated some time in October. I’ve not disassembled it to check yet though 🙂
I’ve uploaded a slightly newer patch/package correcting two bugs. The first is not to reset the IR chip if you try and send an invalid code (by messing with lircd.conf!) since this clearly isn’t necessary. The second is a stack overrun bug spotted by Pascal Brisset, which could have had nasty consequences. I guess since I’ve not seen it the way I use lirc it’s only sending one code at a time to the driver. btw, this stuff is in my SVN repository, under trunk/3rdparty/lirc, if you want to do development on it.
The old stuff
OK, I’ve been playing with this off the back of the basic problem that seems to have been encountered by a lot of people, myself included — after a while the IR chip on the PVR-150 locks up, and hence the remote/blaster stop responding. (This happens with release versions of lirc/ivtv, so is definitely not related to what I’ve been doing with the IR blaster). This problem is pretty difficult to reproduce (i.e. I can’t do it on demand), but only seems to happen if you are using the encoder on the card at the time. I tried reproducing it with the Windows software, but I couldn’t manage it. I might not have tried hard enough; google search show that quite a few people have got this to fail, or it might be that hauppauge fixed the problem at some point. I don’t really know anything about this chip (it’s some software running on a fairly general purpose CPU, so it would be hard to without explicit information from hauppauge or some reverse engineering of that code, which is beyond me at this point in time), so I’m not sure why it happens. If anyone from hauppauge wants to step up and provide me with some information I’d be very happy!
There does exist a sort of solution for this: ivtvctl provides an ioctl that resets the IR chip on the card. Some people have this running every minute from a cron script, whilst that’s not a great solution it is a workable one. My issue with that is if you reset the IR chip, you have to send the boot block again to the IR blaster, so if I’d adopted the cron script I wouldn’t be able to change channel any more.
So after all that, I’ve adopted a delightful solution — detecting when the IR chip has locked up (i.e. stopped responding to i2c traffic), and resetting it in the driver. It’s messy, but it works, and as I do it in the driver, I can transparently retry IR blaster sends, which saves me from recording the wrong channel. Anyway, that was a bit long, so here’s a changelog:
– Split the code out into a new lirc driver, lirc_pvr150.
– TX and RX portions are treated as a single device. This makes good sense as you then only have one lirc socket that supports both receiving and sending (if the TX hardware is actually found).
– The RX device is ‘polled’ in the same way that the windows driver appears to. This is a good place to detect whether it has died or not.
– IR device is reset on failure and operations are retried (needs ivtv patch)
– A local copy of the ‘firmware’ data is made and release_firmware() is called. This prevents a hotplug timeout that I used to see (the script expects that firmware is released when loading is finished).
– Merge with lirc-0.72 release (rather than pre2)
– Module is reference counted properly
– Module has parameters disable_rx and disable_tx. You can use, e.g. modprobe lirc_pvr150 disable_tx=1 if you are not interested in setting up the IR blaster device.
Here’s the updated HOWTO for this version:
1. Get the pre-patched lirc 0.7.2 (or just the patch should you prefer).
2. Unpack the patched lirc (or apply the patch)
cd /usr/src
tar xfj lirc-0.7.2pvr150.tar.bz2
cd lirc-0.7.2pvr150
./configure
Choose:
TV card
h – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
Save configuration & run configure
then:
make && make install.
3. Note that this step is no longer necessary with ivtv >= 0.4.0 (the current stable release series), which is recommended — the export symbol patch was included. Skip right on to step 5 if you’ve grabbed the latest stable release, or go to 3a if you are having ‘remote stops responding’ issues (doesn’t seem to affect everyone).
3a As an alternative to the below, see this post. Don’t do both. I’ll update this if that patch proves to solve problems for people. I am hoping it might, it’s working very well for me so far.
3b Patch your ivtv driver and rebuild it. This step is necessary to be able to reset the IR chip. Download the patch here. Note that this patch does not apply to some versions of ivtv. I’m currently using 0.3.7a, so it should apply cleanly to that. If you want to use a later driver, the change is actually pretty trivial, we just need to export an extra symbol. In drivers/ivtv-driver.c, you need to add:
#include “ivtv-gpio.h”
near the top of the file after the rest of the #include lines, and
EXPORT_SYMBOL(ivtv_reset_ir_gpio);
right at the bottom of the file where all the other EXPORT_SYMBOL lines are. All this does is export that symbol for use by other modules, it does not change the functionality of the driver in any way. If you have trouble with this then drop me a line and I will create a patch for the version of ivtv you want to use.
cd /patch-to-ivtv-driver (e.g. cd /usr/src/ivtv-0.3.7a)
cd driver
patch < ivtv-driver.c.patch
cd ..
make && make install
4. Unload & reload the new ivtv driver. If lucky, rmmod ivtv && modprobe ivtv, otherwise either
kill everything that might be using the driver/unload all dependent modules or just reboot if you can’t be bothered with that.
5. 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 200K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).
6. 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 20927 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 575 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.
7. 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.
8. 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
9. 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.
10. 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 (575 at present).
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 and took me a couple of goes to get right. Some people have reported needing
to have the device attached back to front.
If you can’t get this to work:
a) My software doesn’t work properly
b) The device you are trying to control is not supported (please check against the Windows stuff if possible)
c) You didn’t get the device in the right place — did I mention it was touchy?
11. 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).
12. 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.
That’s it, good luck!
again jumped the gun, that worked except when i rebooted, it killed it. comes back with a
irsend: could not connect to socket
irsend: Connection refused
error. im going to look in to it when i get home from work.
I think you just need to add the line that runs lircd to your boot script (and possible the mknod if /dev/lirc1 is not present on reboot).
The donate link is at the top right — under pages (or here).
Thanks!
Mark
Pascal: I don’t know what outputs the device is capable of generating. You certainly can’t send SPACE_ENC to it as though it was a homebrew device — I don’t have enough information about the hardware/software to make it work like that (although I’m hoping to get this information from Hauppauge at some point).
The only thing I can do with it is what the windows software does — which is to replay outputs that Hauppauge have captured (and then I captured from their software). If your device is relatively common, there’s a good chance that one of their captured codesets works with it. If it’s rare, a good chance not. In any case, it’s probably worth running the procedure above to see if it responds to any of their captured codesets. If not, unless you can figure out the format of the 99 byte data blocks they send to the device, I don’t think you’ll be able to do what you want with it.
HTH,
Mark
Mark, Got it working b4 i went to work, man im on a high now – cant wait to leave and get the rest working – im moving in 3 days to my new place, and this one was for my parents so i definetly had to finish it. Now my only concern is to make some kind of restore disk for them, if they mess it up, Does anyone out there know if there is a program that i can make a bootable restore cd (or dvd) for linux? like a norton ghost or something? that will boot, and give them the option to restore?
here is what i did to my boot
i added
lircd –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lircd1.pid
to the bottom of the file, so now my /etc/init.d/bootmisc.sh file looks like
modprobe lirc_pvr150
lircd
lircd –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lircd1.pid
Im going to donate you the amount of a case of Canadian Beer, this is well worth the efforts. Thank You again!
Mark, thanks for the clarifications. I ran send_power_new a few more times and eventually it worked.
In case anyone cares, the PVR150 codeset for the Freebox V4 is 462.
Ok, this might sound incredibly stupid, but I’ve spend 3 days on it already so here goes. Where does one find the ivtv driver files (ie ivtv-driver.c) on Fedora Core 4 in order to patch them as discussed in step 3? I installed ivtv via rpm so I’m not sure if I even have this code. I tried installing an ivtv.blah.src.rpm but still no joy.
Any suggestions?
Ok, disregard my previous message… I’ve gotten past that stupidity (kind of). I’ve managed to add the patch (manually) and make && make install seems to run successfully. I then configured and did make && make install on the lirc patch. I seem to be having the same problem as the guy in the first post:
/sbin/modprobe lirc_pvr150 debug=1
FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.12-1.1456_FC4/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)
I know I’ve added the symbol export to ivtv-driver.c (quadruple checked)… Is it possible my install quietly barfed and I’m loading the old ivtv module? I’m running FC4, if that helps…
dmesg output is as follows:
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.3.8 (tagged release) loading
ivtv: Linux version: 2.6.12-1.1456_FC4 686 REGPARM 4KSTACKS gcc-4.0
ivtv: In case of problems please include the debug info
ivtv: between the START INIT IVTV and END INIT IVTV lines when
ivtv: mailing the ivtv-devel mailinglist.
ivtv: Autodetected WinTV PVR 150 card (iTVC16 based)
ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [LNK2] -> GSI 5 (level, low) -> IRQ 5
tveeprom: Hauppauge: model = 26032, rev = C199, serial# = 8239201
tveeprom: tuner = TCL 2002N 5H (idx = 99, type = 50)
tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
tveeprom: audio processor = CX25841 (type = 23)
tveeprom: decoder processor = CX25841 (type = 1c)
ivtv: i2c attach to card #0 ok [client=tveeprom[50], addr=50]
tuner: chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
ivtv: i2c attach to card #0 ok [client=(tuner unset), addr=61]
cx25840: loading /lib/modules/HcwMakoA.ROM
ivtv: i2c attach to card #0 ok [client=cx25840[50], addr=44]
ivtv: i2c attach to card #0 ok [client=wm8775[50], addr=1b]
ivtv: loading /lib/modules/ivtv-fw-enc.bin
ivtv: Encoder revision: 0x02040024
ivtv warning: Encoder Firmware can be buggy, use version 0x02040011!!!!
ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
ivtv: Initialized WinTV PVR 150, card #0
ivtv: ==================== END INIT IVTV ====================
lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio
notice that it says it’s loading 0.3.8 (tagged release)… How do I know which module I’m actually loading???
Hey Mark,
Quick one for you, i have everything installed and the remote stops responding for about 2 minutes at a time, an output of dmesg reveals the following.
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
i2c_adapter i2c-2: sendbytes: error – bailout.
lirc_pvr150: i2c_master_send failed with -14
lirc_pvr150: polling the IR receiver chip failed, trying reset
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
i2c_adapter i2c-2: sendbytes: error – bailout.
lirc_pvr150: i2c_master_send failed with -14
lirc_pvr150: polling the IR receiver chip failed, trying reset
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
any ideas? seems its doing what it should be, (restarting the IR chip if it freezes up) but not right when it dies.
Hi Scott,
Thanks very much for your generous donation. Sorry to hear that you’re having troubles — I haven’t seen this problem with my set up. Some questions:
– Can you send me the dmesg output with modprobe i2c-algo-bit i2c_debug=3, keeping the log times as well?
– Are you doing anything else with the card at the same time? Basically, listing any steps that you take to cause the problem would help me to try and get it to happen for myself.
I see the remote drop out occasionally for a few seconds (max about 10) corresponding with the reset log entries, but it doesn’t reset the chip that often for me.
Thanks,
Mark
akjohn: sorry this is out of order. It seems that either you are loading the old module, or you didn’t do depmod -a after installing the new one. depmod -a should report any unresolved symbols.
modinfo ivtv will tell you which module it wants to load. You can check md5sums to see if it is the same as your built version, and objdump -t |grep ksymtab to see if it exports the symbol properly.
This has got to be one of:
– depmod not re-run
– wrong module
– patch not applied correctly
with the likelihood that it’s one of the first two.
HTH,
Mark
Mark, im sorry man, im still learning alot about linux, can you explain to me exactly what you want me to do, ie:
#modprobe i2c-algo-bit i2c_debug=3
#dmesg
is this right?
Mark,
Thanks for your reply. It turned out that I was loading the wrong module. Apparently fedora keeps it’s modules in a strange directory so make install didn’t put them in the “right” place. I just replaced the old modules with the new and everything is working wonderfully now! Thanks a ton for putting this info together! Now all I have to do is get stubborn mythtv to actually call my changechannel script and I’ll be set (it’s always something isn’t it?)…
Again, thanks for the help and info.
John
Hi!
I can’t compile lirc. I downloaded lirc-0.7.2pvr150 and configured it. But when I type make I get the following warnings and errrors.
Can anyone help me?
lirc_pvr150.c: In Funktion »add_to_buf«: lirc_pvr150.c:200: Warnung: implicit declaration of function `i2c_get_adapdata’ lirc_pvr150.c:200: Warnung: Verarbeiten des Argumentes 1 von »ivtv_reset_ir_gpio« erzeugt Zeiger von Ganzzahl ohne Typkonvertierung lirc_pvr150.c: In Funktion »lirc_thread«: lirc_pvr150.c:259: Warnung: implicit declaration of function `lock_kernel’ lirc_pvr150.c:259: Warnung: implicit declaration of function `unlock_kernel’ lirc_pvr150.c: In Funktion »fw_load«: lirc_pvr150.c:580: error: structure has no member named `dev’ lirc_pvr150.c: In Funktion »write«: lirc_pvr150.c:971: Warnung: Verarbeiten des Argumentes 1 von »ivtv_reset_ir_gpio« erzeugt Zeiger von Ganzzahl ohne Typkonvertierung lirc_pvr150.c: In Funktion »i2c_attach«: lirc_pvr150.c:1178: error: Fehler beim Parsen before “do” make[6]: *** [lirc_pvr150.o] Fehler 1 make[6]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150′ make[5]: *** [_mod_/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150] Fehler 2 make[5]: Leaving directory `/usr/src/kernel-source-2.4.27′ make[4]: *** [lirc_pvr150.o] Fehler 2 make[4]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150′ make[3]: *** [all] Fehler 2 make[3]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers/lirc_pvr150′ make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150/drivers’ make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/var/lib/video.00/driver/lirc-0.7.2pvr150′ make: *** [all] Fehler 2
scott: I sent you a mail that hopefully should explain what I meant in more detail. I’m going to look at disassembling the hauppauge driver to see if I can figure anything out from it tomorrow (although that will take some time to complete).
akjohn: Great, I’m glad you got it working!
CyberCSK: I think this will only compile against a 2.6 kernel. If possible, can you try upgrading your kernel?
If not, I might be able to look at getting it to compile with a 2.4 series sometime next week.
A few days ago I reported my set-top-box responds to codeset 462. Unfortunately there are only 15 keys for codeset 462 in lircd.conf, whereas my remote has 35 buttons.
Mark, is this because the Windows software from Hauppauge only supports those 15 keys ? Or is this related to the way you extracted the codes ?
I had a look at the 99-byte blocks for this codeset and found some correlations with the IR pulse bits, but I can’t make sense of all the data. Has anyone succeeded in generating blocks, maybe for other codesets ? Any hints ?
This is because the windows software only supports those 15 keys. I’m curious as to why this is an issue? The only use I can think of for remote controlling your cable/sat box is to change channel so that you can record the right program with myth, or equivalent. Thus the only keys you need are going to be numbers 0-9, with maybe the two digit button and power (if you want to turn it on/off before/after recording).
In terms of generating new codesets, as previously stated, I have no idea how to do this. All I’ve got is the data I captured from the windows software. I’d be interested to know what correlations you found though.
It is possible that some understanding could be gained by disassembling the hauppauge driver. It’s not that simple though as there aren’t really very many starting points (sure, I can see the top level function that gets the data, but after that it’s a lot of bit twiddling and tables so I would reckon on a few days work before I knew what was happening with it).
Pingback: Mark’s Braindump » PVR-150 IR stops responding (maybe fixed!)
> The only use I can think of for remote controlling your cable/sat box is to change channel
The set-top-box sits in a closet with all the other rack-mounted
hardware, so I’d rather not use the original remote at all, even
for the other functions.
Another issue: In order to trigger some functions, I need to keep a button depressed for ~1 second. It seems that lirc_pvr150 can’t repeat codes
fast enough to simulate this. I patched your driver to download the data block only once, and also tried to insert delays between the I2C sends, with no result. Any ideas ?
Hmm, interesting. What exactly did you try? Repeating the W 00, load of NAKS, r 80 bit? The ‘load of NAKs’ take a while (up to 100ms), so that might be slower than the repeat rate of your remote, hence the box thinks that the key has been released. Alternatively your remote might use a repeat bit which isn’t being set in the transmitted code (I think most of them use a toggle bit and a timer though).
In any case, it seems that what you want to do requires a greater understanding of the data block than we currently have. I had a look over your analysis of the data blocks, but I don’t see anything much in them from a quick glance. I’ll try and have a more detailed look at the weekend. It might be worth just twiddling the bits and seeing whether you can get a different remote button to be output. I expect it would be pretty helpful to have a parallel/serial port receiver or the like and record the output from the device with the lirc_xxx driver so you can see exactly what effect your having.
As far as repeat rate goes, what exactly did you change in the driver?
OK, the repeat issue is fixed. I was incorrectly assuming that lircd would send multiple keypresses to the driver in a single write, but actually the repeat period is configured with the “gap” field in lircd.conf, and the default value was simply too high.
Please consider this patch, though.
– for (i = 0; i
HTML filter ate my patch…
– for (i = 0; i < n; )
+ for (i = 0; i+sizeof(lirc_t) <= n; )
{
int ret = 0;
lirc_t command;
printk(“sending %d %d\n”, i, n);
– if (copy_from_user(&command, buf + i, n)) {
+ if (copy_from_user(&command, buf + i, sizeof(lirc_t))) {
Oh nice! I’m surprised that hasn’t blown up in my face before — I guess the way I use it lirc is only sending one command at a time. I shall fix it forthwith!
Thanks,
Mark
OK, should be fixed (package/patch updated). I removed the “i+sizeof(lirc_t) <= n;" check as it already ensures that n % sizeof(lirc_t) == 0.
Hi!
[QUOTE]
If not, I might be able to look at getting it to compile with a 2.4 series sometime next week.
[/QUOTE]
I don’t think that its a good idea for me to upgrade the kernel, because it took me quite long to set my system up.
I would be very happy if you made the kernel compatible with 2.4.27.
I hope it’s not too much work…
thx
CyberCSK
btw: the reason why I want to try your lirc version is, that my PVR 150 doesn’t recognize the remote under linux (with newest ivtv driver and lirc with pvr patch), unless I previously booted XP and then rebooted to linux.
Have you any idea what i can do?
I discribed my problem here: http://www.gossamer-threads.com/lists/ivtv/devel/21952?search_string=remote%20150;#21952
Hi,
Unfortunately I’m not sure that my driver will help — basically if lirc_i2c does not work it’s a pretty sure bet that this driver won’t either. The IR polling works in exactly the same way — all my stuff does is to add support for the IR blaster (plus some code to try to recover the chip if it stops responding, although I seem to have fixed this with a new i2c implementation anyway).
I would seriously recommend upgrading both the kernel and the ivtv driver (0.3.4 is very old, and is really much more of a development snapshot than a stable release). I can try to help with this if you like. With debian (I think it is debian you are using?) it should be a simple matter of apt-get install kernel-image-2.6-arch to upgrade.
Like I said, it’s not that I’m unhappy to try to make it work with 2.4.27 (although that is a bit of a pain :), it’s more that I honestly don’t think that it will solve your problem.
Chalk me up as another successful user. I’d advocate getting these patches merged into the main branches of ivtv and lirc. This is a fantastic hack! Thanks for your hard work.
Hi!
As you suggested I updated my kernel to 2.6 and ivtv to the latest 0.4.0, but my problem still exists. Here I post the dmesg output with full debug.
Do you have any other suggestion, that might help me?
thx
CyberCSK
ivtv: ==================== START INIT IVTV ==================== ivtv: version 0.4.0 (tagged release) loading ivtv: Linux version: 2.6.12 preempt 586 gcc-3.3 ivtv: In case of problems please include the debug info ivtv: between the START INIT IVTV and END INIT IVTV lines when ivtv: mailing the ivtv-devel mailinglist. ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based) ivtv0 info: base addr: 0xe4000000 ivtv0 info: Enabling pci device PCI: Found IRQ 3 for device 0000:00:0b.0 ivtv0 info: Attempting to enable Bus Mastering ivtv0 info: Bus Mastering Enabled. ivtv0 info: 22 (rev 1) at 00:0b.0, irq: 3, latency: 64, memory: 0xe4000000 ivtv0 info: attempting ioremap at 0xe4000000 len 0x00800000 ivtv0 info: attempting ioremap at 0xe5000000 len 0x00800000 ivtv0 info: attempting ioremap at 0xe6000000 len 0x00010000 ivtv0 info: activating i2c… ivtv0 i2c: i2c init ivtv0 i2c: setting scl and sda to 1 tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0 ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0) ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b] tveeprom: ivtv version tveeprom: Hauppauge: model = 26034, rev = C197, serial# = 7703309 tveeprom: tuner = TCL 2002MB_3H (idx = 97, type = 55) tveeprom: tuner fmt = PAL(B/G) PAL(D/K) (eeprom = 0x44, v4l2 = 0x00000e07) tveeprom: audio processor = CX25842 (type = 24) tveeprom: decoder processor = CX25842 (type = 1d) ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50] cx25840 0-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0) cx25840 0-0044: loaded /lib/modules/HcwMakoA.ROM firmware (14264 bytes) ivtv0 i2c: i2c client attach ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44] ivtv0 info: Active card count: 1. ivtv0 info: Loaded module tveeprom ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: using client 2, addr 0x50 ivtv0 info: PAL tuner detected ivtv0 info: Loaded module tuner ivtv0 info: Loaded module cx25840 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: Loaded module wm8775 ivtv0 info: Loaded module tda9887 ivtv0 info: Stopping VDM ivtv0 info: Stopping AO ivtv0 info: pinging (?) APU ivtv0 info: Stopping VPU ivtv0 info: Resetting Hw Blocks ivtv0 info: Stopping SPU ivtv0 info: Sleeping for 10ms ivtv0 info: init Encoder SDRAM pre-charge ivtv0 info: init Encoder SDRAM refresh to 1us ivtv0 info: init Decoder SDRAM pre-charge ivtv0 info: init Decoder SDRAM refresh to 1us ivtv0 info: Sleeping for 600ms (600 recommended) ivtv0 info: Card ready for firmware! ivtv0 info: Loading encoder image ivtv0: loading /lib/modules/ivtv-fw-enc.bin ivtv0 info: Sleeping for 100 ms ivtv0 info: Sleeping for 100 ms ivtv0 info: GPIO INIT ivtv0 info: About to search for mailboxes ivtv0 info: Searching for encoder mailbox ivtv0 info: match: 0x34567812 at 0xd5280104. match: 1 ivtv0 info: match: 0x56781234 at 0xd5280108. match: 2 ivtv0 info: match: 0x78123456 at 0xd528010c. match: 3 ivtv0 info: found encoder mailbox! ivtv0 info: Searching for decoder mailbox ivtv0 info: match: 0x34567812 at 0xd5c80104. match: 1 ivtv0 info: match: 0x56781234 at 0xd5c80108. match: 2 ivtv0 info: match: 0x78123456 at 0xd5c8010c. match: 3 ivtv0 info: found decoder mailbox! ivtv0 info: Getting firmware version.. ivtv0 info: Getting encoder firmware rev. ivtv0 api: API Call: 0x000000c4 (IVTV_API_ENC_GETVER) ivtv0 api: Releasing mailbox (before 0x00000007, after 0x00000000) ivtv0: Encoder revision: 0x02040011 ivtv0 info: v4l2 streams setup ivtv0 info: Configuring WinTV PVR 150 card with 4 streams ivtv0 info: Registered v4l2 device for encoder MPEG minor 0 ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total) ivtv0 info: Registered v4l2 device for encoder YUV minor 32 ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers (2048KB total) ivtv0 info: Registered v4l2 device for encoder VBI minor 224 ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB total) ivtv0 info: Registered v4l2 device for encoder PCM audio minor 24 ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total) ivtv0 info: Starting Threads ivtv0 irq: Masking interrupts ivtv0 i2c: call_i2c_client ivtv0 i2c: using client 0, addr 0x61 tuner: type set to 55 (TCL 2002MB) by ivtv i2c driver #0 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: ivtv_enc_thread: pid = 5485, itv = 0xd35a0000 ivtv0 info: encoder thread sleeping 5485 ivtv0 info: ivtv_enc_vbi_thread: pid = 5486, itv = 0xd35a0000 ivtv0 info: encoder thread sleeping 5486 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: using client 1, addr 0x1b ivtv0 info: Setting audio to input 0 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 ioctl: VIDIOC_S_STD ivtv0 info: Switching standard to PAL. ivtv0 i2c: call_i2c_client ivtv0 i2c: using client 0, addr 0x61 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 ioctl: VIDIOC_S_FREQUENCY ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 api: API Call: 0x000000d2 (IVTV_API_PAUSE_ENCODER) ivtv0 api: Releasing mailbox (before 0x00000007, after 0x00000000) ivtv0 info: Disabling digitizer ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: v4l2 ioctl: set frequency 6400 ivtv0 i2c: call_i2c_client ivtv0 i2c: using client 0, addr 0x61 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: using client 1, addr 0x1b ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 api: API Call: 0x000000d3 (IVTV_API_REFRESH_INPUT) ivtv0 info: Enabling digitizer ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 api: API Call: 0x000000d2 (IVTV_API_PAUSE_ENCODER) ivtv0 api: Releasing mailbox (before 0x00000007, after 0x00000000) ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 i2c: call_i2c_client ivtv0 i2c: skipping client 0, addr 0x61 ivtv0 i2c: skipping client 1, addr 0x1b ivtv0 i2c: skipping client 2, addr 0x50 ivtv0 i2c: using client 3, addr 0x44 ivtv0 info: Finished with Mute ivtv0: Initialized WinTV PVR 150, card #0 ivtv: ==================== END INIT IVTV ==================== lirc_dev: IR Remote Control driver registered, at major 61 lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no lirc_pvr150: ivtv i2c driver #0: no devices found
I’ve been playing around with getting this working, unfortunatly i’m plagued with lirc_pvr150: firmware haup-ir-blaster.bin not available (-2)
and i’ve placed the haup-ir-blaster.bin in every location i’ve found that had anything to do with firmware, and it just isn’t working. I’m using gentoo, i have hotplug installed, and the coldplug starting on bootup, i tried rmmoding lirc_pvr150 and remodprobing it, and it still has the same result. I can’t seem to find out where it’s looking for the firmware. Hotplug is set to load firmware from /lib/firmware, and it has a copy there. I’m stumped. I’ve read thru this and i haven’t seen any real answers on where this file _should_ be or how to find out whats causing this problem. Any suggestions would be great 😉
thanks,
jim
Update: i managed to get it working (i think) it spits alot of stuff in the logs, but it isn’t complaining any more and the LED lights up but unfortunatly none of the codes worked for my philips tv.. is there anywhere else i can find whats needed to turn the tv on?
Hi,
I have installed your driver and it seems to work well.
I have one problem thougn. I can’t change channels on my STB, except for the first 9 (those with a single digit).
I’ve tried repeating the irsend command at different intervals, but no luck so far.
Sending 1_600_KEY_1 twice always results in setting the STB to channel 1, not 11 as I wanted it to.
The STB is a Force satellite/terrestrial box.
I’ve tried to analyze the signal from the Force remote using the mode2 command, and this e.g. display 1200 or 1A00 for the ‘0’ key.
It seems that it is alternating a bit each time the button is pressed.
Could it be that the driver doesn’t do this? I.e. that the driver always send the same code to the STB?
I haven’t been able to verify this as the irsend fails when I am running the mode2 application. It says something about that it timed out.
I guess the alternating bit is used to see if the button is pressed twice or just not released. If I hold down a button, the same code is just repeated.
If I release and then press again, the bit is flipped.
Three different codesets seems to “work”, 1_600, 0_308 and1_498. I.e. the power button works and setting channel 1 through 9.
Haven’t tried other buttons so far.
Any ideas?
Hi everybody, sorry for the delay. I’ve been working non-stop for the past few weeks, including weekends and I just haven’t found the time to do anything else besides eat, drink and sleep!
Here we go with the out of order replies again:
Mike — great! I have got the export symbol part merged into the 0.4.0 ivtv release (about to update the howto), so just lirc to go.
CyberCSK — it looks as though you don’t have any IR hardware. As a quick one, you might want to try powering off the box completely (by removing the power cord from it), then pressing the power button (to drain the last bit of juice), waiting a few seconds, then plugging it in and starting it up again. From the ivtv-devel list, this seems to be the normal way to debug missing hardware. If it’s still not found after that then can you modprobe i2c-dev & then run i2cdetect on the ivtv bus and post the output? If it can’t talk to the hardware at all then, it’s either fried or not present.
Jim: I guess hotplug wasn’t set up properly? This seems to come up a lot, I’d be grateful if you would post the steps that you took to resolve this problem so that people can see how to do this in future. Regarding your tv, is it an STB? I think pretty much all of the codes are for STBs. At any rate, if it doesn’t respond, either there isn’t a codeset for it, or it’s just not picking it up. The transmitter is quite short range, you might want to check how it is positioned (exactly on top of the receiver is good, a torch can help with those bits of tinted plastic that they like to put on top of everything).
olav: I’m pretty sure it always sends the same code, as it’s just replaying the same block of data for each number. You might try hacking around the driver and fiddling with the data it sends to see if you can get it to flip the bit — although nobody has any clue as to the format of the data block at present (have a look at the XML file in the same directory as all the rest of the gubbins (here), that’s got the straight data blocks for each code/key combination as big hex strings. Unfortunately I can’t think of anything else to try — all I do is replay gubbins to the chip from a capture of what the Windows software does. There is definitely structure to it, somebody just needs to figure it out! Sorry I can’t be of more help.
Today is Tuesday October 25
Mark
I sent you an EMAIL this morning (before I found this at the bottom of the list) with a fair amount of debugging information on (at that time) my non-working) pvr150.
I finally got ALL the pieces together from this forum and my pvr150 blinks like crazy with send_power_new. Don’t know if it will drive my Motorola DCT-2224 but my hopes are high. After many failures, the keys for me were…. using Fedora FC4
1. I replaced all references to lirc_i2c with lirc_pvr150 in my /etc/modprobe.conf file.
2. I copied haup-ir-blaster.bin to /lib/firmware. It is the only entry there.
My dmesg output now looks like it is supposed to >>>
I would be interested to hear from anyone who has had success driving a DCT-2224.
Thanks for a bunch of help……. and remember
“Never give up !!!” Elliot Ness to Al Capone in the Untouchables
Hi, I have a mythbox amd64 pvr-150 running with lirc_pvr150 and the patched for the ivtv provided in this post. My remote still dies.. here are the messages in my log file:
i2c_adapter i2c-0: sendbytes: error – bailout.
lirc_pvr150: i2c_master_send failed with -14
lirc_pvr150: polling the IR receiver chip failed, trying reset
i2c_adapter i2c-0: sendbytes: error – bailout.
lirc_pvr150: i2c_master_send failed with -14
lirc_pvr150: polling the IR receiver chip failed, trying reset
lirc_pvr150: i2c_master_send failed with -121
lirc_pvr150: polling the IR receiver chip failed, trying reset
i2c_adapter i2c-0: sendbytes: error – bailout.
lirc_pvr150: i2c_master_send failed with -14
lirc_pvr150: polling the IR receiver chip failed, trying reset
I have the same problem as CyberCSK – my PVR150 card is working fine under IVTV for watching TV, but isn’t recognized at all by LIRC.
Taking what Mark said above, I ran i2cdetect and got:
Installed I2C busses:
i2c-1 unknown ivtv i2c driver #0 Algorithm unavailable
i2c-0 unknown SMBus I801 adapter at 0400 Algorithm unavailable
Which leads me to believe that LIRC needs to talk to card1, not card0 – any idea what parameter I need to put in to get lirc_pvr150 to do that? Thanks!
Today is Thursday October 27th
Mark
Wanted to let you know that I compiled your pre-patched module with
Fedora FC4 kernel 2.6.13-1.1532_FC4 and after reading and applying the
advice here, my PVR150 is blinking away merrily. It does turn off my DCT 2224 Motorola STB running your send_power_new… is there an easy way to determine which set controls my STB. I’m testing with an OTA antenna for the
present. One strange thing is I don’t get ANY sound on WTBS channel 17
here in Atlanta… all the others are fine. Not to worry… channel 17
sound doesn’t work under Windows either. I’ll look into that anomoly
later… once I figure out how to use MYTHTV. Thanks for your great
module and reams of advice.
Cheers
Latest batch of replies!
tk/ted — looks like you are basically there. The way to find the codeset is to just kill the script when your box turns off and see where it got to. Adding -x to the first line might help (#/bin/bash -x) as it will print out what just executed. You can then try a few manual irsends around the point at which it did turn off. I realise it’s not terribly elegant, but I’ve not found the time to code up a more elegant script yet (i.e. one that lets you stop/go back/forward). If it turns the box off, it will probably work. Regarding your lack of sound, I suggest that you post to the ivtv-devel list as the other people there have much more knowledge about that kind of thing than I do. They are generally very helpful too.
Eric: Can you run i2cdetect (i2cdetect 1) on the ivtv bus and post the output of that? The LIRC driver is capable of detecting which bus(es) belong to ivtv cards. It then scans those buses for the IR chip (TX or RX). (In this respect, my driver is no different from lirc-i2c from which it is derived). What I am interested in here is that the chip doesn’t seem to be present — which is weird. You might want to run ivtvctl –reset-ir after and trying it again to see if the outputs differ.
HTH,
Mark
George: sorry I missed you on the first pass!
A few other people have had this issue (it seems that some do, some don’t — even though the software/hardware should be the same). Go figure. Anyway, I believe I have fixed it with this, which you might like to give a whirl. If you have any success with it, please let me know, I’m keen to get that patch tested more widely. Note that it has a little fuzz applying to ivtv-0.4 (there will be a few rejects in ivtv-driver.c), but they are nothing to worry about.
Thanks,
Mark
Running ‘i2cdetect 1′ results in:
Error: Could not open file `/dev/i2c-1′ or `/dev/i2c/1’: No such file or directory
And indeed, there are no i2c entries in /dev
Running ivtvctl -reset-ir gives me:
ioctl VIDIOC_S_FREQUENCY ok
Frequency set to 0
Help?
Oh, and the results of i2cdetect do not differ before or after the ivtvctl -reset-ir command.
Followup:
Creation of /dev/i2c-1 with:
mknod /dev/i2c-1 c 89 1
and then i2cdetect 1 results in:
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
Which I can’t decipher….
It means that it can’t find the IR chip at all, which is somewhat of a disaster for the driver! There should be a chip appearing at 0x70 (TX) and 0x71 (RX). Can you post the full dmesg output for the ivtv module load (the bit between IVTV START & IVTV END or whatever it says)?
You might also try a proper cold boot (as described earlier on this page), and if possible, physically inspecting the card to see if it has a Z8F0811 chip on it (should be a small chip in the bottom left corner of the card). If you can do that, it would be worth reading the model number/revision off the card at the same time. It may be that something has changed in the card design (hauppauge do this frequently).
Here’s my dmesg dump:
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.4.0 (tagged release) loading
ivtv: Linux version: 2.6.13.2-chw-3 SMP preempt 586 gcc-3.3
ivtv: In case of problems please include the debug info
ivtv: between the START INIT IVTV and END INIT IVTV lines when
ivtv: mailing the ivtv-devel mailinglist.
ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based)
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 21 (level, low) -> IRQ 21
tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
tveeprom: ivtv version
tveeprom: Hauppauge: model = 26032, rev = C199, serial# = 8209030
tveeprom: tuner = TCL 2002N 5H (idx = 99, type = 50)
tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
tveeprom: audio processor = CX25841 (type = 23)
tveeprom: decoder processor = CX25841 (type = 1c)
ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
cx25840 1-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0)
cx25840 1-0044: loaded /lib/modules/HcwMakoA.ROM firmware (14264 bytes)
ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
ivtv0: loading /lib/modules/ivtv-fw-enc.bin
ivtv0: Encoder revision: 0x02040011
ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
ivtv0: Initialized WinTV PVR 150, card #0
ivtv: ==================== END INIT IVTV ====================
I’ll try the cold boot and the visual inspection and keep you posted.
Hi Mark,
I tried your driver on Fedora Core 4 most of the way was very smooth (I use the ivtv 0.4)… there are two issues I bumbed into:
1. When trying to start it /dev/lircd –device=/dev/lirc0
I get Permission denied…
2. When trying to send signal, I get:
irsend: command failed: SEND_ONCE blaster 1_14_KEY_POWER
irsend: hardware does not support sending
checking the remote with the irw works perfectly.
Any ideas ?
Thanks,
Tomer.
Comment for Eric…
My dmesg looked like yours until I added the following to /etc/modprobe.conf
in my Fedora FC4 system.
alias char-major-61 lirc_i2c # for lirc
alias char-major-61 lirc_pvr150 # for lirc_pvr150
OOPS
Eric … my suggestion has a typo… The first line should start with a # sound thusly:
or you can delete it completly
# alias char-major-61 lirc_i2c # for lirc
Hi Mark – I have today installed Fedora Core 4 and Mythtv using the tutorial on Wilsonet.com.
I have a PVR-150 for video capture, and the ir blaster and receiver.
My PVR 150 is setup and I can view video, and Myth is setup so that I can view the current channel and any music or movies. The hauppage remote is working great with Myth
What I have been unable to do is to get the blaster to control my stb so that Myth will change to the channel that I want it to.
I tried to follow your patch and instructions, but got some errors at the first steps. As my remote works ok in Myth and it’s just the blaster that I am having problems with can you advise what I might be able to do to get this working?
Thanks
Paul
Have been at my parents for the weekend, sorry for the delay. Replies:
Eric: any further progress? I hope things are going well for you.
Tomer: I think Ted sounds on the mark here and that the issue is probably that you have lirc_i2c loaded. This conflicts with lirc_pvr150 as they try to control the same piece of hardware. The belt and braces fix would be to remove the package completely and make sure that lirc_i2c, lircd, etc are gone and rebuild them from source. The litmus test is of course lsmod |grep lirc_i2c which will tell you if the driver is loaded — if it is, you need to killall lircd && rmod lirc_i2c lirc_pvr150, disable/remove it, and then make sure that lirc_pvr150 gets loaded (modprobe lirc_pvr150, run lircd as per instructions above).
Paul: Can you please post some more details — exactly which step are you having trouble with and what error messages do you get? You should also remove your existing lirc install before starting to prevent any conflicts with the lirc_i2c module.
HTH,
Mark
Mark – thanks for getting back to me… Not sure what else I can provide.
I am falling down at the very first step… have gone to /usr/src and extracted the tar.bz2 file. When I run ./configure I get the following error:
which: no dialog in (/usr/kerberos/sbin:/usr/kerberos.bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin)
dialog not found!
Please read the documentation!!!
I assume that this is because the guide was written for a different linux build and not fedora core4? Is there anything that I can do to get this working? IR Blaster from the PVR-150 would get my setup 100% ok if I can just get it working…
Thanks
Paul
Just a missing dependency — you need to install the dialog package first, e.g. a random RedHat ES 3 box says:
[root@clap root]# rpm -q –whatprovides dialog
dialog-0.9b-20020814.6