Version: unspecified (using KDE 4.5.85) OS: Linux Am trying to get kremotecontrol to work with my remote (built in to a Hauppauge DVB USB stick). Lirc is working correctly - it works with mythtv. My remote is configured as a 'devinput' type in lirc. The kcm module recognises button presses on my remote. I also see messages from lircd in /var/log/daemon.log when I start the kcm module saying that a client has connected. So that bit works. But I create some actions (eg for Amarok) and they do not work. There seem to be two wierd things going on. Firstly, in systemsettings the K Remote Control Daemon is shown as 'not running' when it definitely is. I modified kremotecontroldaemon.desktop so that it contains 'X-KDE-DBus-ModuleName=kremotecontroldaemon' instead of 'X-KDE-DBus-ModuleName=krcd'. This solved this one problem but didn't get me any further. Secondly, when I stop and start the K Remote Control Daemon I don't see any messages in /var/log/daemon.log saying that any clients have connected or disconnected to lirc. Is the daemon actually listening to anything? Reproducible: Always I'm not familiar with how to get debug printfs out of kde daemons but I'm happy to be told :-)
(In reply to comment #0) > The kcm module recognises button presses on my remote. I also see messages from > lircd in /var/log/daemon.log when I start the kcm module saying that a client > has connected. So that bit works. But I create some actions (eg for Amarok) and > they do not work. What do you mean by "The kcm module recognises button presses"? If you open the dialog for configuring actions and press some buttons on the remote, is the combobox for the button updating accordingly? > There seem to be two wierd things going on. > Firstly, in systemsettings the K Remote Control Daemon is shown as 'not > running' when it definitely is. I modified kremotecontroldaemon.desktop so that > it contains 'X-KDE-DBus-ModuleName=kremotecontroldaemon' instead of > 'X-KDE-DBus-ModuleName=krcd'. This solved this one problem but didn't get me > any further. This is indeed wrong in the .desktop file. Thanks for pointing it out! > Secondly, when I stop and start the K Remote Control Daemon I don't see any > messages in /var/log/daemon.log saying that any clients have connected or > disconnected to lirc. Is the daemon actually listening to anything? OK... I'm not yet sure what the problem could be... Lets debug that a little further: - Is the icon for kremotecontrol sitting in the notification area (aka system tray) - If yes, is it flashing when you press any buttons? > I'm not familiar with how to get debug printfs out of kde daemons but I'm happy > to be told :-) Lets start with the basics then: - open "kdebugdialog" and verify that the "kded4" is checked - kill and restart kded4 from Konsole to obtain its debug output - You can load the daemon using "qdbus org.kde.kded /kded loadModule kremotecontroldaemon" and stop it with the same but "unloadModule" instead of "laodModule". To list the currently loaded modules use "qdbus org.kde.kded /kded loadedModules" Please attach the output of kded4 when loading the kremotecontroldaemon module and pressing any buttons.
SVN commit 1207084 by mzanetti: Fix module name in desktop file CCBUG: 260271 M +1 -1 kremotecontroldaemon.desktop WebSVN link: http://websvn.kde.org/?view=rev&revision=1207084
OK I've started investigating like you suggested but what I've discovered is that the problem is not quite as I described because there are some more fundamental problems that were confusing matters. Firstly there's some sort of issue with the remote initialising when I boot - I have to unplug the receiver and then plug it back in in order to get it to work at all with any application *except* the dialog for configuring actions, which always works even directly after a boot. So this makes me wonder if something in KDE has 'locked' my receiver out. Certainly there's a very long pause after log in (30 seconds) during which nothing happens and then the kremotecontrol icon appears in the system tray. This only happens directly after the initial boot. So having done that I can get certain actions to work - I can now control Amarok for example, but I can't get any of the Sound Mixer actions to work, which is what I was originally testing. The system tray icon flashes when I push the volume buttons, but nothing else happens. (My volume controls do work if I disable kremotecontrol. They even work if I stop lircd. I think this is because my receiver is being driven by both 'devinput' and 'kbd' kernel modules. I mention this in case it's relevant but I don't think it is) Sorry for the long post. To sum up, kremote controldaemon *does* work provided my receiver is properly initialised but: (a) Something prevents my receiver from initialising properly - could kremotecontrol or Solid be the culprit? How do I find out? (b) The sound mixer template appears not to work (could this be because I have pulseaudio running?)
(In reply to comment #3) > Firstly there's some sort of issue with the remote initialising when I boot - I > have to unplug the receiver and then plug it back in in order to get it to work > at all with any application *except* the dialog for configuring actions, which > always works even directly after a boot. Thats kinda strange, because also the configure actions dialog gets the button presses from the kremotecontroldaemon... If the dialog works, everything should work... The daemon is the only instance talking directly to lircd and disatches the button presses to either the config dialog or the action-executionengine. > So this makes me wonder if something > in KDE has 'locked' my receiver out. Certainly there's a very long pause after > log in (30 seconds) during which nothing happens and then the kremotecontrol > icon appears in the system tray. This only happens directly after the initial > boot. Verify if the icon is there earlier, but crossed out and hidden behind the arrow. If there is no connection to lircd, the icon is hidden in the inactive icon area. > > So having done that I can get certain actions to work - I can now control > Amarok for example, but I can't get any of the Sound Mixer actions to work, > which is what I was originally testing. The system tray icon flashes when I > push the volume buttons, but nothing else happens. > OK... I just have checked the mixer actions and it seems KMix has changed its D-Bus API lately. I'll have to fix the Volume actions. In the meantime you can workaround this like this: - call: qdbus org.kde.kmix /Mixer0 masterDeviceIndex - copy the resulting string (something like "alsa_output.pci-0000_00_1b.0.analog-stereo") and paste it into the argument value of the configured volume action instead of the text "Master:0" > (My volume controls do work if I disable kremotecontrol. They even work if I > stop lircd. I think this is because my receiver is being driven by both > 'devinput' and 'kbd' kernel modules. I mention this in case it's relevant but I > don't think it is) Not sure... I have no experience with devinput infrared devices. > Sorry for the long post. To sum up, kremote controldaemon *does* work provided > my receiver is properly initialised but: > (a) Something prevents my receiver from initialising properly - could > kremotecontrol or Solid be the culprit? How do I find out? I doubt its KRemoteControl or Solid. They only access the socket file reading. No locks etc involved. Currently I'm not really sure what I should advice to further debug this except trying to better understand how everything works and re-read all the debug output with the newly learned things... If you want to learn more about debugging, you can also contact me privately to prevent flooding the bug report with non related stuff. I'm always willing to help users that have the will to learn some stuff to produce good bug reports. > (b) The sound mixer template appears not to work (could this be because I have > pulseaudio running?) I'll fix this for 4.6. Please use the above mentioned workaround in the meantime.
(In reply to comment #4) > > Thats kinda strange, because also the configure actions dialog gets the button > presses from the kremotecontroldaemon... If the dialog works, everything should > work... The daemon is the only instance talking directly to lircd and disatches > the button presses to either the config dialog or the action-executionengine. Very odd, because when I open the configure dialog I get a 'client connected' message from lircd in /var/log/daemon.log, and when I close the dialog I get a 'client disconnected' message there. I'll do the workaround for the volume control. I don't have much time right now to look at the rest of it. It does seem to me as if it's some strange startup/race kind of condition and probably nothing to do with kremotecontrol.
Any new findings on this one? It really sounds like some sort of race condition when starting up the machine... btw. The Sound Mixer problem should be gone by now. KMix seems to have fixed their API again, so the above mentioned workaround shouldn't be needed any more.
Sorry I haven't been able to do any more tests on this since I last posted, been on holiday :-) Your theory about a race condition sounds feasible though, I do recall having issues that the DVB adapter sometimes didn't work unless I removed and reinserted if after a cold boot. If I get a chance I'll update this bug report, but that's not likely to happen in the immediate future.
Confirming this bug on openSUSE 11.4, Kernel 2.6.37, KDE 4.6.0, LIRC 0.9.0-pre1 with driver 'devinput', lircd set to auto-start on boot (runlevels 2, 3, 5), irw working correctly at all times After reboot, the remote control is not working with kremotecontrol First try: 1. Reboot 2. Remote control not working, the icon in the systemtray is not flashing. 3. Open Remote-Control config dialog: Buttons are picked up during the config, the sys-tray icon is not flashing 4. Close Remote-Control config dialog: No button activity (see 2) Second try: 1. qdbus org.kde.kded /kded loadedModules, output includes kremotecontroldaemon 2. Unload kremotecontroldaemon with qdbus, result: tray icon disappears 3. Re-Load kremotecontroldaemon with qdbus, result: tray icon re-appears 4. No button activity at all, not even in config dialog Third try: 1. kill kded4, result tray icon disappears 2. restart kded4 (with debug output enabled), result http://pastebin.kde.org/7743/ 3. No button activity in config 4. Buttons work as expected outside the config Hope that helps. If you need more info, I'll gladly submit it. Thanks for the great work on kremotecontrol! Other than this bug, it's a real pleasure to work with!
(In reply to comment #8) > Hope that helps. If you need more info, I'll gladly submit it. Hi Martin, I'd like to see the debug output of the daemon on a run where it failed to connect to lircd. The log you put on pastebin just tells that everything is fine. > Thanks for the great work on kremotecontrol! Other than this bug, it's a real > pleasure to work with! Thanks a lot. I'm glad you like it! Such kind words are always appreciated by the devs.
Hi Michael, sorry for the late reply. I've switched back to lirc 0.8.7 and also found a mistake in my config of XBMC: I set "Remote control sends keyboard presses" to yes - which prevents kremotecontrol from picking up any of the key-presses from the remote. So for me, all is working great now. Thanks for your help - your debugging advice made me realize my mis-configuration of XBMC.
Thanks for reporting back... As this behaviour seems to be caused by third party applications and both setups are working now, I'll close this bug as invalid.
I'm sorry, but I'm afraid I would like to request to re-open this bug. At the time I wrote my last message, everything was working as expected - only to stop working the next day. So instead of always ruining my "real" system, I decided to finally set up a VM (VirtualBox 4.0.4, Host Windows 7), with a clean install of openSUSE 11.4, all updates applied as of March 30th, no further repositories or software installed. (Kernel: 2.6.37.1, kremotecontrol 4.6.0, lirc 0.8.7, kde 4.6.0) Then I took the following steps: 0. Kill kded4, enable debug output for it and start it from konsole again 1. Configure lirc (/etc/sysconfig/lirc and /etc/lirc/lircd.conf) -> set Driver="devinput", Device="dev/input/by-path/pci-0000:00:06.0-usb-0:2:1.0-event" and copy /usr/share/lirc/remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf 2. Install kremotecontrol (No kded4 output after about 1 minute, so continuing) 3. Starting lircd and testing with irw -> Works (still no kded4 output, so continuing) 4. Start kremotecontrol Config dialog -> The remote "devinput" is available and active kded4 output: kded(6449) LircClient::isConnected: theSocket QObject(0x0) kded(6449) LircClient::connectToLirc: lircd >= 0.8.6 socket found... kded(6449) LircClient::connectToLirc: updating remotes kded(6449) LircClient::connectToLirc: waiting for lirc kded(6449) LircClient::connectToLirc: reading... kded(6449) LircClient::slotRead: "LIST" kded(6449) LircClient::slotRead: ("devinput", "devinput") kded(6449) LircClient::slotRead: "LIST devinput" kded(6449) LircClient::slotRead: Remotes read! kded(6449) Solid::Control::ManagerBasePrivate::loadBackend: Backend loaded: "Lirc" kded(6449) LircRemoteControlManager::createRemoteControl: unknown interface: "devinput" creating it kded(6449) KRemoteControlDaemon::KRemoteControlDaemon: connecting to remote "devinput" kded(6449): registerObject() successful for "kremotecontroldaemon" kded(6449)/kded4 Kded::loadModule: Successfully loaded module "kremotecontroldaemon" 5.Trying to configure one of the buttons (e.g. to start up Amarok) -> Config dialog is not picking up buttons, Tray icon is not flashing kded4 output: kded(6449) KRemoteControlDaemon::ignoreButtonEvents: muting remote "devinput" kded(6449) KRemoteControlDaemon::considerButtonEvents: unmuting remote "devinput" 6. Press apply anyway -> Tray icon states that the configuration has been reloaded. kded4 output: kded(6449) Remote::masterMode: Master mode not found kded(6449) Remote::masterMode: Master mode not found kded(6449) KRemoteControlDaemon::reloadConfiguration: starting notifier item 7. Stop lirc, re-open config dialog -> The remote "devinput" is available but inactive (cursive) - however, I can still start the wizard to assign buttons to it. Of course it's not picking up buttons in this state. The tray-icon stays in active state. kded4 output (when opening and closing the wizard to assign buttons): kded(6449) KRemoteControlDaemon::ignoreButtonEvents: muting remote "devinput" kded(6449) KRemoteControlDaemon::considerButtonEvents: unmuting remote "devinput 8. Start lirc, re-open config dialog, assign button to open amarok, save, close: -> The remote is available and active, the wizard picks up button presses. One of the buttons is now configured to start amarok. kded4 output: kded(6449) KRemoteControlDaemon::ignoreButtonEvents: muting remote "devinput" kded(6449) KRemoteControlDaemon::considerButtonEvents: unmuting remote "devinput" kded(6449) Remote::masterMode: Master mode not found kded(6449) KRemoteControlDaemon::reloadConfiguration: starting notifier item -> Tray icon does not flash, assigned action (start amarok) not working 9. Stopping lirc -> Tray icon stays active 10. Starting lirc -> No changes 11. Unloading kremotecontroldaemon from kded4 kded4 output: kded(6449)/kded4 Kded::unloadModule: Unloading module "kremotecontroldaemon" kded(6449) StatusNotifierWatcher::serviceUnregistered: Service "org.kde.StatusNotifierItem-6852-1" unregistered 12. Loading kremotecontroldaemon for kded4 kded4 output: kded(6449) Remote::masterMode: Master mode not found kded(6449) KRemoteControlDaemon::KRemoteControlDaemon: starting notifier item kded(6449) KRemoteControlDaemon::KRemoteControlDaemon: connecting to remote "devinput" kded(6449): registerObject() successful for "kremotecontroldaemon" kded(6449)/kded4 Kded::loadModule: Successfully loaded module "kremotecontroldaemon" kded(6449) StatusNotifierWatcher::RegisterStatusNotifierItem: Registering "org.kde.StatusNotifierItem-7064-1/StatusNotifierItem" to system tray -> Buttons can be assigned in the control dialog kded4 output (don't know if this is actually related, but it happened when I pressed some buttons): Fetched layout groups from X server: layouts: ("de") variants: ("nodeadkeys") kded(6449) LayoutMemory::layoutMapChanged: Layout map change from external source: clearing layout memory Fetched layout groups from X server: layouts: ("de") variants: ("nodeadkeys") 13. Restarting kded4 -> No buttons picked up in config dialog, tray icon not flashing, buttons not working kded4 output: kded(7197) LircClient::isConnected: theSocket QObject(0x0) kded(7197) LircClient::connectToLirc: lircd >= 0.8.6 socket found... kded(7197) LircClient::connectToLirc: updating remotes kded(7197) LircClient::connectToLirc: waiting for lirc kded(7197) LircClient::connectToLirc: reading... kded(7197) LircClient::slotRead: "LIST" kded(7197) LircClient::slotRead: ("devinput", "devinput") kded(7197) LircClient::slotRead: "LIST devinput" kded(7197) LircClient::slotRead: Remotes read! kded(7197) Solid::Control::ManagerBasePrivate::loadBackend: Backend loaded: "Lirc" kded(7197) Remote::masterMode: Master mode not found kded(7197) KRemoteControlDaemon::KRemoteControlDaemon: starting notifier item kded(7197) LircRemoteControlManager::createRemoteControl: unknown interface: "devinput" creating it kded(7197) KRemoteControlDaemon::KRemoteControlDaemon: connecting to remote "devinput" kded(7197): registerObject() successful for "kremotecontroldaemon" kded(7197)/kded4 Kded::loadModule: Successfully loaded module "kremotecontroldaemon" 14. Rebooting, starting lirc -> Tray icon stays inactive (red cross). Config dialog has remote active (i.e. not cursive), not picking up any buttons 15. Killing kded4, starting manually kded4 output: see 13 -> Tray icon now active, not flashing, config dialog not picking up button presses For me, only in very rare cases kremotecontrol works - sometimes config and actions, sometimes actions only. The config dialog works more often then actually performing the actions. I haven't found any pattern that would make the actions work reliably, nor one that would make the config work reliably. YMMV, sometimes restarting lirc helps, sometimes restarting kded4 helps, closing and reopening config dialog never helps - it's not 100% reproducible, but it's not working correct about 95% of the time. If you want me to try any other sequence, my VM is ready and waiting :-) Cheers
Thanks a lot for this great testing. I have been able to reproduce this now and after some debugging I am a step closer: It seems this is caused by the default lircd.conf for the devinput remote controls: - The default lircd.conf for devinput contains all 446 possible buttons - KremoteControl tries to read all those buttons from lircd directly after connecting - After reading about 350 of those buttons lircd just closes the connection without telling any reason. I still have no idea why this happens, but I noticed that if I throw out all unneeded buttons from the lircd.conf and leave just the 20 really used buttons in the file, the connection works again. Please remove all unneeded buttons from your lircd.conf and let me know if this works around the issue for you too. I will try to figure out why exactly this happens.
My lircd.conf even had an additional set of entries (although a comment right above stated that they were obsolete) After removing all unneeded entries, kremotecontrol now again works like a charm across reboot and s2ram - thanks a lot for this info. If you can not figure out why lirc stops responding after some 300 entries, it could be an idea to suggest to the lirc package guys, that they should include one devinput-lircd.conf per remote, instead of one devinput-lircd.conf for all possible remotes. Thanks again!
This behaviour is reproducable using the default lircd.conf.devinput and executing: irsend LIST devinput "" "" This seems to be a lircd issue.
The issue in lircd is identified and will be fixed soon (next lirc release). Everyone having this issue please use the above mentioned workaround in the meantime. For more information look here: http://sourceforge.net/mailarchive/forum.php?thread_name=F8BBA0D1-689F-4DD0-B25A-C0B638D87412%40wilsonet.com&forum_name=lirc-list