[mythtv-users] IRBlaster Progress; more questions

Shawn Asmussen asmussen at cox.net
Mon Jul 26 13:09:43 EDT 2004


> This is a continuation of the issue at
>
> http://www.gossamer-threads.com/lists/mythtv/users/77728?search_string=remoted;#77728
>
> Sorry for starting a new thread ... I just accidentally lost my mail
> from the last week or so, so I can't just reply to the existing message.
> --------
> Thanks to Mike for the response! That lead me to make some progress.
> remoted was not running, although I had been starting it in
> /etc/init.d/local with the following lines:
>
> echo "Starting remoted ..."
> setserial /dev/ttyS1 uart none
> /sbin/modprobe remote_sir
> /usr/local/sbin/remoted
>
> I think whenever I ran channel_change.sh, remoted crashed! Because when
> I looked for it with ps ax|grep remoted, it was never there.
>
> What's interesting, and I think is progress, is that when I commented
> those lines in /etc/init.d/local, but ran them from an xterm,
> channel_change.sh started working (I think--but I have a Scientific
> Atlanta 2100, which I see now is kind of a problem child). At least, I
> got no errors and I could see the LED's on the IR Blaster flashing.
>
> So I think I'm having the issue where remoted can't connect to the X
> socket, as in
>
> http://www.gossamer-threads.com/lists/mythtv/users/27190
>
> because when it starts that X socket is not there, or different from the
> one that's running after mythtv logs in and everything starts up. Can I
> fix this somehow? Unforunately, in the above posting the discussion was
> not carried through to a solution.

I am skeptical about it being an X issue. The lirc programs to the best of
my knowledge do not require X, and should function even if X isn't running
at all. To see why remoted is crashing, you might try using strace to
follow what it's doing. Note the PID of the remoted process, and then run
an 'strace -p <PID>' on that PID. Then, in another window/VT, try your
change channel script. Then, if remoted dies, you can switch back to your
strace window and possibly get an idea of what was going on when the
process crashed.

If it doesn't work correctly when started from /etc/init.d/local, but does
work when started from an xterm, I would suspect something like an
environment variable issue, or something else along those lines where the
conditions might be different because you're running it from an
interactive session. Do the kernel messages generated when the module
loads look the same in both cases? When you're running it from an xterm,
are you doing it as the root user? Are there any errors generated in any
of the log files in /var/log? (Both the messages file, and remoted's log
file, although if I remember correctly, the lirc log file isn't usually
very descriptive) When you tried setting the permissions on /dev/remoted,
at what point during the process were you doing it? Before starting
remoted? If you actually ls -l the /dev/remoted socket before trying the
change channel script, do the permissons look the same in both cases?

To eliminate X as the cause of the difference for certain, you can shut
down X entirely by switching to a different runlevel, and then try
starting it up from a text console instead of an xterm. If that works,
then X is definately not the factor that is making the difference.

Shawn Asmussen


More information about the mythtv-users mailing list