[mythtv-users] LIRC problem in Mythdvd/Mythvideo (lircd sends twice)

Mark Schuren schuren at ultra.de
Tue Aug 2 08:32:39 UTC 2005


is there really nobody out there who has the same effects with lirc?

i have mandriva 2005 le, with unmodified kernel, i just installed
the nvidia 7667 drivers and then compiled mythtv from 0.18.1 sources -
no problems. i have two different machines showing the same issue :-(

i understood that the behaviour is not what it should be like
(mythfrontend should block receiving lirc events when it launches
a video/dvd player app like mplayer or xine). But on both of my systems
the problems described below are happening almost every time i use
mythdvd or mythvideo :-(

Is it likely that a CVS version of myth will help?

What else should I try next?

Updating/recompiling lirc did not help.

Is anyone using mythtv/xine/mplayer/lirc on mandriva 2005 (2.6.11-6mdk)
without any flaws using a remote control? Should I invest the time to
build a new stock kernel from kernel.org?

Please give me an advice, I'm so frustrated.

thanks in advance!

Mark Schuren wrote:
> lots of thanks your in-depth answers! 
> 
> unfortunately nothing helps it. any more hints?
> 
> "Michael T. Dean" <mtdean at thirdcontact.com> 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
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


More information about the mythtv-users mailing list