Nope, still nothing.

I may just get desperate and whack the hard drive and try mythdora and see if I make out any better.

Strange... I installed KnoppMyth in a PC emulator on my Mac and it recognized the streamzap remote without any trouble. I copied its lirc config files over to my ubuntu mythbox and rebooted, but that didn't change anything.

Add me to the list of users with this problem. The frustrating thing is that it works great on my FE/BE machine with no problems (both running R5E50). On my new FE, I can't get the Streamzap or my Hauppauge dog-bone remotes to work...

Chris

Well I got my Streamzap remote working. I sure hope this works for everyone else.

I tried to debug using "irw" but it would crash lircd and not allow me to do anything. So I stopped lircd and ran "lircd -n" to run without the daemon. I then ran "irw" and watched the output. It gave an error "could not get file information for /dev/lirc" and killed lircd.

I thought it odd that it was looking at /dev/lirc instead of /dev/lirc0, as that was one of the changes noted in R5E50. So I logged in as root and symlinked lirc to lirc0



And it worked!

I'm sure there is a proper way to fix this, but it will take someone with more Linux knowledge than me (I'm new to Linux)...

Chris

Does this link survive between reboots? If not, you might want to look into writing a udev rule to set the link and its permissions.

Here's what I have in /etc/udev/rules.d/90-lirc.rules on my ubuntu box:



The results:



For what it's worth anyway. Streamzap still doesn't work. From digging around in knoppmyth, it looks like it uses a different rule that accomplishes a similar thing. Minus the link, using group instead of world read/write...

I wonder if your lirc hardware.conf file needs to point to /dev/lirc0 instead of /dev/lirc.

I can confirm what cfoxga did.

At least with the irw killing lircd (there should be a stick or something in the wiki about this since they tell you to troubleshoot with irw).

I got the same error as him too.

However, the symlink did not fix it for me.

Is there any sort of log file or "trace" that can be run to see where the problem is?

From what I can tell:

a) lircd is running. I verified by typing:

and I see "lircd" on the list.

b) The streamzap receiver (USB) is working because when I type:

I see codes and pulses and spaces and all that.

So how do I tell if it's getting "beyond" that?

One thing I did notice is that the lircd.conf file says :



But this is the USB version (not sure if that makes a difference).

I'm at my wits end on this one, especially with a "just works" piece of hardware.

While I'm fighting with this, I was reading about lirc and all that.

I see:

/etc/init.d/lirc

I looked at the file and see that it basically is supposed to start TWO services:

lircmd
and
lirc

Right?

So I stopped the services.

Then I figured I would manually start them, so I looked at the "start' section (oh, by the way, the "usage" line is wrong. It says it's: /etc/init.d/lircd {start|stop|reload|restart|force-reload}" but there is no lircd file in the /init.d directory), anyway, I see that it's doing:



and



So I figured I would just start those manually but without the --quiet switch.

So I typed in:


Then I typed in:



Then it tells me there is no lircmd file or directory. If I do an ls command for /usr/sbin/li* I see a "green" lircmd (sorry I can't remember if that's a link to a file or what).

But why wouldn't it see/run it?

Is that my problem?

Not even sure what lircmd does, but the wiki says those are the two services needed.

bouncey,

You are correct about losing the setting after a reboot. So this is not a good long term solution.

hurnik,

After reading your message, I dug into /etc/init.d/lirc into more detail. I think I have a much better understanding of how this all works now. Basically, /etc/init.d/lirc executes lirc and lircmd (actually, my setup does not execute lircmd). But before running lircd, it builds up a variable $LIRCD_ARGS. This tells what DRIVER and DEVICE (in my case, "default" and "/dev/lirc0" respetcively). So I decided to try running things by hand. After a "su" to root:



I then ran "irw" and started pressing buttons. It recognized my Streamzap! I then restarted the frontend, it it also worked! NOTE: I had to restart the frontend for the remote to work...

So then I looked back in /etc/init.d/lirc at the line that hurnik quoted:



I thought it was very odd that there were no arguments being passed in to lircd. So I look at my other Myth box with a working remote:



Ah ha! That is what I expected to see: the driver and device arguments are being passed in. So I add the variable to /etc/init.d/lirc and reboot. Et voila!

I really hope this is the real fix; it sure seems like it to me (I am a linux newbie). At the very least it looks like hurnik has the same issue...
+
Chris

Actually I also see those lines in the same config file. I just went down to the "restart" section or whatever.

But it's working now after a fresh install.

My streamzap remote works fine now. The solution was to install knoppmyth instead of Ubuntu AMD64 (which is what I had been using). Yay knoppmyth!

The default key assignment in mplayer is weird though. Rewind doesn't actually rewind, it just makes the video play slower. Mplayer fwd/back controls in general aren't what I expect. But at least the hardware and software are on friendlier terms now, and the key assignments for TV playback are intuitive enough.