LIRC and MythBuntu 10.10

This is exactly myth related, but it is such a knowledgeable community....

I just seem to have no luck with LIRC blasting. I have an HD-PVR and initially setup HD-PVR to perform the blasting via lirc_zilog. (Followed the procedure outlined in http://www.mythtv.org/wiki/Hauppauge_HD-PVR#HD-PVR_Driver_Compilation_Howto). Unfortunately, the HD-PVR would lockup after a while with the lirc_zilog loaded. With the module unloaded, it seems fine. (Too bad, because ir blasting and the remote seemed to work fine!)

I then tried to configure using serial port. I copied over the lircd.conf file from the old server, setup hardware.conf and restarted the service. The lirc_serial module seems to correctly load, but the it doesn't change the channels. (Unfortunately this blaster doesn't light up like the HD_PVR, so I can't see if a signal is actually being sent, but if I plug it back into the old mythserver it still works..)

I found some notes suggesting there were some issues with serial blasting in October and early January.

Im running MythBuntu 10.10, 2.6.35-28, and lircd 0.8.7-pre3. Any suggestions on what to try next? 1) finding a combination of driver and lircd that works with hd-pvr 2) patching up lircd (not exactly sure how to do that now) 3) Wipe and install 10.4? 4) Gentoo? -- My old box is Gentoo, but MythBuntu just seems "easier" at the time. :-)

I do remember when I built the old box years ago, that the major version was important. I tried multiple combinations to get it to 61 on 10.10, but none worked so I gave up. I see others have 250 in the web, so I'm assuming that is no longer an issue....

