Linux & IR Blasters

[Doubletop]

I am considering a switch from Windows to Linux and before I rip everything apart I'm going through the list of components of my system not directly part of SageTV to see if it will all hang together again. (it was a problem when I went through this the last time)

As I'm currently using and exetuner, Girder, UIRT2 combination to drive my STB. I know none of this is supported but can you please confirm the status of the Linux version.

Firstly is there an exetuner or equivalent included?
What are the supported devices USB-UIRT etc?
Is LIRC the solution for STB control or is LIRC only about controlling applications? (Which would make it redundant I assume in my case as I am using a PVR350 with its remote, which I believe uses ivtv)
If LIRC is the answer is it supported by the SageTV interface to replace exetuner?

From what I see there is only one other post on the subject of STB control and that branched off discussing firewire interfaces which many of us won’t have.

Hope you can clarify

[m4tth3wv]

In my setup, I'm using the IR Blaster on the PVR150 card with ivtv drivers/firmware.

This appeared to be the only supported method of controlling a cable box via IR blaster.

[Doubletop]

Thanks for the reply I don't think my 350 has the IR blaster like your 150.

I was sort of hoping for a definitive reply from Narflex, Opus4, dkardatzke et al so we all could understand what the Linux version supported

[Narflex]

On Linux we only support the PVR150's blaster and also serial control of DirecTV receivers.

There's also an LIRC plugin I wrote a few years ago which you could try. We didn't pursue it because we found LIRC to be too unreliable and didn't want to deal with the support hassle for that. I'll attach it here.

[harrijay]

I am trying this out plugin out to see if this could work for me. I am getting stuck trying to configure it. All it will allow me to do is just add a device but it will not learn the command or anything. I have all of the buttons for the remote in a file now how do I get sage to use them?

[harrijay]

I know you did not intend on having any support for this plugin but if it is possible I would be willing to make changes to it and update as needed if I could get the code for this This is really the last thing to make the linux version equivalent to the windows version for me.

[Narflex]

Originally Posted by harrijay

I know you did not intend on having any support for this plugin but if it is possible I would be willing to make changes to it and update as needed if I could get the code for this This is really the last thing to make the linux version equivalent to the windows version for me.

Send an email to betatest at sagetv dot com and we can supply you with the source to that plugin.

[stuckless]

I just wanted to document the fact the I have Sage IR blasting using Lirc via Narflex's LIRCTuner. It's probably not in heavy demand, but if someone is searching for it, hopefully they will stumble upon this article.

The .so posted here didn't work, but as per Narflex's advice, I wrote to the Sage folks, and they promptly provided me with the source code. It only took a couple of minutes to see what the real problem was.... the .so was looking for the lircd device in /dev/remoted and my Ubuntu lirc install puts the device as /dev/lircd.

I also changed another piece of code in the plugin where it was telling the remote codes to repeat twice for each code. I removed the repeat var and let it only push each code once, and it works well.

As for Lirc, this is the first time in years that I must say I was impressed with the Lirc install. In Ubuntu 8.04, the Lirc package install asked me for my remote type, and whether or not I was blasting, and what my reciever was... after selecting all the appropriate answers, Lirc just worked. No manual package rebuilds or fussing with remote codes, etc.

When I put the LIRCTuner.so in the irtunerplugins dir I was a little confused because I didn't a "LIRC" entry but a USB-UIRT entry. After looking at the code, I realized that this was what Sage called the LIRCTuner. I changed USB-UIRT to LIRC (You can use USB-UIRT with Lirc, at least I saw a module for it in the lirc setup)

I don't know if Sage will allow me to post the modified LIRCTuner.so here, but if you want it, you can PM me. As for the source, you'll have to ask Sage, and I was greatful that they provided it, because it only took a few minutes to make it all work.

After seeing the code for the LIRCTuner, it's a fairly simple interface to implement a Sage IR Tuner plugin. I considered modifying it to create a External Command Tuner plugin where you could provide an external command to change the channels. But since I got the actual Lirc Tuner plugin to work, there was no need for that.

[Narflex]

Feel free to post your work here. It'd be a good idea to post it in the Downloads area as well. Thanks.

[stuckless]

I uploaded the modified LIRCTuner.so. The direct link to it is here

[bcjenkins]

Is the plugin you've compiled only good for the dev path you specified? My path is /dev/lirc0,1,2 (using 3 HVR-1600s)

B

[stuckless]

It is configured for a single /dev/lircd path. This is the communication socket that the plugin uses to communicate with Lirc. The /dev/lirc[0-2] refers to the physical devices, which are configured and used by lircd in /etc/lirc/hardware.conf.

