lots of thanks your in-depth answers!
unfortunately nothing helps it. any more hints?
"Michael T. Dean" <[EMAIL PROTECTED]> wrote:
Mark Schuren wrote:
so i think i have tried everything, replaced lirc, replaced the player
application, recompiled mythtv. but problem is still exactly the same.
so i guess it is a problem of mythfrontend...
No. Works for me.
or just a faulty configuration
Probably.
i also think so but what am i missing??
because i use the same lirc button for several actions
in different programs...?
But not for that reason--every remote button I use in xine is also
mapped to an action in Myth, and I don't have any problems.
this gives me hope. are you using a cvs myth version? i'm using the
release from mythtv.org.
again, the apps perfectly work with lirc when run stand-alone.
but when a player like xine or mplayer (i tried both) is started through
mythvideo, all lirc-buttons which i press (and which are intended to be
only received by the player - and are actually received by the player
correctly) are also received by mythfrontend, after the player quits...
Yes. This is the correct behavior for LIRC--except they should be
received /while/ the player is executing. Upon receipt of a button
press, LIRC *always* broadcasts the requested string to *all* registered
clients. It's up to the client to know when to handle it and when to
ignore it. Programs like xine always handle it. Programs like
Myth--ones that start other programs--have to decide whether to ignore it.
that's why i post my questions here, because i assumed that lirc was
behaving normally. little correction to my statement above: i found out
that it's not ALL key-presses, but SOME key-presses, read below.
is there any means to let mythfrontend ignore lircd events as
long as an external player is running?
Yeah. You just need some code like
http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/util.cpp
lines 797-799. Oh, wait. It's already there. ;)
since i am not a programmer (more a script kiddie) i don't know where
to put these lines nor what exactly they do ;-)
or do i have a "focus" problem?
No. LIRC always broadcasts to all clients, so when using MythTV's
native LIRC support, focus problems won't make any difference. If you
were using irxevent (and not native LIRC support), focus problems would
result in only one--the wrong--app receiving the button press events.
ok good. i realized that lirc is also working with my apps when
they are not in focus.
also i am still wondering if my lirc config is good:
begin
prog = mythtv
button = OFF
config = Esc
end
begin
prog = xine
button = OFF
config = Quit
end
the above means that i use the same button on my remote ("OFF") for
2 different things. it is on the one hand used to quit xine (if running),
and also used as the escape key for mythtv (if running).
That's perfectly fine. Very close to what I use.
also gives hope.
and this is what happens, if i press the "OFF" button, xine terminates
as expected, and AFTERWARDS also mythfrontend reacts and leaves the current
menu (because it also receives the "escape")...
That's the part that doesn't make sense... If it were a problem of Myth
not ignoring LIRC button press events, it should be happening while
you're watching the video--not after.
i understand, but it's happening on both of myth systems AFTER
closing the player. irxevent isn't there, see below.
maybe this is just "working
as designed" and i have to get a remote with more keys on it?
Nope. Something is wrong with your config--probably buried deep down
within...
sounds too bad. "deep" sounds like "unfindable" :-(
if i should provide any more info please let me know.
i have no more idea what to try next, please advise! is what i what to do
impossible? is anyone else using lirc buttons for more than one application
at once (esp. the mythtv/xine/mplayer combo)?
Wild guess... Do you by any chance have a player command that
backgrounds xine (i.e. ends with "&")? Perhaps the "xine" command
being executed is a script that sets up the environment and calls the
xine executable with the specified options and backgrounds the process.
no.
"# ps ax | grep xine" during play (started via myth) gives me
29413 ? SLl 0:03 xine -D -pfhq --auto-scan dvd
29420 ? Ss 0:00 xine -D -pfhq --auto-scan dvd
so no background process i guess.
What happens when you play a video through MythVideo using only your
keyboard? Do you get similar behavior?
nope. using the keyboard works perfectly fine, no doubled keystrokes
or alike. not even when i alt-tab to mythfrontend during xine playback
and press esc for 10 times and close the player afterwards...
Or, is it impossible to control
xine using the keyboard when started through Myth without Alt-Tab'ing to
the xine window first (focus problem)? If so, it's probably irxevent
(keep reading...).
nope. using the keyboard when not in focus does not work, using lirc when
not in focus works.
You said that irxevent is not running. How sure are you?
"# ps ax | grep irx" gives me nothing. i have no need for irxevent.
Backup your
".lircrc"/"lircrc" file and remove all the irxevent configs just to make
sure (it's possible it's being started by something else).
done, to be very sure. but doesn't change anything.
Because the
events are occurring after xine exits, it seems this is the most
plausible reason for this behavior--you have a focus problem that sends
keys to Myth, but because Myth is blocked waiting for xine to exit, the
events are populated on the X event queue. Since the keys are getting
into the queue after you use the remote, someone started irxevent--which
is sending keys to Myth. Then, when xine exits, Myth processes the
queued X events, giving the behavior you're seeing.
that was also my first thought but - sorry - irxevent is not involved.
any help is appreciated!
If nothing else, I hope this helps you to narrow your search so you're
not chasing non-existant bugs...
i had mythtv up to 0.18.0 running perfectly without these gliches on
my old mandrake 10.0 system, and i'm out of ideas now. i believe you
that it's probably not a myth bug... but i'm still out of ideas.
It happens on both of my boxes at home regardless of the type of
remote (one has a hauppauge wintv remote,i2c), the other one a
recycled yamaha cd player remote, serial), regardless of the player
application i use in with mythdvd/mythvideo, and regardless of the
lirc version used.
I have compiled mythtv with athlon optimizations, may this be a problem?
LIRC is working the way it's supposed to. It isn't a focus problem
(unless you've also got irxevent in the mix).
agree. i wish i had irxevent running so i could kill it ;)
Since Myth isn't
responding to the commands when the buttons are pressed, it doesn't seem
to be a problem with Myth failing to set the lirc_lock. LIRC doesn't
queue up events, so if there is a queue of events executing, it's
probably coming from elsewhere.
how sure are you? i think mythfrontend is blocked while the player command
executes. it really looks like something cues up some events.
the blocking (myth ignoring lirc) seems to work partially, because it's
definately not all buttons which come through. when i just start a player
through myth and exit it after some seconds (no other buttons pressed)
then it's a 70:30 chance, sometimes myth stays in the current menu (off
button not received), and sometimes it reacts leaving the current menu.
the more buttons i use during playback, the more actions follow later on
when player exits. but it's not all button-presses, just...some. sometimes
after watching a whole dvd with menu navigation and other key pressed,
myth goes completely mad afterwards and navigates through a couple of
menus, i even almost had deleted a tv show one time ("are you sure you wish
to delete?").
just annoying.
so how does that locking/blocking work? maybe myth stops blocking lirc too
late (player already running) or too fast (player still running)?
Good luck,
thanks, i need it ;)
i hope someone can reproduce or explain this!?!
_______________________________________________
mythtv-users mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