On 11-04-15 07:28 AM, Greg Hormann wrote: > This is exactly myth related, but it is such a knowledgeable community.... > > I just seem to have no luck with LIRC blasting. I have an HD-PVR and > initially setup HD-PVR to perform the blasting via lirc_zilog. > (Followed the procedure outlined in > http://www.mythtv.org/wiki/Hauppauge_HD-PVR#HD-PVR_Driver_Compilation_Howto). > Unfortunately, the HD-PVR would lockup after a while with the > lirc_zilog loaded. With the module unloaded, it seems fine. (Too > bad, because ir blasting and the remote seemed to work fine!) > > I then tried to configure using serial port. I copied over the > lircd.conf file from the old server, setup hardware.conf and restarted > the service. The lirc_serial module seems to correctly load, but the > it doesn't change the channels. (Unfortunately this blaster doesn't > light up like the HD_PVR, so I can't see if a signal is actually being > sent, but if I plug it back into the old mythserver it still works..) > > I found some notes suggesting there were some issues with serial > blasting in October and early January. > > https://bugzilla.redhat.com/show_bug.cgi?id=658600> http://www.gossamer-threads.com/lists/mythtv/users/455608?do=post_view_threaded#455608

The lirc_serial in many kernels was never tested before release, and has a nasty bug that prevents it from working. Fortunately, the fix is rather simple:

Note that there are also memory leaks in those same b0rked versions of lirc_serial and pals, and there is a more comprehensive patch available to take care of those as well as the fix above. _______________________________________________ mythtv-users mailing list mythtv-users [at] mythtv http://www.mythtv.org/mailman/listinfo/mythtv-users

> On 11-04-15 07:28 AM, Greg Hormann wrote: >> This is exactly myth related, but it is such a knowledgeable community.... >> >> I just seem to have no luck with LIRC blasting. I have an HD-PVR and >> initially setup HD-PVR to perform the blasting via lirc_zilog. >> (Followed the procedure outlined in >> http://www.mythtv.org/wiki/Hauppauge_HD-PVR#HD-PVR_Driver_Compilation_Howto). >> Unfortunately, the HD-PVR would lockup after a while with the >> lirc_zilog loaded. With the module unloaded, it seems fine. (Too >> bad, because ir blasting and the remote seemed to work fine!) >> >> I then tried to configure using serial port. I copied over the >> lircd.conf file from the old server, setup hardware.conf and restarted >> the service. The lirc_serial module seems to correctly load, but the >> it doesn't change the channels. (Unfortunately this blaster doesn't >> light up like the HD_PVR, so I can't see if a signal is actually being >> sent, but if I plug it back into the old mythserver it still works..) >> >> I found some notes suggesting there were some issues with serial >> blasting in October and early January. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=658600>> http://www.gossamer-threads.com/lists/mythtv/users/455608?do=post_view_threaded#455608> > The lirc_serial in many kernels was never tested before release, > and has a nasty bug that prevents it from working.

Receive was tested and worked just fine, only transmit was broken. This was fixed upstream ~3 months ago.

> If that fix is not already in Ubuntu-10.10, then you should probably > pursue the Ubuntu kernel maintainers and try to get it added there.

Good luck, I tried pushing fixes to them several months ago for some of the many issues their shipping imon driver has. Unless the fixes came in via the -stable tree, it didn't meet their stable update release criteria, or something like that. Since the imon bits in the Ubuntu kernel were acquired via a backport, there's no corresponding stable tree bits. Same thing for lirc_serial.

My suggestion for anyone running Ubuntu that is experiencing IR driver issues is to go this route:

On 11-04-15 07:28 AM, Greg Hormann wrote: .. > I then tried to configure using serial port. I copied over the > lircd.conf file from the old server, setup hardware.conf and restarted > the service. The lirc_serial module seems to correctly load, but the > it doesn't change the channels. (Unfortunately this blaster doesn't > light up like the HD_PVR, so I can't see if a signal is actually being > sent, but if I plug it back into the old mythserver it still works..)

I didn't break it, but I can fix it.

Grab this tarball, unpack it, and use "make clean install". Then reboot. Presto, working lirc_serial blaster.

Mind you, it only works as well as the code therein. I find it to be rather spotty when run on a busy mythtv system. Sometimes it works, sometimes it only partially works, depending upon how busy the rest of the system is.

Someday I really ought to write a proper implementation for this thing, except I don't actually need/use it myself.

> On 11-04-15 07:28 AM, Greg Hormann wrote: > .. >> I then tried to configure using serial port. I copied over the >> lircd.conf file from the old server, setup hardware.conf and restarted >> the service. The lirc_serial module seems to correctly load, but the >> it doesn't change the channels. (Unfortunately this blaster doesn't >> light up like the HD_PVR, so I can't see if a signal is actually being >> sent, but if I plug it back into the old mythserver it still works..) > > I didn't break it, but I can fix it. > > Grab this tarball, unpack it, and use "make clean install". > Then reboot. Presto, working lirc_serial blaster. > > http://rtr.ca/lirc_serial_fixed.tar.gz> > Mind you, it only works as well as the code therein. > I find it to be rather spotty when run on a busy mythtv system. > Sometimes it works, sometimes it only partially works, > depending upon how busy the rest of the system is. > > Someday I really ought to write a proper implementation for this thing, > except I don't actually need/use it myself.

Yeah, it needs a significant rewrite if its ever going to get out of staging, but I don't know that anyone really wants to touch it badly enough to make it happen. Its by far my least favorite IR driver that any significant number of people use. (I have even more disdain for lirc_parallel and lirc_sir, but very few people actually use those).

> This is exactly myth related, but it is such a knowledgeable community.... > > I just seem to have no luck with LIRC blasting. I have an HD-PVR and > initially setup HD-PVR to perform the blasting via lirc_zilog. > (Followed the procedure outlined in > http://www.mythtv.org/wiki/Hauppauge_HD-PVR#HD-PVR_Driver_Compilation_Howto> ). > Unfortunately, the HD-PVR would lockup after a while with the > lirc_zilog loaded. With the module unloaded, it seems fine. (Too > bad, because ir blasting and the remote seemed to work fine!) > > I had luck on 10.04 (LTS) installing an 2.6.38 kernel from some kind of ppa backport and using the lirc_zilog with a module option to only do transmit. I did not update lirc.

The 2.6.38 upgrade was required just to get the never version hd-pvr working.

The transmit only module option removed the errors from dmesg and I have been running this way for over 3 weeks with no errors or missed changes.

On Fri, Apr 15, 2011 at 10:59 AM, Jarod Wilson <jarod [at] wilsonet> wrote: >> If that fix is not already in Ubuntu-10.10, then you should probably >> pursue the Ubuntu kernel maintainers and try to get it added there. > > Good luck, I tried pushing fixes to them several months ago for some > of the many issues their shipping imon driver has. Unless the fixes > came in via the -stable tree, it didn't meet their stable update > release criteria, or something like that. Since the imon bits in the > Ubuntu kernel were acquired via a backport, there's no corresponding > stable tree bits. Same thing for lirc_serial.

Jarod has *way* more influence than I'll ever have, so we'll consider me pushing them a non starter. :-)

On 11-04-15 11:29 AM, Jarod Wilson wrote: > On Apr 15, 2011, at 11:24 AM, Mark Lord wrote: > >> Grab this tarball, unpack it, and use "make clean install". >> Then reboot. Presto, working lirc_serial blaster. >> >> http://rtr.ca/lirc_serial_fixed.tar.gz>> >> Mind you, it only works as well as the code therein. >> I find it to be rather spotty when run on a busy mythtv system. >> Sometimes it works, sometimes it only partially works, >> depending upon how busy the rest of the system is. >> >> Someday I really ought to write a proper implementation for this thing, >> except I don't actually need/use it myself. > > Yeah, it needs a significant rewrite if its ever going to get out > of staging, but I don't know that anyone really wants to touch it > badly enough to make it happen. Its by far my least favorite IR > driver that any significant number of people use. (I have even > more disdain for lirc_parallel and lirc_sir, but very few people > actually use those).

That's a bit of a shame, really, because it is by far the most economical and least-wasteful method for adding an IR-Blaster.

What it needs to work properly, is a way to pass in the whole channel change sequence in one go. Then the in-kernel part can clock the whole thing out in (soft) real-time with pretty decent reliability.

But at present, each digit is a whole new kernel system call, and the scheduling delays back at the original script/app just kill any attempt at reliable timing. Except when the system is idle.

On 04/15/2011 11:24 AM, Mark Lord wrote: > On 11-04-15 07:28 AM, Greg Hormann wrote: > .. >> I then tried to configure using serial port. I copied over the >> lircd.conf file from the old server, setup hardware.conf and restarted >> the service. The lirc_serial module seems to correctly load, but the >> it doesn't change the channels. (Unfortunately this blaster doesn't >> light up like the HD_PVR, so I can't see if a signal is actually being >> sent, but if I plug it back into the old mythserver it still works..) > I didn't break it, but I can fix it. > > Grab this tarball, unpack it, and use "make clean install". > Then reboot. Presto, working lirc_serial blaster. > > http://rtr.ca/lirc_serial_fixed.tar.gz> > Mind you, it only works as well as the code therein. > I find it to be rather spotty when run on a busy mythtv system. > Sometimes it works, sometimes it only partially works, > depending upon how busy the rest of the system is. > > Someday I really ought to write a proper implementation for this thing, > except I don't actually need/use it myself. > I just tried this because I can't get the lirc module to see my available serial port. Everything was working fine until I upgraded to 2.6.38. I also use the v4l git (media_build). I get this error: [ 24.867152] lirc_serial: disagrees about version of symbol lirc_register_driver [ 24.867159] lirc_serial: Unknown symbol lirc_register_driver (err -22) [ 24.873145] lirc_serial: disagrees about version of symbol lirc_register_driver

If the driver in v4l it consistently says my serial port is busy and run setserial - and yes, I run setserial to diable the uart.

On 11-04-15 11:49 AM, mlists wrote: > On 04/15/2011 11:24 AM, Mark Lord wrote: >> On 11-04-15 07:28 AM, Greg Hormann wrote: >> .. >>> I then tried to configure using serial port. I copied over the >>> lircd.conf file from the old server, setup hardware.conf and restarted >>> the service. The lirc_serial module seems to correctly load, but the >>> it doesn't change the channels. (Unfortunately this blaster doesn't >>> light up like the HD_PVR, so I can't see if a signal is actually being >>> sent, but if I plug it back into the old mythserver it still works..) >> I didn't break it, but I can fix it. >> >> Grab this tarball, unpack it, and use "make clean install". >> Then reboot. Presto, working lirc_serial blaster. >> >> http://rtr.ca/lirc_serial_fixed.tar.gz>> >> Mind you, it only works as well as the code therein. >> I find it to be rather spotty when run on a busy mythtv system. >> Sometimes it works, sometimes it only partially works, >> depending upon how busy the rest of the system is. >> >> Someday I really ought to write a proper implementation for this thing, >> except I don't actually need/use it myself. >> > I just tried this because I can't get the lirc module to see my > available serial port. Everything was working fine until I upgraded to > 2.6.38. I also use the v4l git (media_build). I get this error: > [ 24.867152] lirc_serial: disagrees about version of symbol > lirc_register_driver > [ 24.867159] lirc_serial: Unknown symbol lirc_register_driver (err -22) > [ 24.873145] lirc_serial: disagrees about version of symbol > lirc_register_driver

On 11-04-15 11:55 AM, Mark Lord wrote: > On 11-04-15 11:49 AM, mlists wrote: >> On 04/15/2011 11:24 AM, Mark Lord wrote: >>> On 11-04-15 07:28 AM, Greg Hormann wrote: >>> .. >>>> I then tried to configure using serial port. I copied over the >>>> lircd.conf file from the old server, setup hardware.conf and restarted >>>> the service. The lirc_serial module seems to correctly load, but the >>>> it doesn't change the channels. (Unfortunately this blaster doesn't >>>> light up like the HD_PVR, so I can't see if a signal is actually being >>>> sent, but if I plug it back into the old mythserver it still works..) >>> I didn't break it, but I can fix it. >>> >>> Grab this tarball, unpack it, and use "make clean install". >>> Then reboot. Presto, working lirc_serial blaster. >>> >>> http://rtr.ca/lirc_serial_fixed.tar.gz>>> >>> Mind you, it only works as well as the code therein. >>> I find it to be rather spotty when run on a busy mythtv system. >>> Sometimes it works, sometimes it only partially works, >>> depending upon how busy the rest of the system is. >>> >>> Someday I really ought to write a proper implementation for this thing, >>> except I don't actually need/use it myself. >>> >> I just tried this because I can't get the lirc module to see my >> available serial port. Everything was working fine until I upgraded to >> 2.6.38. I also use the v4l git (media_build). I get this error: >> [ 24.867152] lirc_serial: disagrees about version of symbol >> lirc_register_driver >> [ 24.867159] lirc_serial: Unknown symbol lirc_register_driver (err -22) >> [ 24.873145] lirc_serial: disagrees about version of symbol >> lirc_register_driver > > make clean ; make install ; reboot

Oh, I know what's going on.. the v4l snapshot installed its copy of lirc_serial.ko in a different location from the default for ubuntu. So your system is getting a bit confused there by all of that.

I can't help much with systems that replace the in-kernel drivers with the v4l snapshots -- too many variables for me to guess and deal with.

So just remove the lirc_serial.ko file from the system: rm /lib/modules/`uname -r`/kernel/drivers/staging/lirc/lirc_serial.ko and then rebuild/reinstall your v4l snapshot drivers again.

* * *

The "always busy" serial port bug in v4l/lirc (dunno which) is also something I remember seeing once. I had to hack lirc source code to remove the offending "O_EXCL" flag from something.

I don't use LIRC, lirc_serial, or the v4l sources here, so I can't help with those.

> On Fri, Apr 15, 2011 at 10:59 AM, Jarod Wilson <jarod [at] wilsonet> wrote: >>> If that fix is not already in Ubuntu-10.10, then you should probably >>> pursue the Ubuntu kernel maintainers and try to get it added there. >> >> Good luck, I tried pushing fixes to them several months ago for some >> of the many issues their shipping imon driver has. Unless the fixes >> came in via the -stable tree, it didn't meet their stable update >> release criteria, or something like that. Since the imon bits in the >> Ubuntu kernel were acquired via a backport, there's no corresponding >> stable tree bits. Same thing for lirc_serial. > > Jarod has *way* more influence than I'll ever have, so we'll consider > me pushing them a non starter. :-)

Well, if its *just* a small patch for lirc_serial, it might have a better shot than the much more involved imon fixes I asked them to take in. Then again, Ubuntu 11.04 ought to be released Real Soon Now, and should have a fully functional lirc_serial. Or not. It looks like that fix went in post-2.6.37, and 11.04 is shipping with a 2.6.37.x-based kernel. So it would seem a 2.6.37.x stable tree backport of that patch is probably in order. Sigh. I think there are probably a few others I should send to the 37 stable tree to head off another 6 months of already-fixed IR issue reports from Ubuntu users...

On Fri, Apr 15, 2011 at 1:47 PM, Jarod Wilson <jarod [at] wilsonet> wrote: >>> My suggestion for anyone running Ubuntu that is experiencing IR driver >>> issues is to go this route: >>> >>> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers>> >> Um. I'll have to play with this some more. I tried it a few weeks >> ago, but ended up with a build failure that didn't appear to be >> firedtv related. I'll spend some more time on it this time... > > Its occasionally a losing battle keeping all the latest media tree > code compiling on older kernels. Report build failures to > linux-media [at] vger and we'll try to get them fixed and/or > offer work-arounds. >

With a little bit of work, I did get it installed. But unfortunately it still locks up after just a few recordings.

Running (Still an issue) ----------------------------------- Light testing seemed good, but the hd-pvr stil locked up after a few channel changes with back-to-back recoding scheduled. Infact, it looks like it was throwing errors much of the the time, I just didn't notice.

On Fri, Apr 15, 2011 at 1:47 PM, Jarod Wilson <jarod [at] wilsonet> wrote: > Well, if its *just* a small patch for lirc_serial, it might have a > better shot than the much more involved imon fixes I asked them to > take in. Then again, Ubuntu 11.04 ought to be released Real Soon > Now, and should have a fully functional lirc_serial. Or not. It > looks like that fix went in post-2.6.37, and 11.04 is shipping with > a 2.6.37.x-based kernel. So it would seem a 2.6.37.x stable tree > backport of that patch is probably in order. Sigh. I think there > are probably a few others I should send to the 37 stable tree to > head off another 6 months of already-fixed IR issue reports from > Ubuntu users... >

I also tried the latest lirc_serial.ko via media build. Found another "common" error. Googling doesn't provide a solution that appears to work for my situation. There are some new messages in dmesg, but I thought they might just be debugging code.

#Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false"

#Try to load appropriate kernel modules LOAD_MODULES="true"

# Default configuration files for your hardware if any LIRCMD_CONF=""

#Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""

> On Fri, Apr 15, 2011 at 1:47 PM, Jarod Wilson <jarod [at] wilsonet> wrote: >> Well, if its *just* a small patch for lirc_serial, it might have a >> better shot than the much more involved imon fixes I asked them to >> take in. Then again, Ubuntu 11.04 ought to be released Real Soon >> Now, and should have a fully functional lirc_serial. Or not. It >> looks like that fix went in post-2.6.37, and 11.04 is shipping with >> a 2.6.37.x-based kernel. So it would seem a 2.6.37.x stable tree >> backport of that patch is probably in order. Sigh. I think there >> are probably a few others I should send to the 37 stable tree to >> head off another 6 months of already-fixed IR issue reports from >> Ubuntu users... >> > > I also tried the latest lirc_serial.ko via media build. Found another > "common" error. Googling doesn't provide a solution that appears to > work for my situation. There are some new messages in dmesg, but I > thought they might just be debugging code. > > ghormann [at] tvServe:/usr/local/bin$ sudo ./change_sa_chan.sh 123 > irsend: command failed: SEND_ONCE SA4250 1 > irsend: hardware does not support sending > irsend: command failed: SEND_ONCE SA4250 2 > irsend: hardware does not support sending > irsend: command failed: SEND_ONCE SA4250 3

If you enabled it building the same way you did lirc_zilog, but didn't add CONFIG_LIRC_SERIAL_TRANSMITTER=y, then you probably only built it with RX support.

I forgot to mention that if you want to build the lirc staging bits, you need to do a 'make stagingconfig' in the root of the media_build source, which should have taken care of that automatically, I think. However, I don't know why we don't just always build in TX support, I should remove that config option...

On Sat, Apr 16, 2011 at 2:04 PM, Jarod Wilson <jarod [at] wilsonet> wrote: > If you enabled it building the same way you did lirc_zilog, but didn't > add CONFIG_LIRC_SERIAL_TRANSMITTER=y, then you probably only built it > with RX support. > > I forgot to mention that if you want to build the lirc staging bits, you > need to do a 'make stagingconfig' in the root of the media_build source, > which should have taken care of that automatically, I think. However, I > don't know why we don't just always build in TX support, I should remove > that config option... >

Actually I did both (with =m) to the .config file That should work right? I *did not* run stagingconfig ghormann [at] tvServe:~/mythtv_source/hd-pvr-driver/v4l-dvb-backport/media_build/v4l$ grep SERIAL .config CONFIG_LIRC_SERIAL_TRANSMITTER=m CONFIG_LIRC_SERIAL=m

I'm running a test right now with options lirc_zilog tx_only=1 as David suggested. No problems after 4 shows being required (even switching between resolutions). That is the most stable hd-pvr has ever been as a transmission device. I also just started playing with an MCE Remote. Hopefully I can get that stable too. (Right now, it seems to be configured as a keyboard by some other module, instead of via LIRC. Time for more google searches!)

On 11-04-16 02:00 PM, Jarod Wilson wrote: > On Apr 15, 2011, at 11:01 PM, f-myth-users [at] media wrote: > >>> Date: Fri, 15 Apr 2011 13:47:16 -0400 >>> From: Jarod Wilson <jarod [at] wilsonet> >> >>> looks like that fix went in post-2.6.37, and 11.04 is shipping with >>> a 2.6.37.x-based kernel. >> >> No it's not. Current 11.04 is already 2.6.38-8, which I'm running on >> an experimental basis on a test machine here. > > Ah, so it is. Good. So the state of IR should actually be pretty sane > for the next 6 months. > >> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html> > Its a travesty that something like that is required to figure out what > upstream kernel a given ubuntu kernel is actually based on...

Actually, as far as mainstream distros go, that's pretty good. Just try figuring out a Redhat kernel.. sure there's a major version number (like 2.6.32), but the subsystems inside could be from completely different major versions. And then there's all of those patches mashed together into a single source blob..

(I presume they don't want to call it the same thing, since they make their own mods, but I also presume they have a reason for not just appending "-ubuntuN" to it or something. How does RH do it?) _______________________________________________ mythtv-users mailing list mythtv-users [at] mythtv http://www.mythtv.org/mailman/listinfo/mythtv-users

On 04/16/2011 02:39 PM, Greg Hormann wrote: > On Sat, Apr 16, 2011 at 2:04 PM, Jarod Wilson<jarod [at] wilsonet> wrote: >> If you enabled it building the same way you did lirc_zilog, but didn't >> add CONFIG_LIRC_SERIAL_TRANSMITTER=y, then you probably only built it >> with RX support. >> >> I forgot to mention that if you want to build the lirc staging bits, you >> need to do a 'make stagingconfig' in the root of the media_build source, >> which should have taken care of that automatically, I think. However, I >> don't know why we don't just always build in TX support, I should remove >> that config option... >> > Actually I did both (with =m) to the .config file That should work > right? I *did not* run stagingconfig > ghormann [at] tvServe:~/mythtv_source/hd-pvr-driver/v4l-dvb-backport/media_build/v4l$ > grep SERIAL .config > CONFIG_LIRC_SERIAL_TRANSMITTER=m > CONFIG_LIRC_SERIAL=m > > I'm running a test right now with options lirc_zilog tx_only=1 as > David suggested. No problems after 4 shows being required (even > switching between resolutions). That is the most stable hd-pvr has > ever been as a transmission device. I also just started playing with > an MCE Remote. Hopefully I can get that stable too. (Right now, it > seems to be configured as a keyboard by some other module, instead of > via LIRC. Time for more google searches!) > > Thanks again for all the assistance!

Well, I didn't run make stagingconfig either and that actually resolved my issue with the lirc_serial module and 2.6.38 kernel on Ubuntu 10.10.

On Sat, Apr 16, 2011 at 11:35 AM, David Linville <dlinvill [at] networksdown> wrote: > I avoided these errors and the failed recordings by adding the following > parameter to the lirc_zilog module. This worked since I was only using the > hd-pvr to send IR to the cable box. > > options lirc_zilog tx_only=1 > Thanks to Jarod, David, Mark and others. My system seems stable now using an HD-PVR (with blaster) and a MCE remote. (I never got back to testing the serial fix, and since it is "working" I'm not going to mess with it.) I've attempted to contribute some of my learnings back to the MythTV wiki.

> On 11-04-16 02:00 PM, Jarod Wilson wrote: >> On Apr 15, 2011, at 11:01 PM, f-myth-users [at] media wrote: >> >>>> Date: Fri, 15 Apr 2011 13:47:16 -0400 >>>> From: Jarod Wilson <jarod [at] wilsonet> >>> >>>> looks like that fix went in post-2.6.37, and 11.04 is shipping with >>>> a 2.6.37.x-based kernel. >>> >>> No it's not. Current 11.04 is already 2.6.38-8, which I'm running on >>> an experimental basis on a test machine here. >> >> Ah, so it is. Good. So the state of IR should actually be pretty sane >> for the next 6 months. >> >>> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html>> >> Its a travesty that something like that is required to figure out what >> upstream kernel a given ubuntu kernel is actually based on... > > Actually, as far as mainstream distros go, that's pretty good.

No, actually, its not. :)

> Just try figuring out a Redhat kernel.. sure there's a major > version number (like 2.6.32), but the subsystems inside could be > from completely different major versions. And then there's all > of those patches mashed together into a single source blob..

The Red Hat Enterprise Linux 6 kernel *is* in fact based upon an upstream 2.6.32 kernel. But there are thousands of patches on top of that. And a 10-year life cycle with a stable kernel ABI promise. Features get backported from newer kernels. Entire subsystems get updated. But its never claimed that its anything close to being an upstream kernel. Its a very different situation from a rolling release community distribution. Try looking at Fedora instead. :)

Where it gets more interesting, current rawhide kernel: kernel-2.6.39-0.rc3.git2.0.fc16 ==> upstream 2.6.39-rc3-git2 kernel

>From either package name or uname -r output alone, you can tell exactly what upstream kernel, including git and rc snapshot kernels, the Fedora kernel is based upon. No lookup table required. Its been that way since mid-2007 and kernel 2.6.22.

> On Sat, Apr 16, 2011 at 2:04 PM, Jarod Wilson <jarod [at] wilsonet> wrote: >> If you enabled it building the same way you did lirc_zilog, but didn't >> add CONFIG_LIRC_SERIAL_TRANSMITTER=y, then you probably only built it >> with RX support. >> >> I forgot to mention that if you want to build the lirc staging bits, you >> need to do a 'make stagingconfig' in the root of the media_build source, >> which should have taken care of that automatically, I think. However, I >> don't know why we don't just always build in TX support, I should remove >> that config option... >> > > Actually I did both (with =m) to the .config file That should work > right? I *did not* run stagingconfig > ghormann [at] tvServe:~/mythtv_source/hd-pvr-driver/v4l-dvb-backport/media_build/v4l$ > grep SERIAL .config > CONFIG_LIRC_SERIAL_TRANSMITTER=m > CONFIG_LIRC_SERIAL=m > > I'm running a test right now with options lirc_zilog tx_only=1 as > David suggested. No problems after 4 shows being required (even > switching between resolutions). That is the most stable hd-pvr has > ever been as a transmission device. I also just started playing with > an MCE Remote. Hopefully I can get that stable too. (Right now, it > seems to be configured as a keyboard by some other module, instead of > via LIRC. Time for more google searches!)

CONFIG_LIRC_SERIAL_TRANSMITTER isn't a tristate, its boolean, so a value of m is undefined. However, it looks like its default state is y when CONFIG_LIRC_SERIAL is enabled. Hrm. Not sure what's going on there.