So in your case, this plugin should still work, since the plugin knows nothing about /dev/lirc[0-2] but only knows about the socket device.

One of the calls in the Tuner Plugin api is a "LoadRemotes" which returns the remotes that are configured. In reviewing the code, it appears that this code queries lirc (via the /dev/lircd socket) and gets back the remotes that are configured by Lirc itself.

I would check you llirc installation... you should have a /dev/lircd file socket as long as the lirc daemon is running. (Under ubuntu it will be there)

If it turns out that your lircd file file is NOT /dev/lircd, then let me know and I can either... rebuild a specific version for you... or add in a configuration section that would allow the lirc socket to be configurable. (I didn't do the latter because it would have required more work than I was willing to do at the time )

[bcjenkins]

Would you mind building plugins for devices: /dev/lircd /dev/lircd1 /dev/lircd2 ? The lircd can only connect to one device. I had to run multiple instances:

/usr/local/sbin/lircd --device=/dev/lirc0 --output=/dev/lircd
/usr/local/sbin/lircd --driver=default --device=/dev/lirc1 --output=/dev/lircd1 --pidfile=/var/run/lircd1.pid 
/usr/local/sbin/lircd --driver=default --device=/dev/lirc2 --output=/dev/lircd2 --pidfile=/var/run/lircd2.pid

Thanks in advance.

B

[stuckless]

Sure.... I'll do it tomorrow (sunday)... It's a little late right now.. spent all day with the inlaws I'll put up a post when it's done.

[stuckless]

Would you mind building plugins for devices: /dev/lircd /dev/lircd1 /dev/lircd2 ?

You can download them from the download section.

[bcjenkins]

Thanks for doing that. I was unable to get my HVR-1600 blasters working. I think it is due to the fact that I am using cx18 and not ivtv and the pvr150 patch was written for ivtv.

Reference:

http://www.blushingpenguin.com/mark/blog/?p=24

Patch:

http://www.blushingpenguin.com/mark/...pvr150-2.patch

I have no idea if I can just go in and replace all ivtv instances for cx18 or not.

B

Meanwhile - I am trying to figure out how to use my iguanaIR for multiples. It does not seem to function the same. Instead of devices, there are channels/zones within each device.

EDIT - The command seems to be

irsend SET_TRANSMITTERS 1 && irsend SEND_ONCE DCT2000 power

So how does that translate?

[stuckless]

The existing source code does not take into account for ir blasters with multiple transmitters. I only have a single blaster, I've never run into this issue. It probably wouldn't be hard to modify the code to add the "SET_TRANSMITTERS 1" command before the "SEND_ONCE" command, but I would have no way of testing this. Let me know if you want me to make some changes... i don't mind, but if you want to do it yourself, just request the source code from support.

[bcjenkins]

How about a plugin which can pass the following to a bash script?

Usage: $0 REMOTE_NAME TRANSMITTER_NUM (CHANNEL_NUMBER | IR_COMMAND) [DELAY]

Options
REMOTE_NAME the name of one of your remotes
TRANSMITTER_NUM the emitter number attached to the REMOTE_NAME device (1-16)
CHANNEL_NUMBER the channel number to send
IR_COMMAND any IR command on REMOTE_NAME that is not a number
DELAY time to wait beween IR commands (default 0.2s)

This is from the commandIR site.

B

PS Aside from scripting, I get lost.

[stuckless]

There are a couple of problems with provide that type of plugin. First, Sage only provides REMOTE_NAME and CHANNEL_NUMBER, so there would be no way of providing TRANMITTER_NUM. The second problem is that the Tuner plugin gets it's list of REMOTE_NAMEs from the Tuner implementation. So if you had a Tuner plugin that called a script, you would also need to have that script be able to return a list of REMOTE_NAMEs as well. All in all , it gets a little complicated

Another issue has to do with configurations. There is no way that a given instance of a TunerPlugin.so can know about a specific configuration. So, if you had an command based tuner, there is no where to store the command to call, so it would have to be hard coded. If it's hard coded, and you copy the .so to a new filename so that sage will now now see 2 command tuner plugins, then they both will call the same command.

I may send sage support an email requesting if there is a way to store tuner configuration with a plugin instance. If so, then that would simplify the configuration problems.

In the meantime, do you want me to build a version the LIRCTuner plugin that will set the transmitter? If so, then let me know the tranmitter, and lirc device, and I can quickly put together a plugin that does that for you.

[stuckless]

With the permission of Narflex, the LIRCTuner plugin now includes it's full source and Makefile. It should be trivial for anyone to rebuild it under Linux.